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.
You don't have to copy the data; it is immutable. Why copy something that isn't going to change? Are we being charged for empty RAM? Different objects can share the same structure. Famously, this is what Clojure does. Theoretically it can be faster than mutating objects because you only have to write the parts that are changing (which is the same as a mutable object), you lose something to overheads (might be nearly negligible) and have enormous gains in situations where you might need a copy of an object for some reason because that is free; there isn't any reason to actually do a copy unless the data itself is going to be mutated.
mrkeen•44m ago
Peeking over the fence at an immutable language and thinking "that runtime does too much copying, which is bad!" is like peeking over the fence at a GC language and thinking "that runtime does too many mallocs and frees, which is bad!"
phil-martin•19m ago
They used C as an example because under normal circumstances you compile a binary and don’t modify it at runtime.
I’m not doing to defend it to strongly though, I _think_ that is what they were getting at, but to be honest I found much of it confusing.
Certhas•14m ago