3 ms·

> C++ has had slow compile times since forever, and so will Rust. Rust has a massive advantage, which is having a 'sanctioned' package manager and built-time c

> C++ has had slow compile times since forever, and so will Rust. Rust has a massive advantage, which is having a 'sanctioned' package manager and built-time capabilities. A huge part of Rust's slowdown is due to: a) Having to compile build scripts b) Those build scripts being built without optimizations (100s of times slower at runtime) If cargo + crates.io supports pre-built dependencies that is a massive optimization. This isn't theoretical or optimistic, it's just a fact - we can already see this by compiling build and proc macro crates with optimizations, it's just not the default and they still have to be compiled once. IF you remove that compilation time, again, it's not theoretical, it's turning N time spent on those deps into 0 time spent. There is easily a 200% performance win available, just from the known optimizations that are on the table.

vlakreeh 3y ago
> we can already see this by compiling build and proc macro crates with optimizations, it's just not the default and they still have to be compiled once. I'm hopeful something like watt (https://github.com/dtolnay/watt https://github.com/dtolnay/watt) will land in Cargo that'll allow us to ship pre-compiled wasm blobs for proc-macros so we can just have sandboxed binaries.
- insanitybit 3y ago
  That'll be great for proc-macros, although it won't work for build scripts.
  - adastra22 3y ago
    Why not?
    - insanitybit 3y ago
      It could, in theory. But build scripts can do arbitrary things so the wasm sandbox would need to allow for that.
      - adastra22 3y ago
        I think the whole point is to prevent build scripts from doing arbitrary things. The sandbox should give access to the source code being built, record changes to these files (and/or new files generated in the same directories), and that's about it.
        insanitybit 3y ago
        That's a cool idea but it would be a major breaking change. For proc-macros it's less of a major breaking change, though it is absolutely still one.
Rusky 3y ago
Rust has another advantage in the language itself- generic code can be type-checked and (partially) optimized before being instantiated. When you export a generic function in C++, every file that pulls it in has to re-parse it, and every instantiation has to re-type-check it. C++20 modules should help with the first part, but they can't help with the second (and neither can concepts). Further, separate translation units can wind up duplicating the same instantiations, which the linker has to deduplicate. When you export a generic function in Rust, by the time it gets pulled in somewhere else, it takes the form of pre-parsed, pre-type-checked MIR. It can also be pre-optimized, so type-independent optimization work is shared between instantiations. The compiler can also tell, before instantiation, which type parameters a function does not actually depend on, and essentially erase them ("polymorphization"). Further, Rust's compilation model reduces the redundant duplicate instantiations C++ does, both by using larger translation units and by automatically sharing any instantiations in dependencies with their dependents (though you can do this by hand in C++). (Incidentally, these differences also apply to inline functions- in C++ you wind up putting their definitions in headers and recompiling them from scratch over and over; in Rust they are shared MIR form.)

vlakreeh 3y ago

> we can already see this by compiling build and proc macro crates with optimizations, it's just not the default and they still have to be compiled once. I'm hopeful something like watt (https://github.com/dtolnay/watt https://github.com/dtolnay/watt) will land in Cargo that'll allow us to ship pre-compiled wasm blobs for proc-macros so we can just have sandboxed binaries.

insanitybit 3y ago
That'll be great for proc-macros, although it won't work for build scripts.
- adastra22 3y ago
  Why not?
  - insanitybit 3y ago
    It could, in theory. But build scripts can do arbitrary things so the wasm sandbox would need to allow for that.
    - adastra22 3y ago
      I think the whole point is to prevent build scripts from doing arbitrary things. The sandbox should give access to the source code being built, record changes to these files (and/or new files generated in the same directories), and that's about it.
      - insanitybit 3y ago
        That's a cool idea but it would be a major breaking change. For proc-macros it's less of a major breaking change, though it is absolutely still one.

Rusky 3y ago

Rust has another advantage in the language itself- generic code can be type-checked and (partially) optimized before being instantiated. When you export a generic function in C++, every file that pulls it in has to re-parse it, and every instantiation has to re-type-check it. C++20 modules should help with the first part, but they can't help with the second (and neither can concepts). Further, separate translation units can wind up duplicating the same instantiations, which the linker has to deduplicate. When you export a generic function in Rust, by the time it gets pulled in somewhere else, it takes the form of pre-parsed, pre-type-checked MIR. It can also be pre-optimized, so type-independent optimization work is shared between instantiations. The compiler can also tell, before instantiation, which type parameters a function does not actually depend on, and essentially erase them ("polymorphization"). Further, Rust's compilation model reduces the redundant duplicate instantiations C++ does, both by using larger translation units and by automatically sharing any instantiations in dependencies with their dependents (though you can do this by hand in C++). (Incidentally, these differences also apply to inline functions- in C++ you wind up putting their definitions in headers and recompiling them from scratch over and over; in Rust they are shared MIR form.)