[threethirtytwo]

I’m not underestimating Erlang processes. I’m saying the distinction you’re drawing is largely semantic and policy-level, not a fundamentally different concurrency mechanism.

Erlang processes, goroutines, and async tasks are all cooperatively scheduled user-space execution units multiplexed over OS threads. That is the same underlying concurrency primitive. There is no new physics here.

Erlang’s real contribution is that it forbids shared memory, bakes message passing, supervision, and restart semantics into the runtime, and forces a particular design discipline. That’s a design rule, not a different execution model.

You can approximate Erlang’s semantics on top of async/await or goroutines; you cannot approximate preemptive shared-memory threads on top of Erlang. That asymmetry tells you where the real difference lies.

Treating policy and guarantees as if they were a different kind of concurrency entirely is what causes people to mystify Erlang instead of understanding why its constraints work.

[josefrichter]

It sounds to me like an exercise in wordplay within very broad definitions. My initial reaction was towards the claim "It's literally the same thing as async await in python and nodejs" which is only true in such case.

[threethirtytwo]

Yeah, I mean, I'm basically accusing YOU of word play. The colloquial meaning is broad, you're just being pedantic.