I think the practitioner angle is what makes interesting. Too many BEAM advocacy posts are theoretical.<p>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.
> actors still deadlock through circular messages<p>I've rarely seen naked sends/receives in Erlang, you mostly go through OTP behaviors. And if you happen to use them and get stuck (without "after" clause), the fact you can just attach a console to a running system and inspect processes' states makes it much easier to debug.
Stateless vs stateful concurrency management is very different, though; I can roll back / replay a mail box, while this isn’t possible with shared locks. It’s a much cleaner architecture in general if you want to scale out, but it has more overhead.
I love the idea of Erlang (and by association Elixir), OTP, BEAM...<p>In practice? Urgh.<p>The live is all so cerebral and theoretical and I'm certain the right people know how to implement it for the right tasks in the right way and it screams along.<p>But as yet no one has been able to give me an incling of how it would work well for me.<p>I read learn you some Erlang for great good quite a while back and loved the idea. But it just never comes together for me in practice. Perhaps I'm simply in the wrong domain for it.<p>What I really needed was a mentor and existing project to contribute to at work. But it's impossible to get hold of either in the areas I'm in.
Related thread from 11 days ago: <a href="https://news.ycombinator.com/item?id=47067395">https://news.ycombinator.com/item?id=47067395</a> "What years of production-grade concurrency teaches us about building AI agents", 144 points, 51 comments.
How closely is BEAM/OTP related to the foundational work on CSP (and the implementation in Occam/Transputer way back when…)?
Good question! It's a bit of a stretch. BEAM has mailboxes, non-blocking sends, and asynchronous handling of messages, whereas the original CSP is based on blocking sends and symmetric channels. Symmetric means you have no real difference between sends and receives: two processes synchrnoise when they are willing to send the same data on the same channel. (A "receive" is just a nondeterministic action where you are willing to send <i>anything</i> on a channel).<p>Occam added types to channels and distinguished sends/receives, which is the design also inherited by Go.<p>In principle you can emulate a mailbox/message queue in CSP by a sequence of processes, one per queue slot, but accounting for BEAM's weak-ish ordering guarantees might be complicated (I suppose you should allow queue slots to swap messages under specific conditions).
Very interesting. Reading this made me think of occam on the transputer: concurrent lightweight processes, message passing, dedicated memory! I spent some happy years in that world. Perhaps I should look at BEAM and see what work comes along?
Zero-sharing message passing is known. But what about shared state? Given the majority of systems manage shared access to arbitrarily constrained shared state or shared resources, I'd be interested to see how this should be handled without just saying "database". Maybe another article?
One process is made the logical goto for all operations on that data. The process identity is logically the identity of the shared state.<p>In other words, it is exactly a database, albeit an in-memory one.
> 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.<p>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.
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.
Sending message to a process has a cost (for purposes of preemption) relative to the current size of receiver's mailbox, so the sender will get preempted earlier. This isn't perfect, but it is <i>something</i>.
I wonder how much the roots of erlang is showing now? Telephone calls had a very specific "natural" profile. High but bounded concurrency (number of persons alive), long process lifetime (1 min - hours), few state changes/messages per process (I know nothing of the actual protocol). I could imagine that the agentic scenario matches this somewhat where other scenarios, eg HFT, would be have a totally different profile making beam a bad choice. But then again, that's just the typical right-tool-for-the-job challenge.
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.
Go is good enough.
The Node.js community had figured this out long before BEAM or even Elixir existed.<p>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.<p>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.<p>Work on the BEAM started in the 1990s, over ten years before the first release of Node in 2009.
And BEAM was the reimplementation of the Erlang runtime, the actual model is part of the language semantics which was pretty stable by the late 80s, just with a Prolog runtime way too slow for production use.
Forget Node.js; _Javascript_ hadn't even been invented yet when Erlang and BEAM first debuted.
You may be thinking of some recent round of publicity for BEAM, but BEAM is a bit older than JavaScript.
BEAM predates node js
I think the author is trying to be clever to parody what was written in tfa.