Hacker News Reader

Comment by insanitybit | Hacker News Reader

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

View on HN

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

> 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) will land in Cargo that'll allow us to ship pre-compiled wasm blobs for proc-macros so we can just have sandboxed binaries.

That'll be great for proc-macros, although it won't work for build scripts.

Why not?

It could, in theory. But build scripts can do arbitrary things so the wasm sandbox would need to allow for that.

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.

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.

Reply on news.ycombinator.com