[topspin]

It's a mixed bag of a blog post. Reading it, and your response, I see all of this as growing pains. The Rust async split mentioned in the post is a legitimate issue. It's also a consequence of immaturity. Rust async underspecified async runtimes and, naturally, incompatible async runtimes emerged and leak all over. The shrapnel of that plagues crates.io. A thoughtful post about this is found here[1]. On the other hand io_uring, new and immature as it is, suffers from security problems, to the point it's been turned off on important platforms, like containerd (by default,) Android, ChromeOS and elsewhere.

As for the actual need for Rust async: there is a real point here as well. While many applications have no actual need for the benefits of Rust async for the bulk of their code, nearly all of them are using it pervasively because that's what the dependencies they're using have been built on. Why? The best answer I can offer is "webscale anxiety": if your thing can't at least theoretically claim to handle Cloudflare levels of IO concurrency out of the box it's garbage, apparently, and no one will consider it. An ecosystem wide case of premature optimization. The cost of that is all the great things that might be done in Rust, but aren't, either because the attempt failed after the developers gave up trying to cope with Rust async, or they've already been through that one or more times and forego Rust by default.

The good news is these problems are all solvable with time. I cling to that hope because Rust and io_uring are both awesome innovations and deserve to survive and thrive.

[1] https://corrode.dev/blog/async/