5 ms·

C and C++ codebases are two very different things. I work on a large c++ project, and our compile times are awful. From my limited experience, moving to rust w

C and C++ codebases are two very different things. I work on a large c++ project, and our compile times are awful. From my limited experience, moving to rust would absolutely ruin our compile times.

cschep 4y ago
I know rust compile times aren't great but.. are they WORSE than C++?? yeesh.
- maccard 4y ago
  Yeah, they are. The compile times on the toy rust projects I've worked on are in the same region of my work c++ projects.
- aliqot 4y ago
  In my experience, yes.
- sli 4y ago
  There are a few things you can do to help it. The Bevy project has a section of their setup documentation that lists a few strategies[0]. In general though it can be relatively pretty slow. [0]: https://bevyengine.org/learn/book/getting-started/setup/#enable-fast-compiles-optional https://bevyengine.org/learn/book/getting-started/setup/#ena...
- meindnoch 4y ago
  By a wide margin.
- nequo 4y ago
  Yes. This benchmark was recently posted on HN[1]: https://quick-lint-js.com/blog/cpp-vs-rust-build-times/ https://quick-lint-js.com/blog/cpp-vs-rust-build-times/ [1] https://news.ycombinator.com/item?id=34271293 https://news.ycombinator.com/item?id=34271293
- bfrog 4y ago
  Frankly it depends, just like in C++, how the code is written. Rust, even more so than C++ code bases I've worked on and with, really tries to do lots of static typing and mono morphizing. If you work with large projects using boost and eigen, or other template libraries like them compile times are far from amazing. Compared to something like Qt where mostly its dynamic typing at work, and compile times were usually pretty reasonable.
- raphlinus 4y ago
  As with most such things, there is considerable nuance to this question. If you're careful with your dependencies and optimizing for compile time, it can be quite good. For example, a clean release build of makepad studio on M1 Max is 8.81s. There are also patterns that can really bloat compile time, especially heavy use of procedural macros to autogenerate code. Using serde to serialize big, complex data types can be a big compile time hit. Monomorphization can also be a problem, but fortunately careful use of boxing of dyn traits can help a lot with both code size and compile time (miniserde is an alternative to serde that's more optimized on these dimensions). There's also continual and ongoing work to improve compile times. So overall I would say it's definitely a factor, but not necessarily a showstopper.
  - maccard 4y ago
    > you're careful with your dependencies and optimizing for compile time, it can be quite good. The same can be said about c++. On the other points, every rust project I've seen in the wild makes heavy heavy use of macros, and the majority of projects I've used have a dependency like serde or something. If you're willing to avoid procedural macros and large dependencies, you might as well just work in c++, avoid custom templates and enjoy wicked fast iteration times. > So overall I would say it's definitely a factor, but not necessarily a showstopper. I disagree, it is a showstopper for now. It might not be in the future but the situation right now is that comparable c++ and rust projects in my experience have been an order of magnitude in the difference in compile times. My work c++ codebase is a 30 minutes clean build on a 32 core machine with 96GB ram and an NVMe SSD. I can only imagine what an equivalent project would be in my rust if it were as large.
    - raphlinus 4y ago
      Another real world example, and actually quite relevant to the use case of the original article. Tint and naga are both shader compilers, primarily used for compiling WGSL into SPIR-V, MSL, and HLSL so shaders can be used portably. Tint is in C++ and takes 113.6s for a clean compile on M1 Max. Naga, in Rust, is 17s. That includes serde and a bunch of the usual community crates (quote, syn, thiserror, petgraph). Admittedly Tint is more mature and sophisticated, but both serve the function I need them for.
- pjmlp 4y ago
  It depends on C++ code is written, plus contrary to Rust, most C and C++ shops make heavy use of binary libraries, so they only get to compile what they actually need for the project.
aliqot 4y ago
Go compiles near instantly, having used Rust and Go for some time now, and shipped in both, Go is the clear winner if you value being able to iterate quickly.
- jorvi 4y ago
  They have very different purposes. By your logic, Python is king over Go since Python doesn’t need to compile at all.
  - arthurcolle 4y ago
    Wait until you hear about Python bytecode: https://opensource.com/article/18/4/introduction-python-bytecode https://opensource.com/article/18/4/introduction-python-byte...
    - super_flanker 4y ago
      Python bytecode is interpreted by cpython.
