I think the best part about smol is its composability.

Unlike tokio which consists of one large integrated library, smol provides many smaller, mostly runtime-agnostic crates e. g. blocking to run blocking I/O on a thread pool or async-lock for async lock primitives.

A good topic to chat about.

But before that, I should mention that I had to use the browser’s inspector to disable that background color. Light and dark backgrounds are both fine (I have color inversion bindkeyed after all). It’s the ones in the middle like this one that are a no-no.

And while you could exclusively use the runtime and ignore the rest, it is easier and more common to buy into the entire ecosystem.

Stats? User surveys?

I would expect that many users (including myself) actually just use the runtime, directly or indirectly (e.g. via async-global-executor with the tokio feature), while API usage is covered by crates like async-io, async-fs, async-channel, blocking, …etc.

In fact, I would hypothesize that, from an ecosystem adoption POV, tokio’s only killer feature is hyper’s dependence on it. If it wasn’t for that dependence, tokio’s adoption, I would expect, would be much lower. But this is admittedly anecdotal.

Any time we reach for an Arc or a Mutex it’s good idea to stop for a moment and think about the future implications of that decision.

This and the quote above it seem to be Rust intellectuals’ flavor of the month position.

It kind of reminds me of the lowering dependencies’ compile times craze from a few years ago. Stretching the anti-MT-RT narrative to the point of making bad advice like recommending sync channels for an IO task adds to the parallels.

The choice to use Arc or Mutex might be indicative of a design that hasn’t fully embraced the ownership and borrowing principles that Rust emphasizes.

Or maybe you know, using APIs that already existed in std for a reason, as intended!

It’s worth reconsidering if the shared state is genuinely necessary or if there’s an alternative design that could minimize or eliminate the need for shared mutable state.

Generally true. But probably false here.

People reaching for Arc+Mutex/RwLock/… (doesn’t have to be a Mutex) in asyc code are probably aware of alternative designs, but still decide to use Arc+Mutex/RwLock/… when it’s either necessary, or when it actually makes things simpler, and the downsides (performance) are of no measurable relevance, or the alternative design is actually slower (i.e. the multi-threaded runtime is actually helping).

I would consider arguments that talk about “killing all the joy of actually writing Rust” in this context as either intellectual posturing, or simply disingenuous.

Otherwise, there is not much to disagree with.