Reupping a post I wrote a few months ago: How and why #Nextest uses #RustLang #Tokio.

This post delves right into the heart of why async Rust exists: to perform *heterogenous selects*. Previous explanations have always been a bit unsatisfying for me. It's more efficient than OS threads, but is that really it? In reality, async Rust satisfies a fundamental need that no other paradigm does, which is to use tokio::select! across arbitrary async sources and platforms.

https://sunshowers.io/posts/nextest-and-tokio/

How (and why) nextest uses tokio :: sunshowers

How my open source test runner uses async Rust.

How (and why) nextest uses tokio
In the post I show how async #RustLang solves practical select problems in #Nextest, and does so in a deeply principled, composable manner. I'm really proud of it because I've taken a view that has been talked about in 1:1 messages and discussions in the past, but hasn't really been written down like this before to the best of my knowledge.
So much of the discussion around async has revolved around "c10k", or massively concurrent network services. While that's grabbed the spotlight, it's really more of a side benefit in my opinion! Almost every network service, "c10k" or not, and many programs that have nothing to do with the network, need to do heterogenous selects.

@rain IMO, tokio has historically over-indexed on c10k to the detriment of those other use cases, especially stuff like unix domain sockets on windows.

I think tokio is good, but I think `smol` and its family of crates are much more amenable to hacking into things that don't need to scale up so much.

(I'm overdue to take another look at whether I could use tokio in place of smol in wezterm: it's possible things have evolved since I last looked!)

@wez Huh, would love to hear what issues you ran into.

From my perspective one of the big things tokio provides is its *significantly* better select macro. The standard futures::select macro is not well designed and misses many use cases.