That's not a paradox, that's how it always works. Compiling to fast machine code requires more work and takes longer.

Is Python a fast language because it barely takes any time to compile the code? No obviously not.

Looks like people extending rust never really focused on compile speed when designing features (from [1]):

> If you could reinvent/change any aspect of Rust, what would you do alternatively?

> A lot happened because we wanted to ship a useful thing with only so much time in the day, so some things were less deliberate than others. There’s an alternate version of Rust with significantly faster compiler times, because while we cared about compile times when designing we always prioritized other values more. We never asked ourselves how this feature or implementation impacted compiler analysis time and there are several spots where something slightly different would have much faster compiler times, which people do care about. But had we spent time on that, we would have neglected other things and not been any more successful.

[1]: https://alexalejandre.com/interviews/interview-with-steve-kl...

▲

amelius a day ago | parent | prev [-]

You missed "without optimizations on".

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

▲

afdbcreid a day ago | parent [-]

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