4 ms·

The long build times are a product of the type safety mechanisms built in. The language complexity is also a result of the qualities required for a low level l

The long build times are a product of the type safety mechanisms built in. The language complexity is also a result of the qualities required for a low level language that can manage memory and resources with precision. Ugly syntax is subjective; I find it expresses cleanly most of the things you want in the domain. Those are not really priorities of Rust or most of its domains anyway.

lifthrasiir 4y ago
Interestingly enough, there is actually a bit of common misconception going. Rust compiles pretty quick if you don't generate binary. If you don't believe me you can compare `cargo check` and `cargo build` yourself. The current bottleneck of Rust compilation time is actually LLVM; there has been lots of efforts to reduce this (including MIR, because less code passed to LLVM means less time spent in LLVM), but LLVM performance still remains a major factor.
svnpenn 4y ago
This whole comment reads as a series of rationalizations. I like Rust and write software with it, but I also understand that Rust has some big problems, that are either a long way from being fixed, or will never be fixed. > The long build times are a product of the type safety mechanisms built in. The long builds times are a product of the crate culture. Like JavaScript, many people are happy to pull in crates that are tiny to avoid having to write anything themself. So you end up with many packages pulling in over 100 crates.
- estebank 4y ago
  Funnily enough, total code size remaining constant, it is preferable to have more smaller crates than a few big ones. This is because the compilation unit in the Rust compiler is the crate, so having more independent crates allows for parallelization during compilation. You can argue that rustc should have either tools to help you split your large crates and/or automatically detect when a single crate has non-overlapping elements that could be compiled concurrently (but the former is not something anyone is working on to my knowledge and the later has the risk of small refactors significantly affecting compile times in an opaque way).

lifthrasiir 4y ago

Interestingly enough, there is actually a bit of common misconception going. Rust compiles pretty quick if you don't generate binary. If you don't believe me you can compare `cargo check` and `cargo build` yourself. The current bottleneck of Rust compilation time is actually LLVM; there has been lots of efforts to reduce this (including MIR, because less code passed to LLVM means less time spent in LLVM), but LLVM performance still remains a major factor.

svnpenn 4y ago

This whole comment reads as a series of rationalizations. I like Rust and write software with it, but I also understand that Rust has some big problems, that are either a long way from being fixed, or will never be fixed. > The long build times are a product of the type safety mechanisms built in. The long builds times are a product of the crate culture. Like JavaScript, many people are happy to pull in crates that are tiny to avoid having to write anything themself. So you end up with many packages pulling in over 100 crates.

estebank 4y ago
Funnily enough, total code size remaining constant, it is preferable to have more smaller crates than a few big ones. This is because the compilation unit in the Rust compiler is the crate, so having more independent crates allows for parallelization during compilation. You can argue that rustc should have either tools to help you split your large crates and/or automatically detect when a single crate has non-overlapping elements that could be compiled concurrently (but the former is not something anyone is working on to my knowledge and the later has the risk of small refactors significantly affecting compile times in an opaque way).