Opinions don't really matter. Solutions to real-world problems do.
To me, the fact that no one up to this day felt that the issues in this area was significant enough to warrant a fix or an alternative tells me that it's noise about nothing.
Do you not view io_uring or Windows IOCP as alternatives? Or the plethora of other non-POSIX IO extensions in Linux, such as splice and sendfile? SPDK and DPDK? There’s also Google’s Fuschia operating system, which is not Posix. I think it’s pretty clear that people are investing in a variety of alternative approaches.
To look at things from another angle, what if having had POSIX all these years actually made things more uniform, in the sense that we didn't have variance between systems as large as e.g. between a BSD Unix and a Lisp machine? What if that were our choices today. As it is the largest mainstream departure is maybe Windows.
They're great tools but they're not great abstractions. If you use them directly for all I/O, then every application in every programming language will end up looking JavaScript, which even with Promises is quite ugly. Promises aren't new; language designers avoided them as best they could for decades because they suck as abstractions.
Languages like Go do a great job at providing abstractions, and tools like io_uring and IOCP are useful for implementing those abstractions. But they're not ideal, either, nor are they necessary. Their value is diminished. Note that both io_uring and IOCP are implemented internally using thread pools that perform synchronous operations, not much different from how Go works when using traditional BSD Sockets interfaces to implement its abstractions. io_uring and IOCP have access to some optimizations, but the basic model remains the same.
If you read between the lines (discussion of pthread complexity, emphasis on virtual memory, which is fundamentally blocking) I think the author is implicitly making the same argument--that better abstractions would make synchronous threading more efficient and easier, and these should be available as a basic application primitives, rather than relying on languages and third-party runtime engines to build atop more coarse-grained primitives, io_uring and IOCP included.
I don't simply due to the fact that no one ever bothered to put something together on UNIX-like systems that resembles any of those options.
If anyone felt that those were worthy ventures, in these last few years we would already have seen something resembling that effort. But we haven't.
What do you mean? io_uring is a Linux kernel interface, and there are several userspace projects that are building upon it.
yes, let's just ignore the mountains of people who end up literally reimplementing complete network stacks in userspace to handle events in a modern way
Who are they, exactly, and why haven't anyone from that mountain thought it would be a worthy investment of their time to pull it off?
I see you complaining that people have to implement things, but why has no one ever implemented the thing you perceive to be so invaluable?
Don't get me wrong, there are lots of room for improvements in POSIX IO interfaces. For example, POSIX doesn't define any modern event systems (epoll, kqueue, etc). But what's the result? We use libevent/libev.
This sort of seems like the result he's asking for in diverging from POSIX, which we ... already have. There are a lot of pretty great non-posix standard interfaces available too!
Most forms of async programming are also unstructured, which is bad for correctness, but also for performance since it can lead to priority inversions.
I don't think he's wrong that the POSIX synchronous IO model isn't a great fit for modern hardware, though. He doesn't really go into it much but (Windows) NT's async-everything IOCP model really seems to be the winner, as far as generic abstractions that have stood the test of time.