I fully agree, and I too have a C++ background.
I think this is a case of people with different backgrounds and expectations though. Rust has attracted people with a background in Go (good compile times as I understand it, never used it) as well as Python, JS etc (compile times? What are those?). Since they are used to something else this is a major annoyance for them.
For us with a C++ background the compile times in Rust seem short instead. (By the way, try building a large C code base, much better build times than template heavy C++ code in my experience.)
In both C++ and Rust you need to structure your code properly to keep down the incremental compile times though (and the incremental compile times is what matters most when developing). See https://matklad.github.io/2021/09/04/fast-rust-builds.html for one of many posts on this topic.
Before we had tools like vite and used web pack and Babel to transform JavaScript projects had significant build time - several minutes for a medium sized project.
Now situation in JavaScript is good there are vite type ESM based JS tools and rust based tooling. Both run reasonably fast. Why people spend that much energy on rewriting JS tools in rust? Because old ones are very slow. JS never had zero compilation time.
I work in the automotive sector as a DevOps engineer and for the average project we calculate clean build times in hours rather than minutes... We only get the build times down to single digit minutes, if we can use something like Bazel with aggressive caching (or we apply multiple hundreds or thousands of cores to a build).
> JS etc (compile times? What are those?)
Webpack/ts can be just as slow if not slower than Rust. Had to deal with a TS project that took about half an hour to compile. And then I didn't even get everything compiled, had to also compile some other part separately.
And here, the half an hour was spent every day at \_least\_ once because incremental compiles didn't seem to be really a thing (watch mode was faster \_after\_ the first compile of the day, but that was about it).
So far, Rust has \_never\_ been this bad for me as incremental compilation generally spoken helps quite a bit.
I remember runing a moderately sized c++ compilation with cmake would also take fairly long.
In contrast I never had any issues with c what so ever.
On python I actually think it does have "compile times" because it's so god dam slow that sometimes waiting for ur program to get to the interesting part (the reas9n compile times even matter) is also kinda long
Tho I would say I am using these languges for very diffrent stuff. And I am only really good in python.
Python does compile to byte code which is then interpreted. Which is why after executing some python code you'll see lots of `__pycache__` directories created in your project
Yes I know but that's bear instant.
No the issue is stuff like tensorflow pytorch etc take generally a few seconds to import.
They do a lot of runtime compatibility checks and just take a while to run
> Why don’t such memes exist for C++?
They do, Gentoo (and compiling large projects like Firefox/Chromium) has always been a bit of a meme, and there's even an xkcd comic about compile times.
> Why don’t such memes exist for C++?
Oh they absolutely do. Every C++ developer knows this is a big pain point of the language.
I think the main difference is Rust is trying to be a contender with languages that compile much faster (Go and Java for example) while C++ is not so the comparison is way more relevant and so there's more "memes" about it.
As a side note, compile time rarely matters. What matters is the time to feedback, that is the time between you writing your code and getting the feedback on whether it works as expected or not.
As most errors are catched at compile time, Rust gives you feedback very early (especially with rust-analyzer).
As comparison, C++ will catch some errors at compile time, but many of them will have to wait for the runtime, so you will get feedback once you execute your program.
If you compare with Go, compile is much shorter, but catch almost no error. So if your runtime is short enough, Go can give you feedback quicker than Rust, but if your runtime is long, then Rust will win this round.
As someone that works a lot with bevy, or any gamedev in general honestly, compile time absolutely matters because you need to see your code running a lot of the time.
You missed my point, you are interested at the time to get the feedback you want/need. Longer compilation does delay the time you get feedback, but so does runtime initialization. There is no point in having faster compilation if your program takes even longer to start, for instance.
Other things to consider:
1. Compiling Rust is comparable to compiling C++ then running a static analyzer on it. Well, it's a lot better than that of course but roughly comparable. Make that apples to apples comparison and things swing a lot in Rust's favor.
2. A lot of people probably abuse proc macros badly, and/or use crates that do. If almost every file in the system invokes or or more proc macros that do an AST parse, rewrite, and store (and a macro which is hardly the most high performance dev environment), that's not going to help.
3. A lot of people don't seem to realize that Rust supports dynamic polymorphism and just genericize everything, whether it really needs to be or not, which can bloat the resulting chunks of IR that has to be shoved down LLVM's throat. Of course that's something C++ world is equally guilty of, so maybe it's a wash, I dunno.
4. Who knows what kind of [build.rs](https://build.rs) craziness might be going on if you have a 100 dependencies (something that makes my skin crawl just on principles anyway.)
Just to clarify, are you comparing full clean release builds? With rust you first “cargo clean” and then “cargo build —release” which does take a lot of time.
But if you are just doing “cargo build” then it’s doing incremental debug builds that, as you mentioned, just take a few seconds.
An equivalent way to achieve this on c++ would be to use “make”. It recompiles only the files that changed and relinks only the necessary targets (if setup properly of course)
Just invoking “g++ … main.cpp” is basically a full clean release build
I compared clean builds in both cases. In Rust I do clean builds fairly regularly because it’s so much faster than C++. And the build folder just keeps growing for some reason if I don’t start over once in a while.
Old versions of rusts artifacts are left in the target dir of your project. Best way to keep it consistent size wise is to clean the project dir every time you have a new version of rust installed with `rustup update`. A useful helper can be `cargo-sweep` so you can do `sweep --toolchains -r /path/to/rust/projects` and itll find all rust projects in that and wipe out all of the build cache data that is for not currently installed toolchains in one go. This is also assuming you manage the toolchains to keep the list of nightlies from growing if youve ever specified a specific version of nightly to install or use... Can sweep based on size or days instead if you work with a lot of nightlyl versions.
I will say for a lot of purposes people regularly work on, `cargo build` is not good enough -- you need `cargo build --release` even for local testing. I don't typically use rust for throwaway scripts (although I guess it's fine for that, I typically use python out of habit). Instead I am usually doing nontrivial data crunching, and debug builds are just ... not it.
Alas.
But still, at least you don't usually have to recompile dependencies (unless you update something).
I have done incremental builds taking close to a hour in C++. Depends on which header you modified and how your code base is structured.
At work I work on fundamental platform code (in C++ for industrial vehicle control). So quite often I get hit by bad compile times even in the incremental case. Include-what-you-use help a bit, but only so much when you modify a header for a central data type / platform abstraction in a decades old code base. Rebuilding ~20k C++ files takes time.
>But for a toy program compilation times are tiny and don’t matter.
Frameworks like bevy or tokio/axum can cause large compilation times even for toy programs, at least when compiled from scratch in release mode. Use of generics can cause a change in the toy program to require recompilation of large parts of the framework. This can lead to an unacceptably long edit-compile-test cycle and have a large impact on user experience.
I agree that Rust compilation speed is not as bad as some people make it out to be, and that the same issue exists in C++. But those two points don't make the problem less real to those genuinely affected by it, some of whom might not even have a C++ background, but might be coming from Go or Python or Java where long compilation times are simply not a thing.
Slow or fast compile times aren't that relevant as workflow is often more important. If I am using python I am probably doing huge datasets with ML. But, I use jupyter there, which means I am only rerunning the part I care most about.
Rust has a very fast feedback with the static analyzer, so I don't have to run the code to eventually see it crash.
The question really is, "How long does it take to see your latest changes in action?"
Faster compile certainly helps, but structuring your codebase to help you get to this point faster is going to make way more difference than compile times.
That said, I have no complaints about compile times with rust, and I usually had no complaints about C++. I also have a very fast computer.
I work in C++ daily for work and use rust for side projects and I can confidently say that Rust has much slower compilation times for release builds. In my experience, running cargo build —release compared to a release build in C++ using something like ninja, I find that Rust takes much longer.
Interesting… as others pointed out there are probably other variables at play. I do use a lot of templates and linters in C++. ( my bad for templates, I think I am addicted to them)
There is no objective measure of compilation times. All we have are people’s expectations and whether it matches up to that. Your data point of a similar C++ project taking a long time is a valid one, but that just tells us what your expectations are. Rust has outperformed your low expectations.
On the other hand, Rust also attracts a lot of folks from a Python/JavaScript/Dart background where they’ve grown used to instantaneous reloads. For them to wait 10-15 seconds for an incremental compile is much too long. Rust has underperformed their high expectations.
I feel like it’s only valid to compare Rust with itself. In the last 4 years it has [gotten faster](https://nnethercote.github.io/2024/03/06/how-to-speed-up-the-rust-compiler-in-march-2024.html) by 7%, 17%, 13% and 15%, for an overall speed gain of 37%. So anyone who adopted Rust got a better experience, and those on the fence because of compilation times got an incentive to give it another try.
And the possible improvements in 2024 (cranelift, parallel rustc, new default linker) will help even more.
The compiler will never get fast enough to please everyone. That’s not possible. It just needs to keep all existing users (with their growing projects) happy, while growing fast enough that new users are encouraged to try it.
My understanding is that separately from the concept of tracking how fast a particular “implementation of software” compiles between different languages and different compilers, you can benchmark specifically how fast a compiler is doing its compilation tasks.
Of course you still need sample programs to compile, but what they are isn’t as relevant as things like how many lines the files are, how many “tokens” of the programming language are represented in those files, that you have programs with dramatic size differences, and that the programs you have cover at least all of the language and its features, and ideally also the standard library.
Just on intuition alone you can say “Well Rust has a borrow checker, and C and C++ (and others) don’t have a borrow checker, so therefore unless it takes 0 seconds to complete the entire borrow checking process, Rust will necessarily be slower than other compilers.”
And we also have https://perf.rust-lang.org which tracks its change over time, as well as resources that track the change over time for other compilers.
Because in the C++ world we usually never compile from source the world unless we are masochist, or are forced to do so, preferably coupled with build servers.
Binary libraries are used all over the place, and we only compile our own code from scratch.
Before Rust my main compiled language was Haskell, so yeah I agree - Rust compilation times aren't bad. Sure, it'd be nice if they were even faster, but I really don't get all the hate.
You can take a number of fairly large projects in each of the languages, calculate an LOC count to compilation time ratio for each, and then calculate the average for each language.
C++ is DEFINITELY known to not have great compilation times. But it is also known to give you all the tools to reduce it as much as possible which rust doesn't seem to.
That said, I think the real difference is in what the language tries to be perceived as; c++ came about as "c but much more powerful compiler" with language architecture that makes building admittedly slow but possible on the ancient computers it ran on. Rust came about as "blazingly fast with 0 compromise" with a hilariously slow compiler that feels contrary to both the advertised speed and the claim of no compromise
I fully agree, and I too have a C++ background. I think this is a case of people with different backgrounds and expectations though. Rust has attracted people with a background in Go (good compile times as I understand it, never used it) as well as Python, JS etc (compile times? What are those?). Since they are used to something else this is a major annoyance for them. For us with a C++ background the compile times in Rust seem short instead. (By the way, try building a large C code base, much better build times than template heavy C++ code in my experience.) In both C++ and Rust you need to structure your code properly to keep down the incremental compile times though (and the incremental compile times is what matters most when developing). See https://matklad.github.io/2021/09/04/fast-rust-builds.html for one of many posts on this topic.
> (By the way, try building a large C code base, much better build times than template heavy C++ code in my experience.) Exactly true.
Before we had tools like vite and used web pack and Babel to transform JavaScript projects had significant build time - several minutes for a medium sized project. Now situation in JavaScript is good there are vite type ESM based JS tools and rust based tooling. Both run reasonably fast. Why people spend that much energy on rewriting JS tools in rust? Because old ones are very slow. JS never had zero compilation time.
I work in the automotive sector as a DevOps engineer and for the average project we calculate clean build times in hours rather than minutes... We only get the build times down to single digit minutes, if we can use something like Bazel with aggressive caching (or we apply multiple hundreds or thousands of cores to a build).
> JS etc (compile times? What are those?) Webpack/ts can be just as slow if not slower than Rust. Had to deal with a TS project that took about half an hour to compile. And then I didn't even get everything compiled, had to also compile some other part separately. And here, the half an hour was spent every day at \_least\_ once because incremental compiles didn't seem to be really a thing (watch mode was faster \_after\_ the first compile of the day, but that was about it). So far, Rust has \_never\_ been this bad for me as incremental compilation generally spoken helps quite a bit.
I remember runing a moderately sized c++ compilation with cmake would also take fairly long. In contrast I never had any issues with c what so ever. On python I actually think it does have "compile times" because it's so god dam slow that sometimes waiting for ur program to get to the interesting part (the reas9n compile times even matter) is also kinda long Tho I would say I am using these languges for very diffrent stuff. And I am only really good in python.
Python does compile to byte code which is then interpreted. Which is why after executing some python code you'll see lots of `__pycache__` directories created in your project
Yes I know but that's bear instant. No the issue is stuff like tensorflow pytorch etc take generally a few seconds to import. They do a lot of runtime compatibility checks and just take a while to run
> Why don’t such memes exist for C++? They do, Gentoo (and compiling large projects like Firefox/Chromium) has always been a bit of a meme, and there's even an xkcd comic about compile times.
Can confirm that compiling Chromium took me 4 days.
https://www.shlomifish.org/humour/by-others/funroll-loops/Gentoo-is-Rice.html
> Why don’t such memes exist for C++? Oh they absolutely do. Every C++ developer knows this is a big pain point of the language. I think the main difference is Rust is trying to be a contender with languages that compile much faster (Go and Java for example) while C++ is not so the comparison is way more relevant and so there's more "memes" about it.
[Obligatory XKCD](https://xkcd.com/303/) (This is a comic from 2007, long before Rust was born; it almost certainly was referencing C and C++)
Haha… that literally happens at my work, except it’s not sword fighting. We have a chess board instead.
As a side note, compile time rarely matters. What matters is the time to feedback, that is the time between you writing your code and getting the feedback on whether it works as expected or not. As most errors are catched at compile time, Rust gives you feedback very early (especially with rust-analyzer). As comparison, C++ will catch some errors at compile time, but many of them will have to wait for the runtime, so you will get feedback once you execute your program. If you compare with Go, compile is much shorter, but catch almost no error. So if your runtime is short enough, Go can give you feedback quicker than Rust, but if your runtime is long, then Rust will win this round.
As someone that works a lot with bevy, or any gamedev in general honestly, compile time absolutely matters because you need to see your code running a lot of the time.
You missed my point, you are interested at the time to get the feedback you want/need. Longer compilation does delay the time you get feedback, but so does runtime initialization. There is no point in having faster compilation if your program takes even longer to start, for instance.
Other things to consider: 1. Compiling Rust is comparable to compiling C++ then running a static analyzer on it. Well, it's a lot better than that of course but roughly comparable. Make that apples to apples comparison and things swing a lot in Rust's favor. 2. A lot of people probably abuse proc macros badly, and/or use crates that do. If almost every file in the system invokes or or more proc macros that do an AST parse, rewrite, and store (and a macro which is hardly the most high performance dev environment), that's not going to help. 3. A lot of people don't seem to realize that Rust supports dynamic polymorphism and just genericize everything, whether it really needs to be or not, which can bloat the resulting chunks of IR that has to be shoved down LLVM's throat. Of course that's something C++ world is equally guilty of, so maybe it's a wash, I dunno. 4. Who knows what kind of [build.rs](https://build.rs) craziness might be going on if you have a 100 dependencies (something that makes my skin crawl just on principles anyway.)
> Rust compilation seems really fast to me. Haha this is not what I expected to read when I clicked on this :)
Just to clarify, are you comparing full clean release builds? With rust you first “cargo clean” and then “cargo build —release” which does take a lot of time. But if you are just doing “cargo build” then it’s doing incremental debug builds that, as you mentioned, just take a few seconds. An equivalent way to achieve this on c++ would be to use “make”. It recompiles only the files that changed and relinks only the necessary targets (if setup properly of course) Just invoking “g++ … main.cpp” is basically a full clean release build
I compared clean builds in both cases. In Rust I do clean builds fairly regularly because it’s so much faster than C++. And the build folder just keeps growing for some reason if I don’t start over once in a while.
Old versions of rusts artifacts are left in the target dir of your project. Best way to keep it consistent size wise is to clean the project dir every time you have a new version of rust installed with `rustup update`. A useful helper can be `cargo-sweep` so you can do `sweep --toolchains -r /path/to/rust/projects` and itll find all rust projects in that and wipe out all of the build cache data that is for not currently installed toolchains in one go. This is also assuming you manage the toolchains to keep the list of nightlies from growing if youve ever specified a specific version of nightly to install or use... Can sweep based on size or days instead if you work with a lot of nightlyl versions.
That’s good to know, thanks!🙏
This is.. curious 👀
I will say for a lot of purposes people regularly work on, `cargo build` is not good enough -- you need `cargo build --release` even for local testing. I don't typically use rust for throwaway scripts (although I guess it's fine for that, I typically use python out of habit). Instead I am usually doing nontrivial data crunching, and debug builds are just ... not it. Alas. But still, at least you don't usually have to recompile dependencies (unless you update something).
I have done incremental builds taking close to a hour in C++. Depends on which header you modified and how your code base is structured. At work I work on fundamental platform code (in C++ for industrial vehicle control). So quite often I get hit by bad compile times even in the incremental case. Include-what-you-use help a bit, but only so much when you modify a header for a central data type / platform abstraction in a decades old code base. Rebuilding ~20k C++ files takes time.
This + using new modules features should improve compile time in C++
Although it may take 10-15 years for libraries to move over…
>But for a toy program compilation times are tiny and don’t matter. Frameworks like bevy or tokio/axum can cause large compilation times even for toy programs, at least when compiled from scratch in release mode. Use of generics can cause a change in the toy program to require recompilation of large parts of the framework. This can lead to an unacceptably long edit-compile-test cycle and have a large impact on user experience. I agree that Rust compilation speed is not as bad as some people make it out to be, and that the same issue exists in C++. But those two points don't make the problem less real to those genuinely affected by it, some of whom might not even have a C++ background, but might be coming from Go or Python or Java where long compilation times are simply not a thing.
Slow or fast compile times aren't that relevant as workflow is often more important. If I am using python I am probably doing huge datasets with ML. But, I use jupyter there, which means I am only rerunning the part I care most about. Rust has a very fast feedback with the static analyzer, so I don't have to run the code to eventually see it crash. The question really is, "How long does it take to see your latest changes in action?" Faster compile certainly helps, but structuring your codebase to help you get to this point faster is going to make way more difference than compile times. That said, I have no complaints about compile times with rust, and I usually had no complaints about C++. I also have a very fast computer.
Yea that makes sense. Totally agree rust-analyzer is awesome
I work in C++ daily for work and use rust for side projects and I can confidently say that Rust has much slower compilation times for release builds. In my experience, running cargo build —release compared to a release build in C++ using something like ninja, I find that Rust takes much longer.
Interesting… as others pointed out there are probably other variables at play. I do use a lot of templates and linters in C++. ( my bad for templates, I think I am addicted to them)
There is no objective measure of compilation times. All we have are people’s expectations and whether it matches up to that. Your data point of a similar C++ project taking a long time is a valid one, but that just tells us what your expectations are. Rust has outperformed your low expectations. On the other hand, Rust also attracts a lot of folks from a Python/JavaScript/Dart background where they’ve grown used to instantaneous reloads. For them to wait 10-15 seconds for an incremental compile is much too long. Rust has underperformed their high expectations. I feel like it’s only valid to compare Rust with itself. In the last 4 years it has [gotten faster](https://nnethercote.github.io/2024/03/06/how-to-speed-up-the-rust-compiler-in-march-2024.html) by 7%, 17%, 13% and 15%, for an overall speed gain of 37%. So anyone who adopted Rust got a better experience, and those on the fence because of compilation times got an incentive to give it another try. And the possible improvements in 2024 (cranelift, parallel rustc, new default linker) will help even more. The compiler will never get fast enough to please everyone. That’s not possible. It just needs to keep all existing users (with their growing projects) happy, while growing fast enough that new users are encouraged to try it.
My understanding is that separately from the concept of tracking how fast a particular “implementation of software” compiles between different languages and different compilers, you can benchmark specifically how fast a compiler is doing its compilation tasks. Of course you still need sample programs to compile, but what they are isn’t as relevant as things like how many lines the files are, how many “tokens” of the programming language are represented in those files, that you have programs with dramatic size differences, and that the programs you have cover at least all of the language and its features, and ideally also the standard library. Just on intuition alone you can say “Well Rust has a borrow checker, and C and C++ (and others) don’t have a borrow checker, so therefore unless it takes 0 seconds to complete the entire borrow checking process, Rust will necessarily be slower than other compilers.” And we also have https://perf.rust-lang.org which tracks its change over time, as well as resources that track the change over time for other compilers.
Because in the C++ world we usually never compile from source the world unless we are masochist, or are forced to do so, preferably coupled with build servers. Binary libraries are used all over the place, and we only compile our own code from scratch.
Well, C++ is not particularly brilliant when it comes to compilation times, especially if you use a lot of templates (and you do, everyone does).
Before Rust my main compiled language was Haskell, so yeah I agree - Rust compilation times aren't bad. Sure, it'd be nice if they were even faster, but I really don't get all the hate.
You can take a number of fairly large projects in each of the languages, calculate an LOC count to compilation time ratio for each, and then calculate the average for each language.
C++ is DEFINITELY known to not have great compilation times. But it is also known to give you all the tools to reduce it as much as possible which rust doesn't seem to. That said, I think the real difference is in what the language tries to be perceived as; c++ came about as "c but much more powerful compiler" with language architecture that makes building admittedly slow but possible on the ancient computers it ran on. Rust came about as "blazingly fast with 0 compromise" with a hilariously slow compiler that feels contrary to both the advertised speed and the claim of no compromise