Tokio maintainer here. I've actually been spending a bunch of time recently looking in to how we can reduce Tokio's compile-times. I haven't really been able to find any big wins yet, but one thing has been pretty clear from the benchmarks: The number of dependencies of Tokio is not the problem. They all compile pretty fast and can all compile in parallel. Tokio itself takes a lot longer than the dependencies.

(Except for tokio-macros which takes a long time because it depends on syn and quote. Consider disabling it if you don't need it.)

So I've read "syn" and "slow rust compiles" in pretty much every discussion of "slow rust compiles" and finally googled it and... syn is a Rust parser? For use in macros? Because procedural macros operate on tokens and not an AST? Hm. I'm sure there are reasons for how it ended up like this, but it does smell kinda funny.

If I recall the reason is "rustc's representation of the AST is an implementation detail and unstable, thus macro code may not rely on it (and it will not be exposed)". Hence "syn" came along and provided a stable API and format. "quote" is the inverse function, turning an AST back into tokens.

It allows for things like https://docs.rs/typed-html/latest/typed_html/ to exist.

This is quite interesting. Is `syn` just an interface to the Rust compiler's Rust parser or is it a completely separate implementation of the parser that works at compile-time?

Hopefully it's not the latter but then I wonder where the slowness comes from.

it's a completely separate implementation of the parser

I wish that the proc_macro API from the compiler would do that instead.

syn also let's you define your own parsers for non-Rust syntax, way beyond what rustc could provide.

Macros.

This is a major pain. I wish it get more attention (and hopefully: How about a SINGLE way to do macros? Like zig?).

Serde is another killer on compiling speed.

Well, one of the advantages of having two ways to do macros is that macro_rules! macros are much much faster than procedural macros.

Yeah, but then why not make it the only one? One reason is that proc-macros can "see" the syntax outside the point of declaration(or enclosed). This means you must do macro_rules! {struct.... } instead of declare the struct first then forward it.

First of all, Tokio is my favorite async framework, so thank you and the Tokio team! And second, I appreciate that cargo/rustc compiler errors are clear, helpful, and guide me toward cleaner and thread-safe coding where most other languages happily let me create unsafe hidden race bugs all day long with no warning … oh but they compile so much faster! (I don’t care) The slower compile time really doesn’t bother me when I’m getting a more stable end result… but I’m glad the maintainers are working on improving compile time anyway.

To me the extra compile time makes sense when rust is showing me many unsafe coding issues that languages seem to ignore even with their strict warnings enabled.

… and I don’t get all of the complaining about rust. I’ve written code in a lot of languages and rust has its quirks too, as they all do, but I really like it!

> But unfortunately, a lot of the problem is with the ecosystem, as hinted at in the article. There seems to be no limit to the amount of code bloat and compile time complexity that people are willing to accept to win some microbenchmarks. This includes some very popular crates with lots of dependents, like Tokio.

But isn't this the right trade off for something like Tokio which is at the base of applications which expect to be fast? Or else those applications wouldn't bother with async runtimes and what-have-you. There's also the fact that during the dev cycle, you'll compile tokio & friends once and be done with it. And for CI pipelines, there's caching.

I'm however not a professional developer, so I'm curious if I'm missing something.

Yes, a slow compiletime of a dependency is less painful since you don’t do full recompiles that often, but things can spiral out of control if you have say 50 dependencies and many of them are real slow and you are on your old dual core laptop and find it takes hours, and so on.

Hold up, this is some severe goalpost moving. I realize these comments are coming from different people, but this thread started at:

“tribal knowledge required to bypass it, so early in the the life of a programming language, is a really bad sign.”

and within a few replies we ended at (paraphrasing):

“Granted compilation time is incremental, libraries are only compiled once, debug mode is much faster, but it’s really going to be an issue with a huge project on absurdly obsolete hardware.”

As the author of a project that relies on 50+ projects with some massive dependencies (wgpu, Tokio, rayon), yes it can take a good long while to compile from scratch, but it’s not “hours”, and after first compile that’s all paid for going forward.

Honestly this all seems like grasping at one of Rust’s perceived weak points, but really there are so many better criticisms, I don’t know why compile time gets so much attention.

Mainly because not everyone is willing to buy a last generation threadripper to have the same workflow as apt/yum/rpm/NuGet install libXXX-dev + make.

Including me! There’s a lot of daylight between “an old dual core laptop” and a last gen thread ripper. For example, I’m running on a quad core i7 from 2015.

My old dual core laptop from 2009 works just fine with Visual Studio 2022, even though I wasn't the OP.

And long compile times kill the battery on the go, and cargo check hardly helps when writing GUI code.

I don’t think I follow the point you’re trying make. Are you trying to say Rust compile times are a problem for you on your 13 year old laptop in the context of writing GUI code on battery? If so I think that’s such a specific scenario that it’s hard to draw any generally applicable conclusions.

I also own devices like laptop graphics workstations.

The point I am making is Rust only for those with enough income to buy hardware powerful enough to have a usable workflow or for anyone regardless of what hardware they can afford?

As for coding on the go, classical desktops are a dying breed.

Your laptop from 2009 predates even Rust's earliest stable version by 6 years. Including computers that are older than the language itself is completely unreasonable.