5 ms·

Having worked on large scale C++ code-bases and thus used to long compilation times, it surprises me that this is the hill many C++ devs would die on in regards

Having worked on large scale C++ code-bases and thus used to long compilation times, it surprises me that this is the hill many C++ devs would die on in regards to their dislike of Rust.

logicchains 1y ago
There's a lot of things you can do in C++ to reduce compilation time if you care about it, that aren't possible with Rust.
- MeetingsBrowser 1y ago
  There are things you can do for Rust if it really is a deal breaker. Dioxus has a hot reload system. Some rust game engines have done similar things.
  - jplusequalt 1y ago
    When in doubt, manually patch your dll's
- kibwen 1y ago
  You can absolutely do the same things in Rust, it's just that the culture and tooling of Rust encourages much larger compilation units than in C or C++, so you don't get the same sort of best-case nontrivial embarrassing-parallelism, forcing the compiler to do more work to parallelize. To address the tooling pressure, I would like to see Cargo support first-class internal-only crates, thereby deconflating the crate as what is today both the unit of compilation and the unit of distribution.
  - pjmlp 1y ago
    You certainly cannot distribute binary libraries, including pre-expanded templates for common use cases. Which is always my standard approach to fast build times in C++ projects.
0cf8612b2e1e 1y ago
It is a quantifiable negative to which you can always point. Of course it will be used for justifications.
phkahler 1y ago
>> it surprises me that this is the hill many C++ devs would die on in regards to their dislike of Rust I believe people will exaggerate their current issue so it sounds like the only thing that matters to them. On another project I've had people say "This is the only thing that keeps me using commercial alternatives" or the only thing holding back wider adoption, or the only thing needed for blah blah blah. Meanwhile I've got my own list of high priority things needed to bring it to what I'd consider a basic level of completeness. When it comes to performance it will never be good enough for everyone. There is always a bigger project to consume whatever resources are available. There are always people who insist on doing things in odd ways (maybe valid, but very atypical). These requests to improve are often indistinguishable from the regular ones.
pton_xd 1y ago
Makes sense to me! Everyone with enough C++ experience has dealt with that nightmare at one point. Never again, if you can help it.
maccard 1y ago
I work on large c++ code bases day in day out - think 30 minute compiles on an i9 with 128GB ram and NVMe drives. Rusts compile times are still ungodly slow. I contributed to a “small to medium” open source project [0] a while back, fixing a few issues that we came across when using it. Given that the project is approximately 3 orders of magnitude smaller than my day to day project, a clean build of a few thousand lines of rust took close to 10 minutes. Incremental changes to the project were still closer to a minute at the time. I’ve never worked on a 5m+ LOC project in rust, but I can only imagine how long it would take. On the flip side, I also submitted some patches to a golang program of a similar size [1] and it was faster to clone, install dependencies and clean build that project than a single file change to the rust project was. [0] https://github.com/getsentry/symbolicator https://github.com/getsentry/symbolicator [1] https://github.com/buildkite/agent https://github.com/buildkite/agent
- jplusequalt 1y ago
  Yes, but Go is a higher level language than Rust. It feels unfair to compare the two. That's why I brought up C++ (as did the article).
  - maccard 1y ago
    I disagree that it’s unfair to compare the two. The performance difference between go and rust is far less than the difference between go and python, it has a garbage collector sure but it’s an example of a language designed for fast compilation time that achieves an order of magnitude faster compile times than rust
    - jplusequalt 1y ago
      I think you're missing the point of my comparison. Rust has a lot more going on than Go, so it feels unfair.
      - sagarm 1y ago
        Go has a lot less going on than Rust partially because compile times were a priority.
bnolsen 1y ago
The answer there was to always write small standalone executable unit test sets and simulation for day to day coding. Avoiding template heavy pigs like QT or boost helps too.
- akazantsev 1y ago
  > Avoiding template heavy pigs like QT Well, you definitely have no experience with Qt.
throwaway664786 1y ago
C++ is one of the fastest languages to compile*, assuming you aren't doing silly stuff like abusing templates. It just gets a bad rep because actual, real-world, massive projects are written in C++. Like, yeah, no wonder Chromium build times aren't spectacular, but I assure you that they'd be much, much worse if it was written in Rust. Pointing and scoffing at it when there's nothing written in Rust that we can even compare it to is just intellectually dishonest. * It's not beating interpreted languages any time soon, but that's not really a fair comparison.

