Process-Based Concurrency: Why Beam and OTP Keep Being Right
variantsystems.io
Process-Based Concurrency: Why Beam and OTP Keep Being Right
1–10 of 58 posts
Re: Process-Based Concurrency: Why Beam and OTP Keep Being Right
#2I think the practitioner angle is what makes interesting. Too many BEAM advocacy posts are theoretical.
I would push back on the "shared state with locks vs isolated state with message passing" framing. Both approaches model concurrency as execution that needs coordination. Switching from locks to mailboxes changes the syntax of failure, not the structure. A mailbox is still a shared mutable queue between sender and receiver, and actors still deadlock through circular messages.
Re: Process-Based Concurrency: Why Beam and OTP Keep Being Right
#3> Backpressure is built in. If a process receives messages faster than it can handle them, the mailbox grows. This is visible and monitorable. You can inspect any process’s mailbox length, set up alerts, and make architectural decisions about it. Contrast this with thread-based systems where overload manifests as increasing latency, deadlocks, or OOM crashes — symptoms that are harder to diagnose and attribute.
Sorry but this is wrong. This is no kind of backpressure as any experienced erlang developer will tell you: properly doing backpressure is a massive pain in erlang. By default your system is almost guaranteed to break in random places under pressure that you are surprised by.
Re: Process-Based Concurrency: Why Beam and OTP Keep Being Right
#4> Backpressure is built in. If a process receives messages faster than it can handle them, the mailbox grows. This is visible and monitorable. You can inspect any process’s mailbox length, set up alerts, and make architectural decisions about it. Contrast this with thread-based systems where overload manifests as increasing latency, deadlocks, or OOM crashes — symptoms that are harder to diagnose and attribute. Sorry…
Yes, this is missing the "pressure" part of "backpressure", where the recipient is able to signal to the producer that they should slow down or stop producing messages. Observability is useful, sure, but it's not the same as backpressure.
Re: Process-Based Concurrency: Why Beam and OTP Keep Being Right
#5> Backpressure is built in. If a process receives messages faster than it can handle them, the mailbox grows. This is visible and monitorable. You can inspect any process’s mailbox length, set up alerts, and make architectural decisions about it. Contrast this with thread-based systems where overload manifests as increasing latency, deadlocks, or OOM crashes — symptoms that are harder to diagnose and attribute. Sorry…
Occam (1982 ish) shared most of BEAMs ideas, but strongly enforced synchronous message passing on both channel output and input … so back pressure was just there in all code. The advantage was that most deadlock conditions were placed in the category of “if it can lock, then it will lock” which meant that debugging done at small scale would preemptively resolve issues before scaling up process / processor count.
Re: Process-Based Concurrency: Why Beam and OTP Keep Being Right
#6The Node.js community had figured this out long before BEAM or even Elixir existed.
People tried to introduce threads to Node.js but there was push-back for the very reasons mentioned in this article and so we never got threads.
The JavaScript languages communities watch, nod, and go back to work.
Re: Process-Based Concurrency: Why Beam and OTP Keep Being Right
#7The Node.js community had figured this out long before BEAM or even Elixir existed. People tried to introduce threads to Node.js but there was push-back for the very reasons mentioned in this article and so we never got threads. The JavaScript languages communities watch, nod, and go back to work.
You may be thinking of some recent round of publicity for BEAM, but BEAM is a bit older than JavaScript.
Re: Process-Based Concurrency: Why Beam and OTP Keep Being Right
#8The Node.js community had figured this out long before BEAM or even Elixir existed. People tried to introduce threads to Node.js but there was push-back for the very reasons mentioned in this article and so we never got threads. The JavaScript languages communities watch, nod, and go back to work.
BEAM predates node js
Re: Process-Based Concurrency: Why Beam and OTP Keep Being Right
#9The Node.js community had figured this out long before BEAM or even Elixir existed. People tried to introduce threads to Node.js but there was push-back for the very reasons mentioned in this article and so we never got threads. The JavaScript languages communities watch, nod, and go back to work.
> The Node.js community had figured this out long before BEAM or even Elixir existed.
Work on the BEAM started in the 1990s, over ten years before the first release of Node in 2009.
Re: Process-Based Concurrency: Why Beam and OTP Keep Being Right
#10Go is good enough.