1. The article wasn't talking about "asynchronous I/O". It was talking about message-passing (actor model/message-oriented OO) as the interface.
2. Message passing isn't new, it is at least 50 years old even if you don't go further back than early Smalltalk and the Actor model.
3. The article wasn't "selling" anything, and certainly nothing new see (2). It was noting convergence from several directions on an old and somewhat misunderstood paradigm.
It mentions the names of message-passing and the well-known actors model, but the ideas it engages with are the ideas of io_uring, which is a system for asynchronous I/O using a message queue. The two designs are not unrelated, and you could write an interesting post exploring the relationships between them, but unfortunately the author did not do that, because his engagement with the ideas of the actor model and message-passing was limited to quoting one of Hewitt and Baker's famous early attempts to define actors.
Instead, he jumps into salesman hypester mode with "The game has changed," which, like, gag. A lot of games are having their rules rewritten right now (tank/drone warfare, the energy market, freedom of expression, international finance, and artificial intelligence come to mind) but asynchronous I/O is not one of them. (Except, maybe, in the non-io_uring-related way I suggested—the advent of much-higher-bandwidth access to large-capacity storage devices than I/O buses can handle—to which message-passing is even less applicable.)
It's perfectly fair to describe actors as "somewhat misunderstood" because the ways Hewitt himself understood it over the 50 years he developed the idea frequently contradict one another. At the end of his life he spent several years writing https://arxiv.org/abs/0904.3036v12, which describes his conceptualization of it at that time, which was very different from the early versions, though I think he would deny that. The versions on the arXiv only go back to 02009, but I am pretty sure the draft paper he showed me when I met him a few years before that was an earlier draft of the same thing.
The existing "asynchronous" I/O mechanisms that I am aware of all use a procedural interface...which doesn't really work.
The first kind of procedural interface is what I would call "the simulation of synchronous I/O". So basic OS behavior that goes outside the procedural model supported in the programming language by suspending your process and going off to do something else while the I/O completes.
This has various problems, mainly the one of suspending your process, but it is nice and simple from the perspective of a program in the call/return architectural style because it never has to see anything outside its understanding of the world.
The attractive convenience and the intrinsic problems have led us to reproduce this mechanism at the process level, the kernel-thread level, the user-thread level and most recently the async/await level. The fundamental flaw remains: we are simulating a synchronous procedural interface on top of something that is very different[1]
Callback hell is another way of mapping asynchrony to synchronous procedural interfaces, but well...yikes. NT completion ports and the like are as well, and let's agree not talk about aio(4).
Asynchronous messaging such as that in io_ring is a different way of interfacing with asynchronous I/O, just like Erlang messages are different from synchronous procedure calls and synchronous RPCs. Instead of all communication being encoded in individual procedures, it is encoded in reified messages (the io_uring_sqe struct). These have an "opcode", the message name, and parameters.
Now you can ignore the completely different interface that is the point and instead focus on the underlying asynchronous I/O operations, but that is, well, missing the point.
I have built more asynchronous/message-oriented I/O APIs in userspace with and for Objective-S[2], and am personally very interested in how these could map to the io_ring kernel interface. I certainly agree with the poster's point that this is fundamentally different from what has come before. And again: the messaging interface to (inherently asynchronous) I/O, not the fact that there is some (procedural) mechanism for asynchronous I/O.
> Callback hell is another way of mapping asynchrony to synchronous procedural interfaces, but well...yikes. NT completion ports and the like are as well
NT IOCP are true async as all I/O in the NT kernel is asynchronous. It was a design principle.
This isn't my first interaction with Kragen on this site, so unfortunately I'm not sure all his criticisms are genuine. He's said a few interesting things, but the amount of stuff he's written about my post is well over twice the length of my actual post, so at some point you just skim read.
I'm not sure what you mean by "genuine". My criticisms are sincere, as always, though of course that is no guarantee that they are correct. I've certainly made every effort to ensure that they are, but I'm fallible. Do you think they are incorrect?
If you don't find my perspective of interest, you of course have no obligation to read it, but if I didn't think something like my comments were worth reading, I wouldn't have written them. It's true that they're longer than your post—but that's because your post is unfinished!
Sometimes my writing falls short of the mark, but in this case, other people seem to have found my comment worthwhile, and
I think that it turned out to be much higher quality than I had hoped. This time I think you're missing out by skimming.
Yeah, it's difficult for someone else to be of interest to someone so wrapped up in their ego they answer thoughtful critiques with lazy insults. Fortunately I have another audience.
On the other hand, the most interesting discussions to be had are the ones where the opponent disagees with you.
As this is hard for many people i learn to completely ignore any part that is not of interest.
The funniest instance was an infuriated coworker calling me names, ready to fight me. He must have raged on fir 10 whole minutes while i calmly looked at him without expession. After his rage my conclusion was that he was right and calmly told him he was, next shift we will do it the way you've described. If he was wrong i would just say NO.
2. Message passing isn't new, it is at least 50 years old even if you don't go further back than early Smalltalk and the Actor model.
3. The article wasn't "selling" anything, and certainly nothing new see (2). It was noting convergence from several directions on an old and somewhat misunderstood paradigm.