11–20 of 30 posts
You can have it all in the vast majority of cases. It just requires a lot of work. See: The Hotspot JVM.
> But again, there is no free lunch: copying data is slow. Very slow. Of course you can optimize data representations, avoid copying binary blobs (they are ref-counted in Erlang) because it would be untenable. But it will still be horribly slow. 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 stru…
Preemptive actor model (Erlang, Elixir, Gleam) for backend.
https://pouchdb.com for frontend.
This doesn't follow at all! Dropping interactivity [keep Concurrency, mutability]: The most popular choice is to drop interactivity: since there is no one to randomly access runtime data, there are no concurrency issues. C, Rust, Go, the list of languages that go this way is long. No-one to randomly access runtime data? Do "other threads" not count? There are no concurrency issues in C? Dropping mutability What if yo…
I believe the article is written from a lisp point of view where it interactivity is inspecting and modifying the application itself while it is running. It’s assuming that the software has already been written with no existing concurrency issues, but when a person comes along and does something unexpected and rewrites pose of the application or in the example they gave, modifying a hash map, things break. They used…
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 sourc…
What exactly are you mutating?
You can have it all in the vast majority of cases. It just requires a lot of work. See: The Hotspot JVM.
This doesn't follow at all! Dropping interactivity [keep Concurrency, mutability]: The most popular choice is to drop interactivity: since there is no one to randomly access runtime data, there are no concurrency issues. C, Rust, Go, the list of languages that go this way is long. No-one to randomly access runtime data? Do "other threads" not count? There are no concurrency issues in C? Dropping mutability What if yo…
I believe the article is written from a lisp point of view where it interactivity is inspecting and modifying the application itself while it is running. It’s assuming that the software has already been written with no existing concurrency issues, but when a person comes along and does something unexpected and rewrites pose of the application or in the example they gave, modifying a hash map, things break. They used…
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 sourc…
> 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
> But again, there is no free lunch: copying data is slow. Very slow. Of course you can optimize data representations, avoid copying binary blobs (they are ref-counted in Erlang) because it would be untenable. But it will still be horribly slow. 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 stru…
If you don't copy the data to the other process, then your garbage collection needs to be aware of all processes all the time. I'm not sure if the author would count that as a form of synchronization, but it wouldn't be unreasonable to argue that I think.
And that could be substantially faster than a mutable approach when you need to make a genuine copy of the 1MB structure with a small change and keep both, because you can't structure share and you will need to copy the whole MB. Obviously situation specific, and I'm sure there are edge cases where immutable lookup tables fall apart. I haven't met one myself.
I don't disagree with the article exactly, I do think abandoning mutability is necessary. I just don't think his argument that it needs to be slow is good. If you abandon mutability, "copying" data logically is extremely fast because you can skip almost all the IO for large objects. And copying a large object with a small change should be much faster in an immutable language because of structure sharing. Depending on the workload, that might be faster.