Having worked on large scale C++ code-bases and thus used to long compilation times, it surprises me that this is the hill many C++ devs would die on in regards to their dislike of Rust.

logicchains 1y ago

There's a lot of things you can do in C++ to reduce compilation time if you care about it, that aren't possible with Rust.

MeetingsBrowser 1y ago
There are things you can do for Rust if it really is a deal breaker. Dioxus has a hot reload system. Some rust game engines have done similar things.
- jplusequalt 1y ago
  When in doubt, manually patch your dll's
kibwen 1y ago
You can absolutely do the same things in Rust, it's just that the culture and tooling of Rust encourages much larger compilation units than in C or C++, so you don't get the same sort of best-case nontrivial embarrassing-parallelism, forcing the compiler to do more work to parallelize. To address the tooling pressure, I would like to see Cargo support first-class internal-only crates, thereby deconflating the crate as what is today both the unit of compilation and the unit of distribution.
- pjmlp 1y ago
  You certainly cannot distribute binary libraries, including pre-expanded templates for common use cases. Which is always my standard approach to fast build times in C++ projects.

0cf8612b2e1e 1y ago

It is a quantifiable negative to which you can always point. Of course it will be used for justifications.

phkahler 1y ago

>> it surprises me that this is the hill many C++ devs would die on in regards to their dislike of Rust I believe people will exaggerate their current issue so it sounds like the only thing that matters to them. On another project I've had people say "This is the only thing that keeps me using commercial alternatives" or the only thing holding back wider adoption, or the only thing needed for blah blah blah. Meanwhile I've got my own list of high priority things needed to bring it to what I'd consider a basic level of completeness. When it comes to performance it will never be good enough for everyone. There is always a bigger project to consume whatever resources are available. There are always people who insist on doing things in odd ways (maybe valid, but very atypical). These requests to improve are often indistinguishable from the regular ones.

pton_xd 1y ago

Makes sense to me! Everyone with enough C++ experience has dealt with that nightmare at one point. Never again, if you can help it.

maccard 1y ago

I work on large c++ code bases day in day out - think 30 minute compiles on an i9 with 128GB ram and NVMe drives. Rusts compile times are still ungodly slow. I contributed to a “small to medium” open source project [0] a while back, fixing a few issues that we came across when using it. Given that the project is approximately 3 orders of magnitude smaller than my day to day project, a clean build of a few thousand lines of rust took close to 10 minutes. Incremental changes to the project were still closer to a minute at the time. I’ve never worked on a 5m+ LOC project in rust, but I can only imagine how long it would take. On the flip side, I also submitted some patches to a golang program of a similar size [1] and it was faster to clone, install dependencies and clean build that project than a single file change to the rust project was. [0] https://github.com/getsentry/symbolicator https://github.com/getsentry/symbolicator [1] https://github.com/buildkite/agent https://github.com/buildkite/agent

jplusequalt 1y ago
Yes, but Go is a higher level language than Rust. It feels unfair to compare the two. That's why I brought up C++ (as did the article).
- maccard 1y ago
  I disagree that it’s unfair to compare the two. The performance difference between go and rust is far less than the difference between go and python, it has a garbage collector sure but it’s an example of a language designed for fast compilation time that achieves an order of magnitude faster compile times than rust
  - jplusequalt 1y ago
    I think you're missing the point of my comparison. Rust has a lot more going on than Go, so it feels unfair.
    - sagarm 1y ago
      Go has a lot less going on than Rust partially because compile times were a priority.

bnolsen 1y ago

The answer there was to always write small standalone executable unit test sets and simulation for day to day coding. Avoiding template heavy pigs like QT or boost helps too.

akazantsev 1y ago
> Avoiding template heavy pigs like QT Well, you definitely have no experience with Qt.

throwaway664786 1y ago

C++ is one of the fastest languages to compile*, assuming you aren't doing silly stuff like abusing templates. It just gets a bad rep because actual, real-world, massive projects are written in C++. Like, yeah, no wonder Chromium build times aren't spectacular, but I assure you that they'd be much, much worse if it was written in Rust. Pointing and scoffing at it when there's nothing written in Rust that we can even compare it to is just intellectually dishonest. * It's not beating interpreted languages any time soon, but that's not really a fair comparison.