6 ms·
You can substitute the word 'interactivity' with 'statefulness' and it makes the statement more intuitive IMO. Concurrency + statefulness means you can't have
by socketcluster 2mo ago
You can substitute the word 'interactivity' with 'statefulness' and it makes the statement more intuitive IMO.
Concurrency + statefulness means you can't have mutability because then you would run the risk of a concurrent update overwriting another. But you can have concurrent read-only state, so long as concurrent writing is not permitted. This is the 'single writer principle' which is a variant of the 'single source of truth principle'. You can't have concurrent writing in this case.
If you have statefulness + mutability then you must do away with concurrency; a different way to avoid the same concurrent overwriting problem mentioned above.
If you have concurrency + mutability, then that's possible if you don't have state... You could have multiple independent, divergent copies of the state but not a single consistent state.
- PunchyHamster 2mo ago> If you have statefulness + mutability then you must do away with concurrency; a different way to avoid the same concurrent overwriting problem mentioned above. Last time I checked we had plenty of concurrency primitives allowing for that; you might need to wait few tens or hundreds of nanoseconds for a lock (or few orders more over network), but it works just fine
- naasking 2mo agoAll of them depend on temporarily suspending concurrency in order to synchronize. Even atomic exchange operations are like this at the hardware level.
- mrkeen 2mo ago'Statefulness' doesn't make anything clearer. What exactly are you mutating?
- dwattttt 2mo agoI'll take a punt; based on the last pairing, where "statefulness" is abandoned > You could have multiple independent, divergent copies of the state but not a single consistent state. I'd suggest it's describing "consistency".