Process-Based Concurrency: Why Beam and OTP Keep Being Right

joshsegall

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

rapsey

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

socketcluster

The 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.

gethly

Go is good enough.

baud9600

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?

mrngm

Related thread from 11 days ago: https://news.ycombinator.com/item?id=47067395 "What years of production-grade concurrency teaches us about building AI agents", 144 points, 51 comments.

emperorz0

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?

EdNutting

How closely is BEAM/OTP related to the foundational work on CSP (and the implementation in Occam/Transputer way back when…)?

rustyhancock

I love the idea of Erlang (and by association Elixir), OTP, BEAM... In practice? Urgh. 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. But as yet no one has been able to give me an incling of how it would work well for me. 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. 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.

loloquwowndueo

I really tried reading through this but couldn’t - it’s AI-written so it’s like trying to chew cardboard. I gave up after like 3 paragraphs.

epicepicurean

A rewrite of a stateful application written in python with postgres would be more illustrative of how you're solving the same problems but better. Do BEAM applications not use an actual databse? How is crash tolerance guaranteed? In a typical application I'd write crash tolerance would be handled by the DB. So would transactionality. Without it, one would have to persist each message to disk and be forced to make every action idempotent. The former sounds like a lot of performance overhead, the latter like a lot of programming effort overhead. I assume these problems are solved, but the article doesn't demonstrate the solutions.

nnevatie

BEAM/OTP are great, but do impose an exotic language onto the user. Most programs and solutions of today aren't Erlang-based.

dzonga

inverse thinking is needed here - instead of having a solution trying to find a problem. what would it look like if you didn't need concurrency at all - would simply having a step by step process enough e.g using DAGs what would it look like if by not letting it crash - you can simply redo the process like a Traditional RDBMS does i.e ACID they're domains where OTP / BEAM are useful - but for majority of business cases NO

vipulbhj

Author of the post and founder of Variant System here, so cool to finally find out where we been getting all this traffic from. So many threads I wanna jump in to, interesting discussions.