Hacker News Reader

Comment by aliceryhl | Hacker News Reader

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

View on HN

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!

Reply on news.ycombinator.com