undefined

points

[-]

This is not actually the main reason, most of the time.

Generics/monomorphization and how iterators work results in a lot of compiler bytecode that has to be churned through. More bytecode = longer compilation. It increases the size of the (debug) binaries, the debuginfo in general, causes performance issues with debug binaries in some situations unless you bump the optimization level, causes more IO, etc.

by ModernMech7 hours ago|

parent|

[-]

If you don't use generics and monomorphization, then what explains it?

by dralley6 hours ago|

parent|

[-]

It's unlikely that many people are using Rust without using Option<T> or Result<T, U> a fair bit. Idiomatic Rust fundamentally uses a lot of generics. And a basic for loop expands into quite a lot of intermediate representation due to Iterator.

by ModernMech6 hours ago|

parent|

[-]

Other languages support generics, monomorphization, and iterators (e.g. Zig or D), but they're not as slow as Rust to compile, what's the reason for that?

by tialaramex6 hours ago|

parent|

[-]

It's likely easier to answer for specific languages

All three of those words can mean "just like Rust" but equally "Not at all like Rust" for different languages.

Two examples to contrast: In C++ the iterators are basically a pointer analog (in some cases they're just literally pointers) and that's a very difference "feature" but it's still definitely iterators. In Ginger Bill's Odin, the iterators are a function, possibly generic, which returns a pair, the next item and a boolean telling you whether the iterator was exhausted.

by gf0005 hours ago|

parent|

prev|

[-]

Zig has their own backend, monomorphization is afaik slow because LLVM itself.

On top the borrow checker and other features are non-existent in these languages.

by moritzruth6 hours ago|

parent|

prev|

[-]

AFAIK it's because of trait solving. And also not every language does monomorphization.

by kibwen5 hours ago|

parent|

[-]

Trait solving isn't a bottleneck for Rust compilation unless you're doing some extremely cursed things like trying to implement Doom in the type system. At the end of the day it's still mostly that Rust just generates a ton of IR for LLVM to chew on (because of monomorphization), then LLVM takes a while to process all of it (because LLVM is designed primarily to produce high-performance code, often resulting in reasonable tradeoffs against compilation speed), and then the linker takes a while to connect it all together. With an alternative backend to LLVM (e.g. Cranelift) you could choose to design it with a greater emphasis on compilation speed (likely trading off generated code quality in the process). And with a more radical vertically-integrated model where Rust controls the linker you could do in-place linking and nearly completely skip the final step (at least for debug builds), but that's a big change compared to the classic C-style build model.