Doing stuff isn't free. For instance, Go compiles relatively quickly for a modern language, but the biggest reason for that is that it does less stuff than most compilers... less optimization, less checking, and some stuff built into the language to avoid some of the problems with having to read lots of headers just to compile a file and other ways of doing less stuff, but mostly the key is it does less stuff, in both the good and bad senses of that.
If you want something like Rust that offers guarantees and checks and cross-checks by the boatload, it adds up. Macros, monomorphization, implicit code generation with traits and all those other things add up too. And you can't always get O(n) or O(n log n) code to implement those checks. Maybe it can be sped up and maybe there's tricks here or there, but at the Pareto frontier, a language that has more checks will be slower to compile than one that has fewer.
And that's not a bad thing or a deficit in Rust, it's just the nature of the beast.
And since you bring up Go and contrast the compile time with Rust, it's been experienced at Google (and also Volvo and other places) that Rust and Go teams are as productive whereas C++ is less than half as productive: <a href="https://www.youtube.com/watch?t=27012&v=6mZRWFQRvmw&feature=youtu.be" rel="nofollow">https://www.youtube.com/watch?t=27012&v=6mZRWFQRvmw&feature=...
So the focus on Rust compile time is misplaced. It's not a big deal in terms of overall productivity.
I don't think that follows - just that compile times aren't the only thing that matters. Maybe rust could be twice as productive as go if compile times went to zero for instance (or maybe not - just disputing that the evidence proves the claim here).
But it can't go to zero, that was the point -- at some level you have to pay for what you get. I'm not saying the compile times couldn't be better, but Rust can't be Go in terms of compile times if it wants to offer the guarantees and options it does. Meanwhile if Go wants to offer more options and stronger guarantees, it won't be able to preserve the short compile times everyone points to.
The Cranelift backend is extremely fast. Most of the slowness is all the crazy optimizations that LLVM does + other things (generating debug info etc).
For symbol heavy projects, linking is a surprising bottleneck.
Some ideas to speed up compilation by not evaluating items that are not used might pan out significantly for big crates in your dep tree (that behavior might never be stable because that would allow items with compile errors in a crate that would still let your application compile, which is against the Rust approach). The same work to do that would also allow overlapping of crate evaluation between different rustc instances called by cargo, as it would require partial evaluation of crates (to do name res only and gather the symbols needed from its deps).
Another thing is that stable rust doesn't treat macros as idempotent (because that wasn't a requirement from the start, there are crates that do dynamic IO to generate types), but if they are then incr comp can be faster by not evaluating them unnecessarily.
I know people are working on a bunch of different strategies to improve both first and incremental compile times, and I'm looking forward to the fruit of their labor.
Compile times are rarely the bottleneck for me, but that doesn't mean I won't welcome any improvements on that front.
> For symbol heavy projects, linking is a surprising bottleneck.
Is that still true with modern linkers like `wild`? Seems like it can link Chromium in 1-2s.
> Another thing is that stable rust doesn't treat macros as idempotent
This seems absolutely insane to me given how pervasive macros are in Rust (I wonder how much of incremental compilation time is just repeated serde derives?). Obviously we can't just blindly treat all macros as idempotent, but an opt-in attribute on a macros that pinky-promises that it is seems like it ought to be pretty easy to implement?
Maybe somebody's looked into it and it doesn't help much? But I've heard (unverified) rumours of the opposite.
> Is that still true with modern linkers like `wild`? Seems like it can link Chromium in 1-2s.
Wild improves things significantly, but it really depends on the kind of project. For some a third of the time can be linking. And not everyone configures their environment to use a different linker. Another thing that can easily improve performance is changing the global allocator, but I've seen teams that measured 10% perf improvements in their own metrics decide against going with anything other than the "default".
I fully expect that if wild delivers an effective incremental linking architecture, then rustc will be able to produce the patches directly (instead of wild having to produce patches from two versions of the object files), which would mean both that rustc is producing less LLVM bytecode and that wild gets to do what it (will) do best and make linking as fast as mechanically possible.
> This seems absolutely insane to me given how pervasive macros are in Rust
There was some work done on this front, but I haven't kept up to date on the current status of that. There was a PR showing promise <a href="https://github.com/rust-lang/rust/pull/129102" rel="nofollow">https://github.com/rust-lang/rust/pull/129102 (later landed as <a href="https://github.com/rust-lang/rust/pull/145354" rel="nofollow">https://github.com/rust-lang/rust/pull/145354, 10% on a specific serde-heavy crate, reports of 32% improvements in the original PR). The tracking issue doesn't have any updates <a href="https://github.com/rust-lang/rust/issues/151364" rel="nofollow">https://github.com/rust-lang/rust/issues/151364, but you can try out nightly with -Zcache-proc-macros to see what the effect could be on your projects.
Part of the problem I see is that crates will have to opt-in (and we might be able to change the default over an edition boundary) to get the perf benefit, and it might require a granularity lower than "a crate" (which would complicate implementation). I haven't seen additional discussions around these design considerations (needed to stabilize), which will need to happen before people can see progress.
Sadly, Rust is, like many open source projects, a show-up-o-cracy: you need a motivated (group of?) individual(s) to deliver a feature to fruition, and if the person driving a feature is fine with using nightly for their purposes, and only needs a subset of a feature, they will drive the feature to that state (lets say 80% completion), and then the feature will linger (until someone else with enough motivation to see the other 80% through shows up). This is exacerbated because the project is unwilling to have 80% solutions on stable unless the state is very clearly not going to preclude other future work, or the path to completion is 100% visible (but if that were the case, then it would have been completed already). So we end up with situations like the Allocator APIs.
(I did a quick test, and I'm seeing between 15-20% for <a href="https://github.com/servo/stylo" rel="nofollow">https://github.com/servo/stylo which is a macro-heavy crate. I guess it only matter for crates you're actually editing though, macro will already be cached as part of "entire crate is unchanged")
> Another thing that can easily improve performance is changing the global allocator, but I've seen teams that measured 10% perf improvements in their own metrics decide against going with anything other than the "default".
Yeah, although I think there's more of a trade-off there. Alternative allocators can add significant amounts of compile time. Whereas, modulo maturity, I think a faster linker is more of a pure win. I would imagine we will make wild the default linker at some point if development continues on the trajectory it seems to be on.
I’m not sure if Cranelift support will ever become stable. It’s really complex, it has tradeoffs like you mentioned, and it requires its own backend to be maintained. TPDE looks like something that could more realistically be stabilized as it just slots into the existing LLVM support.
Rust wants badly to have its cake and eat it too. I get it, but it's not the sensibilities I have. The rustc compiler, if it really can achieve everything all at once, will be a beast like none other, making C++ compilers look simple by comparison.
I'd love something halfway. Go is maybe a bit radical in some regards, but also, with the news of the new SIMD package for Go, it has occured to me just how little I missed having things like, say, autovectorization.
(I know also that some people have tried halfway, but the big thing is figuring out how to keep a relatively simple type system that can still support a borrow checker. Even if there is some middleground, is it truly worth it? As nice as it sounds, I've been more skeptical. Go seems to exist in a very narrow space where its simplifications barely can be made to work.)
Instead of Go, you could have reached out to complex languages with fast compilation times like D, OCaml, Haskell, Ada, Delphi, C++.
All of them have alternative implementations with fast compilation times.
D, use dmd for fast development workflows, gdc or ldc for the ultimate performance at the expense of compilation times.
OCaml, use the REPL or bytecode interpreter for fast development times, the full blow compiler for ultimate performance.
Haskell, use the REPL, GHCi for the fast development cycles, GHC for the release build.
Ada and Delphi, have had fast implementations since forever, although Ada/SPARK is indeed somehow expensive.
C++, yes it isn't a mistake. Use Live++, VS hot reload, coupled with binary libraries, or a REPL like CINT (nee ROOT), binary libraries for dependencies, incremental compilation and incremental linking for the development workflow.
The problem with Rust isn't the language itself, rather the ecosystem currently lacking such kind of options being available.
including c++ with all of those qualifiers would be like me saying rust is fast with sccache, subsecond, cranelift, and making every single module a separate crate.
The difference being the adoption culture across the ecosystem.
C++ game engines also don't need Bevy like tutorials, because most studios aren't compiling them from scratch, and tools like Live++ or VC++ hot reload are relatively easy to use.
unreal engine is compiled from scratch (depending on your definition of "from scratch") and has notoriously long compile times. heck you have to recompile the editor to make certain gameplay code changes. and it's by far the most popular AAA game engine on the planet. if it was so easy to fix with your suggestions they would have done it already.
but hey, just add subsecond and switch to cranelift. problem solved :)
Unreal Engine has an installer, and they have done my suggestions, as they are the main customers of Live++ [0], advocates of tooling like Blueprints and now Verse for doing full games.
Many studios have delivered games with little to no changes to the underlying C++ code.
so... c++ compile times are fast, because you can simply not compile c++ and instead use blueprints? seems odd since we're talking about c++/rust compile times. turns out you can make rust compile times infinitely faster by not compiling it too...
but when you do have to compile c++, it can be real slow. maybe not as slow as rust, but it's not in the same league as eg. go, c#, zig, etc.
ue5's hot reload is by no means perfect either - many gameplay code changes require recompiling the editor. exposing c++ properties on a blueprint? recompile. modify a constructor? recompile. changing parameters, return types, or adding/removing UFUNCTION or UPROPERTY macros? recompile. you can simply search the web to read the experiences of thousands of ue devs complaining about slow compile times and workflows. it's the same with unity btw, search "reloading domain unity".
also verse is not in unreal engine. no studio is using verse for ue games. not sure why you threw that in.
i get you love c++ and dislike rust, but you aren't really making a good case for c++ when you group it in with other languages that have fast compile times ootb, make arguments that involve not using c++ (like blueprints, lol), and rely on brittle third-party hot-reloading solutions.
I threw that in, because if you knew Unreal Engine, you would be aware of the roadmap for Unreal 6.
No one is saying that C++ compile times are anywhere close to Delphi or D, although they are much better when using modules actually.
Rather that C++ ecosystem has a developer culture and tools, that makes compiling from scratch and pure distribution of source code for what is a compiled language, something rare, thus despite its slowness, the average impact is less felt than on Rust projects.
Surac · · focus · HN ↗
What is the performance killer?
jerf · · focus · HN ↗
If you want something like Rust that offers guarantees and checks and cross-checks by the boatload, it adds up. Macros, monomorphization, implicit code generation with traits and all those other things add up too. And you can't always get O(n) or O(n log n) code to implement those checks. Maybe it can be sped up and maybe there's tricks here or there, but at the Pareto frontier, a language that has more checks will be slower to compile than one that has fewer.
And that's not a bad thing or a deficit in Rust, it's just the nature of the beast.
ch4s3 · · focus · HN ↗
[deleted] · · focus · HN ↗
[deleted]
ModernMech · · focus · HN ↗
So the focus on Rust compile time is misplaced. It's not a big deal in terms of overall productivity.
gpm · · focus · HN ↗
ModernMech · · focus · HN ↗
vlovich123 · · focus · HN ↗
estebank · · focus · HN ↗
Some ideas to speed up compilation by not evaluating items that are not used might pan out significantly for big crates in your dep tree (that behavior might never be stable because that would allow items with compile errors in a crate that would still let your application compile, which is against the Rust approach). The same work to do that would also allow overlapping of crate evaluation between different rustc instances called by cargo, as it would require partial evaluation of crates (to do name res only and gather the symbols needed from its deps).
Another thing is that stable rust doesn't treat macros as idempotent (because that wasn't a requirement from the start, there are crates that do dynamic IO to generate types), but if they are then incr comp can be faster by not evaluating them unnecessarily.
I know people are working on a bunch of different strategies to improve both first and incremental compile times, and I'm looking forward to the fruit of their labor.
Compile times are rarely the bottleneck for me, but that doesn't mean I won't welcome any improvements on that front.
nicoburns · · focus · HN ↗
Is that still true with modern linkers like `wild`? Seems like it can link Chromium in 1-2s.
> Another thing is that stable rust doesn't treat macros as idempotent
This seems absolutely insane to me given how pervasive macros are in Rust (I wonder how much of incremental compilation time is just repeated serde derives?). Obviously we can't just blindly treat all macros as idempotent, but an opt-in attribute on a macros that pinky-promises that it is seems like it ought to be pretty easy to implement?
Maybe somebody's looked into it and it doesn't help much? But I've heard (unverified) rumours of the opposite.
estebank · · focus · HN ↗
Wild improves things significantly, but it really depends on the kind of project. For some a third of the time can be linking. And not everyone configures their environment to use a different linker. Another thing that can easily improve performance is changing the global allocator, but I've seen teams that measured 10% perf improvements in their own metrics decide against going with anything other than the "default".
I fully expect that if wild delivers an effective incremental linking architecture, then rustc will be able to produce the patches directly (instead of wild having to produce patches from two versions of the object files), which would mean both that rustc is producing less LLVM bytecode and that wild gets to do what it (will) do best and make linking as fast as mechanically possible.
> This seems absolutely insane to me given how pervasive macros are in Rust
There was some work done on this front, but I haven't kept up to date on the current status of that. There was a PR showing promise <a href="https://github.com/rust-lang/rust/pull/129102" rel="nofollow">https://github.com/rust-lang/rust/pull/129102 (later landed as <a href="https://github.com/rust-lang/rust/pull/145354" rel="nofollow">https://github.com/rust-lang/rust/pull/145354, 10% on a specific serde-heavy crate, reports of 32% improvements in the original PR). The tracking issue doesn't have any updates <a href="https://github.com/rust-lang/rust/issues/151364" rel="nofollow">https://github.com/rust-lang/rust/issues/151364, but you can try out nightly with -Zcache-proc-macros to see what the effect could be on your projects.
Part of the problem I see is that crates will have to opt-in (and we might be able to change the default over an edition boundary) to get the perf benefit, and it might require a granularity lower than "a crate" (which would complicate implementation). I haven't seen additional discussions around these design considerations (needed to stabilize), which will need to happen before people can see progress.
Sadly, Rust is, like many open source projects, a show-up-o-cracy: you need a motivated (group of?) individual(s) to deliver a feature to fruition, and if the person driving a feature is fine with using nightly for their purposes, and only needs a subset of a feature, they will drive the feature to that state (lets say 80% completion), and then the feature will linger (until someone else with enough motivation to see the other 80% through shows up). This is exacerbated because the project is unwilling to have 80% solutions on stable unless the state is very clearly not going to preclude other future work, or the path to completion is 100% visible (but if that were the case, then it would have been completed already). So we end up with situations like the Allocator APIs.
nicoburns · · focus · HN ↗
> Another thing that can easily improve performance is changing the global allocator, but I've seen teams that measured 10% perf improvements in their own metrics decide against going with anything other than the "default".
Yeah, although I think there's more of a trade-off there. Alternative allocators can add significant amounts of compile time. Whereas, modulo maturity, I think a faster linker is more of a pure win. I would imagine we will make wild the default linker at some point if development continues on the trajectory it seems to be on.
dicytea · · focus · HN ↗
<a href="https://github.com/rust-lang/rustc_codegen_cranelift/issues/166" rel="nofollow">https://github.com/rust-lang/rustc_codegen_cranelift/issues/...
dabinat · · focus · HN ↗
jchw · · focus · HN ↗
I'd love something halfway. Go is maybe a bit radical in some regards, but also, with the news of the new SIMD package for Go, it has occured to me just how little I missed having things like, say, autovectorization.
(I know also that some people have tried halfway, but the big thing is figuring out how to keep a relatively simple type system that can still support a borrow checker. Even if there is some middleground, is it truly worth it? As nice as it sounds, I've been more skeptical. Go seems to exist in a very narrow space where its simplifications barely can be made to work.)
oscillonoscope · · focus · HN ↗
pjmlp · · focus · HN ↗
Instead of Go, you could have reached out to complex languages with fast compilation times like D, OCaml, Haskell, Ada, Delphi, C++.
All of them have alternative implementations with fast compilation times.
D, use dmd for fast development workflows, gdc or ldc for the ultimate performance at the expense of compilation times.
OCaml, use the REPL or bytecode interpreter for fast development times, the full blow compiler for ultimate performance.
Haskell, use the REPL, GHCi for the fast development cycles, GHC for the release build.
Ada and Delphi, have had fast implementations since forever, although Ada/SPARK is indeed somehow expensive.
C++, yes it isn't a mistake. Use Live++, VS hot reload, coupled with binary libraries, or a REPL like CINT (nee ROOT), binary libraries for dependencies, incremental compilation and incremental linking for the development workflow.
The problem with Rust isn't the language itself, rather the ecosystem currently lacking such kind of options being available.
Shorel · · focus · HN ↗
[deleted] · · focus · HN ↗
[deleted]
slopinthebag · · focus · HN ↗
pjmlp · · focus · HN ↗
C++ game engines also don't need Bevy like tutorials, because most studios aren't compiling them from scratch, and tools like Live++ or VC++ hot reload are relatively easy to use.
slopinthebag · · focus · HN ↗
but hey, just add subsecond and switch to cranelift. problem solved :)
pjmlp · · focus · HN ↗
Many studios have delivered games with little to no changes to the underlying C++ code.
[0] - <a href="https://dev.epicgames.com/documentation/unreal-engine/using-live-coding-to-recompile-unreal-engine-applications-at-runtime" rel="nofollow">https://dev.epicgames.com/documentation/unreal-engine/using-...
slopinthebag · · focus · HN ↗
but when you do have to compile c++, it can be real slow. maybe not as slow as rust, but it's not in the same league as eg. go, c#, zig, etc.
ue5's hot reload is by no means perfect either - many gameplay code changes require recompiling the editor. exposing c++ properties on a blueprint? recompile. modify a constructor? recompile. changing parameters, return types, or adding/removing UFUNCTION or UPROPERTY macros? recompile. you can simply search the web to read the experiences of thousands of ue devs complaining about slow compile times and workflows. it's the same with unity btw, search "reloading domain unity".
also verse is not in unreal engine. no studio is using verse for ue games. not sure why you threw that in.
i get you love c++ and dislike rust, but you aren't really making a good case for c++ when you group it in with other languages that have fast compile times ootb, make arguments that involve not using c++ (like blueprints, lol), and rely on brittle third-party hot-reloading solutions.
pjmlp · · focus · HN ↗
No one is saying that C++ compile times are anywhere close to Delphi or D, although they are much better when using modules actually.
Rather that C++ ecosystem has a developer culture and tools, that makes compiling from scratch and pure distribution of source code for what is a compiled language, something rare, thus despite its slowness, the average impact is less felt than on Rust projects.
slopinthebag · · focus · HN ↗
modules? you mean the thing where 2/3 major compilers still only have partial support for? how many major c++ projects are using modules?
i get it, you hate rust.
pjmlp · · focus · HN ↗
Office has been using C++ modules for a while now, I think they are major enough.
Nah, I hate lack of tooling, you missed my other examples from languages in the ML family.