Delightful seeing someone so broadly colossal conservative, picking so many fights at once with folks doing things other than the classics. Yeah man, retrocompute your way to the future, the ancients had it right, this is all just nonsense.
Except... Ah...
> You wanna know what else didn't ship with async? The thing all your bullshit async websocket servers run on: Linux. Last time I checked, Linux, and the POSIX world in whole, seems to be doing just fine running the entire internet without it. signal, timerfd, epoll, kqueue exist. Guess what? That's all tokio and these runtimes are doing. They can't magically put something to sleep. The kernel is the one who's not bringing your CPU to a halt when your read isn't doing anything, not tokio
You seem to not have heard of io-uring. Yeah, Linux wasn't async. But it has become very very very good at async since 5.11 or 5.15 time frame, 2020/2021.
You can do just fine without it. But wow, you have to get a lot right & what's right is going to keep changing all the time depending on very specific vagueries of the individual workload. signal, timerfd, epoll, kqueue all have many enormously popular event loop libraries that wrap them, that need all kinds of tuning & strategies to make good use of.
Io-uring let's us throw way more over the wall to the kernel for it to have to handle. It involves less switches between kernel and user space.
Imo the definitive challenge in getting to next level systems is figuring out how to write languages where users can make good use of all the many io uring affordances, naturally. Tokio-uring is a decent start at letting tokio-uring async work, but if anything it's too conservative, isn't able to express & enable enough of the patterns users could be doing in io-uring. It predefines some narrow paths of use. Which is great, it's a fine async, but there's so much more we ought be mining, and it's a huge opportunity for any language to come out ahead & advance things if it can use Linux 's newfound async.
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.
Except... Ah...
> You wanna know what else didn't ship with async? The thing all your bullshit async websocket servers run on: Linux. Last time I checked, Linux, and the POSIX world in whole, seems to be doing just fine running the entire internet without it. signal, timerfd, epoll, kqueue exist. Guess what? That's all tokio and these runtimes are doing. They can't magically put something to sleep. The kernel is the one who's not bringing your CPU to a halt when your read isn't doing anything, not tokio
You seem to not have heard of io-uring. Yeah, Linux wasn't async. But it has become very very very good at async since 5.11 or 5.15 time frame, 2020/2021.
You can do just fine without it. But wow, you have to get a lot right & what's right is going to keep changing all the time depending on very specific vagueries of the individual workload. signal, timerfd, epoll, kqueue all have many enormously popular event loop libraries that wrap them, that need all kinds of tuning & strategies to make good use of.
Io-uring let's us throw way more over the wall to the kernel for it to have to handle. It involves less switches between kernel and user space.
Imo the definitive challenge in getting to next level systems is figuring out how to write languages where users can make good use of all the many io uring affordances, naturally. Tokio-uring is a decent start at letting tokio-uring async work, but if anything it's too conservative, isn't able to express & enable enough of the patterns users could be doing in io-uring. It predefines some narrow paths of use. Which is great, it's a fine async, but there's so much more we ought be mining, and it's a huge opportunity for any language to come out ahead & advance things if it can use Linux 's newfound async.