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

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.

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.

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

I think you’re missing my point. Even if they were using “real” thread then it then Erlang’s messaging semantics would remain largely unchanged.

Also, it’s not the same thing as async nodejs. Node.js is a fully cooperative system, something CPU intensive can hog the thread and starve the other tasks. Erlang processes are preemptive; every process gets N reductions and then it is parked and the next process can make progress. They’re closer to OS processes than goroutines.