OK, OP was somewhat remiss in saying "no-one". But you have, I think, missed his point. Instead, substitute "few mainstream language designers" and it stands

OK, OP was somewhat remiss in saying "no-one". But you have, I think, missed his point. Instead, substitute "few mainstream language designers" and it stands up. By mainstream I mean Java, Javascript/Typescript, C#, C, C++, Python and such. Most have introduced async/await. None has meaningfully gone beyond that as far as I'm aware. Working with Erlang's concurrency model is a refreshingly simple, consistent mental model compared to the mismash of concurrency features provided by the mainstream. In Erlang, it's as simple as: 1. Do these things need to happen concurrently? No: regular functions. Yes: spawn regular functions. Compare that to the mainstream: 1. Do these things need to run concurrently? No: regular functions. Yes: are there only a few, and/or do I need strong isolation? Yes: use OS-level processes No: do I want the OS to take care of scheduling / preemption? Yes: use threads No: use async/await Is there a chance that my async operations will be scheduled across multiple OS threads? No: get speed boost from no scheduling overhead, but remember to yield if there's any long-running actions. Yes: build my own likely-buggy, half-baked scheduler Oh, and as a bonus: run back up the entire call stack to make all functions that call mine async. And that's before we get to error handling. I'd take Erlang supervision trees _every day_ over trying to figure out which nested async callback function generated an exception.