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 ?
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.
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.