Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

variantsystems.io

Post reply on HN
Print view View original

11–20 of 58 posts

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

#11

Post by masklinn »

pentacent_hq wrote: post #9
socketcluster wrote: post #6

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.

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

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.

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

#13

Post by baud9600 »

librasteve wrote: post #5
rapsey wrote: post #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…

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.

Once you were familiar with occam you could see deadlocks in code very quickly. It was a productive way to build scaled concurrent systems. At the time we laughed at the idea of using C for the same task

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

#14

Post by [deleted] »

socketcluster wrote: post #6

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.

[deleted]

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

#15

Post by librasteve »

baud9600 wrote: post #13
librasteve wrote: post #5

Earlier quoted context omitted.

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.

Once you were familiar with occam you could see deadlocks in code very quickly. It was a productive way to build scaled concurrent systems. At the time we laughed at the idea of using C for the same task

I spreadsheeted out how many T424 die per Apple M2 (TSMC 3nm process) - that's 400,000 CPUs (about a 600x600 grid) at say 1GIPs each - so 400 PIPS per M2 die size. Thats for 32 bit integer math - Inmos also had a 16 bit datapath, but these days you would probably up the RAM per CPU (8k, 16k?) and stick with 32-bit datapath, but add 8-,16-bit FP support. Happy to help with any VC pitches!

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

#16

Post by stingraycharles »

joshsegall wrote: post #2

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…

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.

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

#17

Post by mnsc »

rapsey wrote: post #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…

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.

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

#18

Post by worthless-trash »

socketcluster wrote: post #6

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.

I think the author is trying to be clever to parody what was written in tfa.

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

#19

Post by hlieberman »

socketcluster wrote: post #6

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.

Forget Node.js; _Javascript_ hadn't even been invented yet when Erlang and BEAM first debuted.

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

#20

Post by IsTom »

joshsegall wrote: post #2

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…

> actors still deadlock through circular messages

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.

Post reply on HN