- bfrog 4y ago
  Maybe? I found Go pretty stifling and ran into corners where I was faced with having to copy/paste a lot, write a code generator, or resort to ditching type safety. None of those options are very satisfying. I know generics are now there so maybe this has changed since I last used it. Good if so! 100kloc go program was fast to compile, but awful to modify. It was amusing to me that often times the answer in Go to avoiding repeating yourself was creating a code generator though, because the language didn't have the native abilities in macros/generics/meta programming itself to do it.
  - aliqot 4y ago
    Look, I'm not trying to start a holy war, I'm just relating my experience of more than just a toe being dipped in. Find the argument somewhere else.
bfrog 4y ago
It's not solely about compile times though. If you consider all the debugging time Rust saves you from, I'd guess Rust even with its slower compile time, comes out ahead in terms of productivity. That is after all what this link is telling us. One of the main points made was "speed up development" If it were solely about compile times that wouldn't be a major reason to use Rust here.
- dralley 4y ago
  Not having spurious race conditions that take days if not weeks to hunt down is quite nice.
  - menaerus 4y ago
    That's not possible at all with the bare-metal languages. I think many people do not understand that race conditions are a direct consequence of the complexity of our CPUs, memory etc. It is not the "flawed" programming language design that allowed them to sneak in but it is because the problem isn't fundamentally solvable. Some languages try to minimize the surface area but it's not for free: there's always a trade-off attached to it. In that sense it is not anymore a bare-metal language.
    - tialaramex 4y ago
      You're thinking of data races, but, (safe) Rust doesn't have data races. You can't write them. In C++ if you write a data race, that's Undefined Behaviour, game over. This difference might be astonishing, but it's a fundamental design choice. The data race requires two things to coincide and in (safe) Rust they can't. You need mutation of a value which isn't synchronised with access to that value. In concurrent C or C++ it's trivial to do this by mistake, you now have a data race and so UB. But you can't write this in safe Rust.
- maccard 4y ago
  Only a sith deals in absolutes, it's not solely about _anything_. I write multithreaded code every day, and I'm constantly pushing for us modernizing and cleaning up our c++ codebase. Mistakes happen, subtle bugs slip through, but probably 95% of the code I write and features I write don't benefit from the extra checks that rust provides. The 5% that _do_, that's a trade-off, and we need to decide whether it's worth it. In the long tail, yeah there's less bugs of various categories. Is that worth the cost of the rewrite and the productivity hit for 95% of what I do (as someone who would genuinely benefit from having a borrow checked), the answer right now is probably not

C and C++ codebases are two very different things. I work on a large c++ project, and our compile times are awful. From my limited experience, moving to rust would absolutely ruin our compile times.

cschep 4y ago

I know rust compile times aren't great but.. are they WORSE than C++?? yeesh.

maccard 4y ago
Yeah, they are. The compile times on the toy rust projects I've worked on are in the same region of my work c++ projects.
aliqot 4y ago
In my experience, yes.
sli 4y ago
There are a few things you can do to help it. The Bevy project has a section of their setup documentation that lists a few strategies[0]. In general though it can be relatively pretty slow. [0]: https://bevyengine.org/learn/book/getting-started/setup/#enable-fast-compiles-optional https://bevyengine.org/learn/book/getting-started/setup/#ena...
meindnoch 4y ago
By a wide margin.
nequo 4y ago
Yes. This benchmark was recently posted on HN[1]: https://quick-lint-js.com/blog/cpp-vs-rust-build-times/ https://quick-lint-js.com/blog/cpp-vs-rust-build-times/ [1] https://news.ycombinator.com/item?id=34271293 https://news.ycombinator.com/item?id=34271293
bfrog 4y ago
Frankly it depends, just like in C++, how the code is written. Rust, even more so than C++ code bases I've worked on and with, really tries to do lots of static typing and mono morphizing. If you work with large projects using boost and eigen, or other template libraries like them compile times are far from amazing. Compared to something like Qt where mostly its dynamic typing at work, and compile times were usually pretty reasonable.
raphlinus 4y ago
As with most such things, there is considerable nuance to this question. If you're careful with your dependencies and optimizing for compile time, it can be quite good. For example, a clean release build of makepad studio on M1 Max is 8.81s. There are also patterns that can really bloat compile time, especially heavy use of procedural macros to autogenerate code. Using serde to serialize big, complex data types can be a big compile time hit. Monomorphization can also be a problem, but fortunately careful use of boxing of dyn traits can help a lot with both code size and compile time (miniserde is an alternative to serde that's more optimized on these dimensions). There's also continual and ongoing work to improve compile times. So overall I would say it's definitely a factor, but not necessarily a showstopper.
- maccard 4y ago
  > you're careful with your dependencies and optimizing for compile time, it can be quite good. The same can be said about c++. On the other points, every rust project I've seen in the wild makes heavy heavy use of macros, and the majority of projects I've used have a dependency like serde or something. If you're willing to avoid procedural macros and large dependencies, you might as well just work in c++, avoid custom templates and enjoy wicked fast iteration times. > So overall I would say it's definitely a factor, but not necessarily a showstopper. I disagree, it is a showstopper for now. It might not be in the future but the situation right now is that comparable c++ and rust projects in my experience have been an order of magnitude in the difference in compile times. My work c++ codebase is a 30 minutes clean build on a 32 core machine with 96GB ram and an NVMe SSD. I can only imagine what an equivalent project would be in my rust if it were as large.
  - raphlinus 4y ago
    Another real world example, and actually quite relevant to the use case of the original article. Tint and naga are both shader compilers, primarily used for compiling WGSL into SPIR-V, MSL, and HLSL so shaders can be used portably. Tint is in C++ and takes 113.6s for a clean compile on M1 Max. Naga, in Rust, is 17s. That includes serde and a bunch of the usual community crates (quote, syn, thiserror, petgraph). Admittedly Tint is more mature and sophisticated, but both serve the function I need them for.
