You missed "without optimizations on".

This is important, because most often during development you want fast compilation times more than you want fast code.

That still isn't a paradox. Furthermore it still makes sense: a language designed to generate the fastest code has constructs that cannot be compiled quickly, even without optimizations.

But some of it is implementation problems.

▲

adastra22 a day ago | parent [-]

Rust's compilation speed issues are not due to optimizations. There is some intrinsic slowness, but also some boneheaded decisions that are now baked in. E.g. the unit of compilation being the crate, not file/module, makes it so you hit some bad scaling laws. And the borrow checker is SLOW, and unavoidably so, but borrow checking could have been avoided with different lifetime rules. Etc.

I say this as a full-time rust developer btw.

	▲	aw1621107 a day ago \| parent \| next [-]
		> And the borrow checker is SLOW, and unavoidably so IIRC for most codebases borrowck actually makes up a pretty small proportion of compilation time (e.g., see [0] for some admittedly rough estimates). > but borrow checking could have been avoided with different lifetime rules. I'm not sure you could entirely avoid borrow checking without a pretty significant change to what you're allowed to do with references. [0]: https://kobzol.github.io/rust/rustc/2024/03/15/rustc-what-ta...
	▲	afdbcreid 16 hours ago \| parent \| prev [-]
		Rust is indeed not designed for quick compilation. Furthermore and unlike what you said, what makes it memory safe has pretty little to do with that. But what makes it fast definitely has to do with that, which is what I said.