6 ms·
I agree, and even as someone who holds Rust in high regard, I’m becoming increasingly frustrated by this. There doesn’t seem to be one clear root of this proble
by codeflo 5y ago
I agree, and even as someone who holds Rust in high regard, I’m becoming increasingly frustrated by this. There doesn’t seem to be one clear root of this problem.
Some of it is the language not being designed with ease of compilation in mind, unlike let’s say, to pick an extreme example, Go. Some of it is the tooling and default settings, especially around incremental compilation, linkers etc. People are working on this, but it takes time.
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.
In the C++ world, the popular “boost” library has a similar problem, and I know shops that avoid it, or large parts of it, simply because the compile times would be unbearable. I really hope that parts of the Rust community start to make similar decisions.
- vladvasiliu 5y ago> 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.
- gameswithgo 5y agoYes, 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.
- ModernMech 5y agoHold 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.
- pjmlp 5y agoMainly 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.
- ModernMech 5y agoIncluding 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.
- pjmlp 5y agoMy 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.
- ModernMech 5y agoI 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.
- aliceryhl 5y agoTokio 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.)
- formerly_proven 5y agoSo 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.
- jhgg 5y agoIt allows for things like https://docs.rs/typed-html/latest/typed_html/ https://docs.rs/typed-html/latest/typed_html/ to exist.
- dom96 5y agoThis 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.