Is tokio unavoidable for distributed / scaleable Rust?

I have been obsessive so far about keeping rust 'incremental build' time down, currently at 1-2 seconds; this has involved ignoring many of the larger / more popular libraries.

Recently, I have been looking at building distributed services in Rust and nearly every library I have looked at depends on tokio.

Question: for distributed / scaleable Rust, is tokio unavoidable ? If avoidable, what are alternative tech stacks ?

1 Like

tokio is basically an async-runtime. Async in Rust depends on the presence of a runtime, since the language itself doesn't ship with one. There is nothing hallowed about tokio - you can roll your own async runtime as well, although admitedly it is quite difficult.
That said, I don't see why tokio would slow down incremental builds. Tokio would be built once - incremental rebuilds re-compile only the code you have yourself written and changed.

There is also async-std. I have no idea of the merits of async-std compared to tokio. My general impression is that tokio is more widely used, but both are fine.

I think tokio is reaching escape velocity as the default way to write asynchronous rust code. I understand wanting to keep compile times down, but there is some fundamental increase in complexity when you start to make everything async.

If you think gravity is pulling you in that direction, I would bite the bullet now and start to play around with tokio.

While I have been and remain a strong advocate for Rust. if you want to build lots of distributed async stuff the learning curve is gentler in Go.

I believe tokio has more sophisticated scheduling as described here and a timer wheel implementation, while I think smol uses a more naive but simple task stealing logic and BTreeMap for timers. Thus tokio could show improved performance when pushing a system to its limits, depending on the workload.

I'm also impressed by tokio's concurrency correctness testing infrastructure..

1 Like

Maintainer of Tokio here. Generally, Tokio provides a lot of feature flags, and disabling the ones you don't need can have a significant impact on compile times if there are a lot you don't use. Although, of course, if you do need most of the feature flags, then that doesn't help you much.

As for alternatives such as async-std, I would also expect them to have similar compile time costs as Tokio does.


This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.