Asynchronous IO: the next billion-dollar mistake?

File io can now be done asynchronously with io_uring.

Or Go. Or Java' virtual threads.

It must happen at the language level; When it comes to execution context knowledge: what context to compile out (stackless), or what context to serialize to the heap (stackful). Programming language will always know much more about the program than the OS.

If I'm not mistaken in Erlang the programmer will provide the exact context to serialize : the actor.

I think compare programing pattern(threads) to kernel async apis is a questionable comparation.

The point of kernel async apis is not about letting programmers write system calls directly. It's about expose the actual async operations under the hook (it could be disk, be network, be anything outside of the computer case).

Those actions are never mean to be interleaved with cpu computation, because they are usually with ms level delay (which could be millions of cpu ticks). The kernel fakes these into sync calls by pause everything. But it isn't always the best idea to do these.

Let userland program decide what they want to do with the delay will be a way better idea. Even they eventually just invent blocking io calls again. They can still decide what operations are more relevant to itself instead of let the kernel guessing it.

To put a different spin on what others are saying, asynchronous IO is a different programming model for concurrency that's actually more ergonomic and easier to get right for an average developer (which includes great developers on their not-highly-focused days).

Dealing with raciness, deadlocks and starvation is simply hard, especially when you are focused on solving a different but also hard business problem.

That's also why RDBMSes had and continue to have such a success: they hide this complexity behind a few common patterns and a simple language.

Now, I do agree that languages that suffer from the "color of your functions" problems didn't get it right (Python, for instance). But ultimately, this is an easier mental model, and it's been present since the dawn of purely functional languages (nothing stops a Lisp implementation from doing async IO, and it might only be non-obvious how to do "cancellation" while "gather" is natural too)

I would concur, the author also mentions that file IO isn't async; this makes me conclude that the author hasn't grasped how much the Linux kernel has moved on since in the mid 2000s.

I suspect that the author has an incomplete view of the current kernel / userland interface as well as the inner workings of how a kernel actually "does what it does".