top | item 46956539

(no title)

josefrichter | 19 days ago

No, it’s not literally the same thing. I’m afraid you greatly underestimate and fundamentally misunderstand Erlang processes by making such comparison.

discuss

order

threethirtytwo|19 days ago

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|19 days ago

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.