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).
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.
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.
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 ↗
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 ↗