> more generally not thinking clearly about what their multithreaded code will actually do when it runs The whole reason people are trying to build better conc

> more generally not thinking clearly about what their multithreaded code will actually do when it runs The whole reason people are trying to build better concurrent/parallel computational abstractions is because they're sick of having to think about that stuff. But to be able to stop thinking about it you need to arrive at abstractions that don't leak: that is, their failure modes should themselves be (non-leaky) abstractions of the lower-level error details. Async/await still forces you to learn about thread-pools and scheduling — while in Erlang one has to learn about scheduling only to optimize performance, and deadlocking requires one to explicitly write a "receive" without a timeout.