throwup238
10 months ago
> 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.
iTokio
10 months 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
9 months ago
You don't need serde or proc macros to blow up your compilation times - just a lot of complex monomorphised generics.
Ygg2
9 months 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
9 months ago
While true, not everyone can afford a gamming rig just for using a compiled language, so this hurts adoption.
Ygg2
9 months ago
Gaming rigs cost is mostly GPU. Compilers love cores, ssd, ram in that order.
Gaming rig is not great for compiling. And vice versa.
pjmlp
9 months ago
It was an example of the kind of compute power, of course we can get pedantic on which hardware.
Ygg2
9 months ago
You're overestimating the budget needed for the rig. Would working with a Windows 7 era laptop and Rust suck? Yes. But so would anything else.
I'm on a 4-year-old PC, granted it's 5900X, 3800 MHz RAM and my numbers are derived from it.
pjmlp
9 months ago
Quite far from the typical i5 most folks have access to on shopping malls.
Ygg2
9 months ago
Even i5 will only make it around twice as slow[1]. So from 5min -> 10min.
And that's a relatively pessimistic scenario - huge number of dependencies, slow processor (i5), fresh build. In incremental build, it goes from minutes to seconds.
Klonoar
9 months ago
My M1 from ~4 years ago still rips through compiles. shrug
pjmlp
9 months ago
Outside wealthy countries Apple hardware isn't really an option.
noisy_boy
9 months ago
I am yet to see an example of a full-time Rust developer in a poor country who can't afford Apple hardware.
pjmlp
9 months ago
See, gatekeeping right there.
How did that lucky person become a full time Rust developer, and landed a job paying Apple level of income, in first place?
itishappy
9 months ago
Wait a bit longer?
I'd argue that gatekeeping here is being done by the "Rust requires overpowered hardware" position you're assuming. I happily use an RPi4.
ekaryotic
9 months ago
maybe we could use ai to optimise compilers somehow.
cosmic_quanta
9 months 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
9 months 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++.
pjmlp
9 months ago
Which is exactly why we traditionally don't build the world from scratch in C++, rather rely on binary libraries for 3rd party dependencies, or component frameworks.
Additionally rely on dynamic libraries during debug builds.
imron
9 months ago
Incremental build times in rust are also on par (and often faster) with c++ on the similar sized projects I’ve worked on.
pjmlp
9 months ago
Except those other compilers offer multiple toolchains, including interpreters, that are faster than rustc.
Standard ML, Idris, ..., F#, Haskell and OCaml have interpreters, and REPLs, in addition to the full blown AOT compilation.
Naturally Rust can also have those, however they aren't here today.
phyrex
9 months ago
People are working on it: https://ai.meta.com/blog/compilergym-making-compiler-optimiz...
dietr1ch
10 months ago
Code generation isn't the fastest, but you can iterate with `cargo check`
pjmlp
9 months ago
Not a great advice for graphical applications.
Havoc
10 months 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
9 months ago
Exactly, the same way Moore's law has solved C++ compile times.
ynik
9 months 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.
flohofwoe
9 months 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)