> 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 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.
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.
I don't think the author took a position on synchronisation at all. He said you have to pick one to abandon of mutability/concurrency/interactivity and that abandoning mutability is horribly slow (because of the need to copy things). And that isn't technically accurate because you can abandon mutability and not copy things. If you have a 1MB int->int associative data structure and need to change one entry, then you can reuse most of the MB (it isn't going to change) and get away with writing a couple of integers.
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.
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.
> 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
Totally agree; we're approaching a time where a single processor has hundreds of threads - it's a conceptual limitation of the author's preferred language that was never considered due to it's ancient 75-ish year old design. "Use the right tool for the job" has never been more important, versus "I have a hammer, everything is a nail"
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 you could not really change data? Instead of reading the value of a variable, you could have the runtime systematically (and safely) copy the value and return it to you.
Why would you copy anything? Copying is defense against mutation. It's what you do for safety when you're working in a language with pervasive mutation, and it's opt-in and manual, meaning it works about as well as other opt-in and manual operations, like malloc and free.
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!"
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 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.
If the author wants to take "a C program with concurrency and mutability is fine" (correctness being left to the reader), then he might as well just put a big global lock around the REPL and declare interactivity fixed too!
It's especially weird since the author is talking about inspecting and modifying data at runtime; gdb happily attaches to a process running a program written in C. However, if he were talking about inspecting and modifying the program itself, then we'd be cooking.
I think the example makes it pretty clear that this is exactly what is meant. I was thrown by the term interactivity at first as well. But I think the trichonomy is sound, and the Erlang Vs Python Vs Rust buckets are quite meaningful, though I would argue it's rare for people to "interact" with running Python programmes in this way.
> 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 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.
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.
I don't think the author took a position on synchronisation at all. He said you have to pick one to abandon of mutability/concurrency/interactivity and that abandoning mutability is horribly slow (because of the need to copy things). And that isn't technically accurate because you can abandon mutability and not copy things. If you have a 1MB int->int associative data structure and need to change one entry, then you can reuse most of the MB (it isn't going to change) and get away with writing a couple of integers.
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.
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.
'Statefulness' doesn't make anything clearer.
What exactly are you mutating?
> 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
All of them depend on temporarily suspending concurrency in order to synchronize. Even atomic exchange operations are like this at the hardware level.
Are you implying that a single CPU system can't be concurrent?
You can have it all in the vast majority of cases. It just requires a lot of work. See: The Hotspot JVM.
Totally agree; we're approaching a time where a single processor has hundreds of threads - it's a conceptual limitation of the author's preferred language that was never considered due to it's ancient 75-ish year old design. "Use the right tool for the job" has never been more important, versus "I have a hammer, everything is a nail"
Or, almost no work, see erlang gen_server.
A reminder that databases (as an example) provide all three without issues (at the cost of complexity in the implementation of course).
This doesn't follow at all!
No-one to randomly access runtime data? Do "other threads" not count? There are no concurrency issues in C? Why would you copy anything? Copying is defense against mutation. It's what you do for safety when you're working in a language with pervasive mutation, and it's opt-in and manual, meaning it works about as well as other opt-in and manual operations, like malloc and free.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!"
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 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.
If the author wants to take "a C program with concurrency and mutability is fine" (correctness being left to the reader), then he might as well just put a big global lock around the REPL and declare interactivity fixed too!
It's especially weird since the author is talking about inspecting and modifying data at runtime; gdb happily attaches to a process running a program written in C. However, if he were talking about inspecting and modifying the program itself, then we'd be cooking.
I think the example makes it pretty clear that this is exactly what is meant. I was thrown by the term interactivity at first as well. But I think the trichonomy is sound, and the Erlang Vs Python Vs Rust buckets are quite meaningful, though I would argue it's rare for people to "interact" with running Python programmes in this way.
RCU needs discussing in an article like this. It arguably fudges the definitions of all 3 things a little, but you do get them all.
Choose three.
Preemptive actor model (Erlang, Elixir, Gleam) for backend.
https://pouchdb.com for frontend.
That linked benchmark feels weird. The discrepancy is way too big. I'll need to take a look into the slower contestants.