Live data from Hacker News

Concurrency, interactivity, mutability, choose two

n16f.net

21–30 of 30 posts

Re: Concurrency, interactivity, mutability, choose two

#21

Earlier quoted context omitted.

> 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?

Re: Concurrency, interactivity, mutability, choose two

#22

Earlier quoted context omitted.

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?

What sentence from my post implies that?

Re: Concurrency, interactivity, mutability, choose two

#23
I believe it is a Lisp related story, not some general truth. I mean, if I had a hashtable that needs to be mutated asynchronously, I'd probably create a single writer to it. Some entity that takes ownership of a hashtable and you can talk with hashtable only through it.

But if you are writing Lisp, and that hashtable is a global, then good luck ensuring that no one except the designated entity talks with hashtable directly. In particular, you can't force the user at REPL prompt to not do it.

The mutability lament in the same ballpark. Dynamic nature of LISP makes it hard to ensure that some code paths can't change values they deal with. Statically typed languages do it all the time: just pass a const reference into a function and you can be sure that it wouldn't change the value, or anything referenced from it. In LISP the easiest way is to make a deep copy of a value. Other ways would probably need some changes introduced into lisp-machine itself. So you are choosing between two alternatives: either copy everything, or to believe other code to behave like values are immutable. The former is slow, the latter just doesn't work generally.

Take Rust for example: if I have a mutable HashMap that needs a concurrent access, I'd hide it. It would be accessible directly in one module only, and the module would export safe API that you can't use to achieve data race. Technically I can make this HashMap to be global, but then Rust would rebels and force me to wrap my HashTable into a Mutex. If I added REPL to the mix, then REPL would need to lock Mutex as any other thread.

Lisp just an ancient language that doesn't have these guardrails, so you need to think things through and ofc you will be overwhelmed in any real case by all these things, and then you write that you can't have concurrency, interactivity and mutability at the same time. To have them, you have to limit yourself in how you write your program, and while you can use LISP to limit yourself, you still need to do the decision and invest some work into it. It doesn't happen magically all by itself. For magic you'd better try rust, though its "magic" requires months of fighting with borrow checker until it succeeds at conditioning you into right practices.

Re: Concurrency, interactivity, mutability, choose two

#24

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"

> we're approaching a time where a single processor has hundreds of threads

Approaching? EPYC 9996 has 512 threads. EPYC 9754 had 256 threads three years ago.

Re: Concurrency, interactivity, mutability, choose two

#25
post #5

> 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…

Elixir / Beam take this approach with byte strings. Once they exceed 64 bytes they are allocated to shared reference counted memory.

Re: Concurrency, interactivity, mutability, choose two

#26
post #25
post #5

> 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…

Elixir / Beam take this approach with byte strings. Once they exceed 64 bytes they are allocated to shared reference counted memory.

I'm more and more convinced that for these types of problems most popular languages are just reimplementing or offloading to services like Kafka or Celery functions that are first class primitives in the BeamVM/Elixir

Re: Concurrency, interactivity, mutability, choose two

#28
post #15

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…

'Statefulness' doesn't make anything clearer. What exactly are you mutating?

I'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".

Post reply on HN