4 ms·

> Compile time is still PITA This is Rust's Achilles heel and has been since almost day one. Once a project is at a nontrivial scale, it really starts to weigh

> Compile time is still PITA This is Rust's Achilles heel and has been since almost day one. Once a project is at a nontrivial scale, it really starts to weight it down. I'm working on a Rust/C++/QT QML desktop app and I've spent the last week refactoring my crates/libraries so I can split them off as shared libraries that can be built independently, otherwise even incremental builds can take minutes. Thankfully there are some crates to make a stable ABI and dynamic reload. > LLMs rarely help with a proper solution, as most of the packages are kind of niche. This has also bitten me quite a bit but at the same time, I've been impressed with what Claude 3.5 and o1-preview have been able to do with Rust even with niche libraries like cxx-qt - a relatively new library with little in the training data. A lot of stuff like writing Rust implementations of QAbstractListModel works really well when given the right context (like an example implementation of another list model). LLMs have also been a boon for writing macros, both macro_rules and proc macros.

dietr1ch 2y ago
Code generation isn't the fastest, but you can iterate with `cargo check`
- pjmlp 2y ago
  Not a great advice for graphical applications.
iTokio 2y ago
There is a subset of Rust that compiles fast, but it requires to avoid serde and crates that depends on syn, quote, proc-macro… The issue is that macros and generics can generate tons of code under the hood. Unfortunately some major parts of the rust ecosystem like serialization and async frameworks are dependent on these features..
- Ygg2 2y ago
  You don't need serde or proc macros to blow up your compilation times - just a lot of complex monomorphised generics.
Havoc 2y ago
Well at least Moores law favours rust on compile time. So in that regard it seems like one of the less problematic language issues one can have - it’ll sort itself out. The same can’t be said for the issues on other langs
- pmezard 2y ago
  Exactly, the same way Moore's law has solved C++ compile times.
  - ynik 2y ago
    Not sure if you dropped a "/s". In my experience, C++ template usage will always expand until all reasonably available compile time is consumed. Rust doesn't have C++'s header/implementation separation, so it's easy to accidentally write overly generic code. In C++ you'd maybe notice "do I really want to put all of this in the header?", but in Rust your compile times just suffer silently. On the other hand, C++'s lack of a standardized build system led to the popularity of header-only libraries, which are even worse for compile times.
    - pjmlp 2y ago
      From my point of view it is more like laziness to learn how to properly use compiler toolchains.
      - dymk 2y ago
        First rule of good design: misuse isn’t the humans fault
- flohofwoe 2y ago
  Moore's Law never sorted it out, even when it wasn't dead yet. Software always got slower quicker than the hardware it runs on got faster (as can be seen currently on ARM Macs, they felt incredibly fast in the beginning, but now software is starting to catch up and new Macs are starting to feel just as slow as the Intel Macs they replaced (looking specifically at you, Xcode)
Ygg2 2y ago
Keep in mind the times written in article are unrealisticly long. Bevy, being the chonker it is, with 300-700 dependencies takes about 5min from scratch. And 15 seconds on average. What is happening here is combination of using underpowered Gitlab runner, no-caching of artifacts between runs and dog knows what else.
- pjmlp 2y ago
  While true, not everyone can afford a gamming rig just for using a compiled language, so this hurts adoption.
  - ekaryotic 2y ago
    maybe we could use ai to optimise compilers somehow.
    - phyrex 2y ago
      People are working on it: https://ai.meta.com/blog/compilergym-making-compiler-optimizations-accessible-to-all/ https://ai.meta.com/blog/compilergym-making-compiler-optimiz...
    - cosmic_quanta 2y ago
      The reason rustc and other compilers like it (e.g. GHC) are "slow" isn't because they are unoptimized; it's because they do A LOT of work! rustc is enforcing a strong and expressive type system, checking for ownership, generating code from macros, etc. It will always be an order of magnitude slower than C/C++ compiler, kind-of by design.
      - imron 2y ago
        Large C++ projects aren't exactly known for their stellar compile times either. Coming from a C++ background, I don't find Rust compile times to be that bad for comparable sized projects in C++.

dietr1ch 2y ago

Code generation isn't the fastest, but you can iterate with `cargo check`

pjmlp 2y ago
Not a great advice for graphical applications.

iTokio 2y ago

There is a subset of Rust that compiles fast, but it requires to avoid serde and crates that depends on syn, quote, proc-macro… The issue is that macros and generics can generate tons of code under the hood. Unfortunately some major parts of the rust ecosystem like serialization and async frameworks are dependent on these features..

Ygg2 2y ago
You don't need serde or proc macros to blow up your compilation times - just a lot of complex monomorphised generics.

Havoc 2y ago

Well at least Moores law favours rust on compile time. So in that regard it seems like one of the less problematic language issues one can have - it’ll sort itself out. The same can’t be said for the issues on other langs

pmezard 2y ago
Exactly, the same way Moore's law has solved C++ compile times.
- ynik 2y ago
  Not sure if you dropped a "/s". In my experience, C++ template usage will always expand until all reasonably available compile time is consumed. Rust doesn't have C++'s header/implementation separation, so it's easy to accidentally write overly generic code. In C++ you'd maybe notice "do I really want to put all of this in the header?", but in Rust your compile times just suffer silently. On the other hand, C++'s lack of a standardized build system led to the popularity of header-only libraries, which are even worse for compile times.
  - pjmlp 2y ago
    From my point of view it is more like laziness to learn how to properly use compiler toolchains.
    - dymk 2y ago
      First rule of good design: misuse isn’t the humans fault
flohofwoe 2y ago
Moore's Law never sorted it out, even when it wasn't dead yet. Software always got slower quicker than the hardware it runs on got faster (as can be seen currently on ARM Macs, they felt incredibly fast in the beginning, but now software is starting to catch up and new Macs are starting to feel just as slow as the Intel Macs they replaced (looking specifically at you, Xcode)

Ygg2 2y ago

Keep in mind the times written in article are unrealisticly long. Bevy, being the chonker it is, with 300-700 dependencies takes about 5min from scratch. And 15 seconds on average. What is happening here is combination of using underpowered Gitlab runner, no-caching of artifacts between runs and dog knows what else.

pjmlp 2y ago
While true, not everyone can afford a gamming rig just for using a compiled language, so this hurts adoption.
- ekaryotic 2y ago
  maybe we could use ai to optimise compilers somehow.
  - phyrex 2y ago
    People are working on it: https://ai.meta.com/blog/compilergym-making-compiler-optimizations-accessible-to-all/ https://ai.meta.com/blog/compilergym-making-compiler-optimiz...
  - cosmic_quanta 2y ago
    The reason rustc and other compilers like it (e.g. GHC) are "slow" isn't because they are unoptimized; it's because they do A LOT of work! rustc is enforcing a strong and expressive type system, checking for ownership, generating code from macros, etc. It will always be an order of magnitude slower than C/C++ compiler, kind-of by design.
    - imron 2y ago
      Large C++ projects aren't exactly known for their stellar compile times either. Coming from a C++ background, I don't find Rust compile times to be that bad for comparable sized projects in C++.