pjmlp 4y ago
It depends on C++ code is written, plus contrary to Rust, most C and C++ shops make heavy use of binary libraries, so they only get to compile what they actually need for the project.

aliqot 4y ago

Go compiles near instantly, having used Rust and Go for some time now, and shipped in both, Go is the clear winner if you value being able to iterate quickly.

jorvi 4y ago
They have very different purposes. By your logic, Python is king over Go since Python doesn’t need to compile at all.
- arthurcolle 4y ago
  Wait until you hear about Python bytecode: https://opensource.com/article/18/4/introduction-python-bytecode https://opensource.com/article/18/4/introduction-python-byte...
  - super_flanker 4y ago
    Python bytecode is interpreted by cpython.
bfrog 4y ago
Maybe? I found Go pretty stifling and ran into corners where I was faced with having to copy/paste a lot, write a code generator, or resort to ditching type safety. None of those options are very satisfying. I know generics are now there so maybe this has changed since I last used it. Good if so! 100kloc go program was fast to compile, but awful to modify. It was amusing to me that often times the answer in Go to avoiding repeating yourself was creating a code generator though, because the language didn't have the native abilities in macros/generics/meta programming itself to do it.
- aliqot 4y ago
  Look, I'm not trying to start a holy war, I'm just relating my experience of more than just a toe being dipped in. Find the argument somewhere else.

bfrog 4y ago

It's not solely about compile times though. If you consider all the debugging time Rust saves you from, I'd guess Rust even with its slower compile time, comes out ahead in terms of productivity. That is after all what this link is telling us. One of the main points made was "speed up development" If it were solely about compile times that wouldn't be a major reason to use Rust here.

dralley 4y ago
Not having spurious race conditions that take days if not weeks to hunt down is quite nice.
- menaerus 4y ago
  That's not possible at all with the bare-metal languages. I think many people do not understand that race conditions are a direct consequence of the complexity of our CPUs, memory etc. It is not the "flawed" programming language design that allowed them to sneak in but it is because the problem isn't fundamentally solvable. Some languages try to minimize the surface area but it's not for free: there's always a trade-off attached to it. In that sense it is not anymore a bare-metal language.
  - tialaramex 4y ago
    You're thinking of data races, but, (safe) Rust doesn't have data races. You can't write them. In C++ if you write a data race, that's Undefined Behaviour, game over. This difference might be astonishing, but it's a fundamental design choice. The data race requires two things to coincide and in (safe) Rust they can't. You need mutation of a value which isn't synchronised with access to that value. In concurrent C or C++ it's trivial to do this by mistake, you now have a data race and so UB. But you can't write this in safe Rust.
maccard 4y ago
Only a sith deals in absolutes, it's not solely about _anything_. I write multithreaded code every day, and I'm constantly pushing for us modernizing and cleaning up our c++ codebase. Mistakes happen, subtle bugs slip through, but probably 95% of the code I write and features I write don't benefit from the extra checks that rust provides. The 5% that _do_, that's a trade-off, and we need to decide whether it's worth it. In the long tail, yeah there's less bugs of various categories. Is that worth the cost of the rewrite and the productivity hit for 95% of what I do (as someone who would genuinely benefit from having a borrow checked), the answer right now is probably not