Exposing the limitations of the underlying tech is a good thing, because it makes it clear what needs to be fixed. Early operating system APIs grew up around b

Exposing the limitations of the underlying tech is a good thing, because it makes it clear what needs to be fixed. Early operating system APIs grew up around batch systems, which were inherently synchronous. As multi-user systems and networking became ubiquitous, computers have become inherently asynchronous. But system APIs have been slow to evolve, or else have made explicit decisions to go all-in with threading (e.g. WinAPI). Threads are a paper-over. You can use threads to simulate asynchronicity over synchronous system APIs. As I'm sure you know, threads have a widespread performance tax (context switching blowing out your cache), and are an obstacle for the developer who wants to understand exactly what the machine is really doing. When you use async, you can reason about what the machine is doing. Operating system APIs have been slow to effectively support this. For example, they usually support something like select(3) but it's usually non-trivial to check for keyboard input in the same select call as you are checking for network activity. It's encouraging to see Linux add io_uring recently. I think I have read elsewhere that Windows is your main platform. Indeed, the Windows API steers programmers heavily towards threads due to design choices. Sometimes in linux you can hack in a path towards async by abusing file descriptors+threads but Windows is inflexible here. Tanenbaum defends the synchronous model, "Parallel programming and interrupts are REALLY REALLY hard to get right. There are all kinds of race conditions you have to worry about. Synchronous is much safer. Sometimes there is no way around using an asynchronous interface, but it is always the last resort. Making it hard to do is a good idea." But the RMOX os seems to have solved the general problem of creating a pure-async system api. The dialects of Javascript that are in the current generation of browsers are confusing partly because the async model in that js generation is half-baked. In another comment, you highlight the ecosystem problems that have grown around js callback hell. But these problems are not an inherent problem of async programming. For example, python3 asyncio does not suffer from callback hell, because (1) it is straightforward to await on a coroutine to return a value, and (2) the ecosystem has grown up around a mature async model. There are still hassles with python asyncio libraries that use threads under the hood. For example, I've had trouble with aiofiles at scale. Regarding Erlang: I see the actor model as a weak response to multicomputing. Some of the difficult problems of that domain: (1) message reliability; (2) grid-application survival when you lose a physical host. Erlang/Actor avoids responsibility here by telling the application programmer that they must assume that message delivery is unreliable. This pushes handling of all related problems into the application layer, where it is a distraction, and arduous to test. I think the actor model dodges hard problems that are inherent to its chosen domain. (Apologies if I have misunderstood the reason you highlighted Erlang.)