5 ms·

I recently started a Rust project coming from mostly writing Haskell in my job and oh boy was I surprised. I was expecting long compile times because of the com

I recently started a Rust project coming from mostly writing Haskell in my job and oh boy was I surprised. I was expecting long compile times because of the complaints I read about everywhere. But in fact compilation is very speedy. Much, much faster then I'm used to with GHC in fact.

zamalek 4y ago
It has significantly improved, and I mean significantly, even in the past year alone.
- silverwind 4y ago
  According to https://perf.rust-lang.org/dashboard.html https://perf.rust-lang.org/dashboard.html compile times only have improved by like 5-10% since last year.
  - rowanG077 4y ago
    That's pretty huge though.
    - estebank 4y ago
      And that's only for the aggregate, specific codepaths/code patterns got significantly faster in order to contribute to those numbers. The biggest improvement I see is 68% (bitmaps crate) back in May 25th. https://perf.rust-lang.org/index.html?start=2022-01-01&end=&kind=percentfromfirst&stat=instructions%3Au https://perf.rust-lang.org/index.html?start=2022-01-01&end=&... (takes a while to load, too many datapoints for 6 months at once)
indiv0 4y ago
1. Don't use the `async` ecosystem. 2. Prefer dynamic dispatch to monomorphization (i.e., use fewer generics). 3. Don't use proc macros (i.e., don't depend on the `syn` crate, even transitively). Easy to say; hard to put into practice. But that's all there is to it.
- fasterthanlime 4y ago
  > Don't use the `async` ecosystem. I want to make it /very/ clear that async isn't to blame at all for the pathological build times described here. It's a bug about traits and lifetimes, both very core concepts of Rust that you deal with even if you stay away from async code. async rust will certainly be more ergonomic once some more improvements land (hopefully later this year), but I don't feel like it deserves all the sighs it's been publicly getting these past few months. (And I /love/ to complain. I've written pieces named "Surviving Rust async interface", "Getting in and out of trouble with Rust futures", "Pin and suffering", etc.) > Prefer dynamic dispatch to monomorphization (i.e., use fewer generics). Unless you hit a pathological case as shown in the article, it tends to not be _that_ bad, especially if you enable `-Z share-generics=y` (unstable still, yet enabled by default for debug builds if I remember correctly). Overall still solid advice - although "use fewer generics" sometimes turns out to be "just turn a big generic type into `Box<dyn Trait>`" (it's not _just_ boxing, that would be `Box<T>`). That's what axum[1] does with all services, and it's never had the compile times issues warp[2] had, for example. > Don't use proc macros (i.e., don't depend on the `syn` crate, even transitively). Good news there, I hear there's some progress on the proc-macro bridge (which improves macro expansion performance) AND "wasm proc-macros". I hope this piece of advice will be completely irrelevant in a year (but for now, it's spot-on. using pin-project-lite instead of pin-project is worth it, for example). [1] https://lib.rs/crates/axum https://lib.rs/crates/axum [2] https://lib.rs/crates/warp https://lib.rs/crates/warp
  - vgel 4y ago
    My understanding of point #2 is that LLVM may still try to devirtualize the call, which would reduce the performance impact -- is that true for Rust? I know it happens sometimes in C++. Also for proc macros, rust-analyzer seems to struggle with them sometimes as well, so I try to avoid them (outside Serde, which is worth any price) for that reason.
    - afdbcreid 4y ago
      rust-analyzer for a long time expands all kinds of proc-macros. The only project it does not work (although to be honest I didn't really tried) is rustc.
p1necone 4y ago
AFAICT most of the talk about Rust having slow build times is a combination of kneejerk FUD from people that don't like Rust for other ideological reasons, and people that last used Rust when it was much earlier in development. (And also people that have some massive project with hundreds of dependencies that would be slow to build in any language)
oxff 4y ago
I think a bunch of the "rustc compiles slow" talk comes from the misunderstanding of what rustc does. For example, to do the same things as `rustc` but using C++, you need to run external runtime modifying program to check your program for memory errors .. so that extends your C++ "compile time" by fair amount to even begin to match what rustc does.
- pjmlp 4y ago
  Or use modern IDEs that run the static analysis in the background already spotting many of those issues before the build takes place.
- jstimpfle 4y ago
  The question would be for me, can we run those slow-rustc cases faster by skipping the part corresponding to "external checker program"? Or is that part required for each and every build, even after tiny changes or no changes at all?
  - oxff 4y ago
    Well, you are asking about disabling borrow checker here, one of the main selling points of Rust and rustc here so I think that's out of the question. When you do full comparison of what rustc does, and compare it to what you need to do in C++ project to match it, the compile times aren't actually slow since rustc does more with actual guarantees.
    - jstimpfle 4y ago
      But that was my point, I don't necessarily want to do more. In general I want results faster, and am not willing to trade build speed for more safety checks unconditionally. Having some additional features and checkers is nice, and can even be a life saver, but having to pay a high cost each time I hit compile is not acceptable.
      - PoignardAzur 4y ago
alpaca128 4y ago
I don't get the complaints either, especially because so many people seem to treat it as an actually serious issue and not just the meme it is. Yes, many other compilers are faster and produce smaller binaries. But it's not that bad and I get incredible value out of all the checks done by rustc. Incremental builds are reasonably quick and produce excellent error messages. When it comes to efficiency optimizations I see much lower hanging fruits in the web space, some TypeScript projects I'm working on take longer to fully start the dev setup than a fresh optimized Rust build. I hope Bun will make the difference it promises.
- hinach4n 4y ago
  It gets pretty bad as your codebase increases. I work on a pretty large Rust project that uses a lot of async, and uses a LOT of static dispatch (mainly because we use a web-server framework called warp). Usually, even after a simple change a simple `cargo check` can take a minute or two on a beefy PC. That said, over time you get numbed to it :D.
  - alpaca128 4y ago
    I can't say much about async because I never really use it. To me it feels like a slightly misleading abstraction/syntax compared to what actually happens, most bugs I introduced in JS backends happened because async/await made the code look more synchronous than it is. Maybe that's just me.

zamalek 4y ago

It has significantly improved, and I mean significantly, even in the past year alone.

silverwind 4y ago
According to https://perf.rust-lang.org/dashboard.html https://perf.rust-lang.org/dashboard.html compile times only have improved by like 5-10% since last year.
- rowanG077 4y ago
  That's pretty huge though.
  - estebank 4y ago
    And that's only for the aggregate, specific codepaths/code patterns got significantly faster in order to contribute to those numbers. The biggest improvement I see is 68% (bitmaps crate) back in May 25th. https://perf.rust-lang.org/index.html?start=2022-01-01&end=&kind=percentfromfirst&stat=instructions%3Au https://perf.rust-lang.org/index.html?start=2022-01-01&end=&... (takes a while to load, too many datapoints for 6 months at once)

indiv0 4y ago

1. Don't use the `async` ecosystem. 2. Prefer dynamic dispatch to monomorphization (i.e., use fewer generics). 3. Don't use proc macros (i.e., don't depend on the `syn` crate, even transitively). Easy to say; hard to put into practice. But that's all there is to it.

fasterthanlime 4y ago
> Don't use the `async` ecosystem. I want to make it /very/ clear that async isn't to blame at all for the pathological build times described here. It's a bug about traits and lifetimes, both very core concepts of Rust that you deal with even if you stay away from async code. async rust will certainly be more ergonomic once some more improvements land (hopefully later this year), but I don't feel like it deserves all the sighs it's been publicly getting these past few months. (And I /love/ to complain. I've written pieces named "Surviving Rust async interface", "Getting in and out of trouble with Rust futures", "Pin and suffering", etc.) > Prefer dynamic dispatch to monomorphization (i.e., use fewer generics). Unless you hit a pathological case as shown in the article, it tends to not be _that_ bad, especially if you enable `-Z share-generics=y` (unstable still, yet enabled by default for debug builds if I remember correctly). Overall still solid advice - although "use fewer generics" sometimes turns out to be "just turn a big generic type into `Box<dyn Trait>`" (it's not _just_ boxing, that would be `Box<T>`). That's what axum[1] does with all services, and it's never had the compile times issues warp[2] had, for example. > Don't use proc macros (i.e., don't depend on the `syn` crate, even transitively). Good news there, I hear there's some progress on the proc-macro bridge (which improves macro expansion performance) AND "wasm proc-macros". I hope this piece of advice will be completely irrelevant in a year (but for now, it's spot-on. using pin-project-lite instead of pin-project is worth it, for example). [1] https://lib.rs/crates/axum https://lib.rs/crates/axum [2] https://lib.rs/crates/warp https://lib.rs/crates/warp
- vgel 4y ago
  My understanding of point #2 is that LLVM may still try to devirtualize the call, which would reduce the performance impact -- is that true for Rust? I know it happens sometimes in C++. Also for proc macros, rust-analyzer seems to struggle with them sometimes as well, so I try to avoid them (outside Serde, which is worth any price) for that reason.
  - afdbcreid 4y ago
    rust-analyzer for a long time expands all kinds of proc-macros. The only project it does not work (although to be honest I didn't really tried) is rustc.

p1necone 4y ago

AFAICT most of the talk about Rust having slow build times is a combination of kneejerk FUD from people that don't like Rust for other ideological reasons, and people that last used Rust when it was much earlier in development. (And also people that have some massive project with hundreds of dependencies that would be slow to build in any language)

oxff 4y ago

I think a bunch of the "rustc compiles slow" talk comes from the misunderstanding of what rustc does. For example, to do the same things as `rustc` but using C++, you need to run external runtime modifying program to check your program for memory errors .. so that extends your C++ "compile time" by fair amount to even begin to match what rustc does.

pjmlp 4y ago
Or use modern IDEs that run the static analysis in the background already spotting many of those issues before the build takes place.
jstimpfle 4y ago
The question would be for me, can we run those slow-rustc cases faster by skipping the part corresponding to "external checker program"? Or is that part required for each and every build, even after tiny changes or no changes at all?
- oxff 4y ago
  Well, you are asking about disabling borrow checker here, one of the main selling points of Rust and rustc here so I think that's out of the question. When you do full comparison of what rustc does, and compare it to what you need to do in C++ project to match it, the compile times aren't actually slow since rustc does more with actual guarantees.
  - jstimpfle 4y ago
    But that was my point, I don't necessarily want to do more. In general I want results faster, and am not willing to trade build speed for more safety checks unconditionally. Having some additional features and checkers is nice, and can even be a life saver, but having to pay a high cost each time I hit compile is not acceptable.
    - PoignardAzur 4y ago

alpaca128 4y ago

I don't get the complaints either, especially because so many people seem to treat it as an actually serious issue and not just the meme it is. Yes, many other compilers are faster and produce smaller binaries. But it's not that bad and I get incredible value out of all the checks done by rustc. Incremental builds are reasonably quick and produce excellent error messages. When it comes to efficiency optimizations I see much lower hanging fruits in the web space, some TypeScript projects I'm working on take longer to fully start the dev setup than a fresh optimized Rust build. I hope Bun will make the difference it promises.

hinach4n 4y ago
It gets pretty bad as your codebase increases. I work on a pretty large Rust project that uses a lot of async, and uses a LOT of static dispatch (mainly because we use a web-server framework called warp). Usually, even after a simple change a simple `cargo check` can take a minute or two on a beefy PC. That said, over time you get numbed to it :D.
- alpaca128 4y ago
  I can't say much about async because I never really use it. To me it feels like a slightly misleading abstraction/syntax compared to what actually happens, most bugs I introduced in JS backends happened because async/await made the code look more synchronous than it is. Maybe that's just me.