There's really a paradox here. Rust claims to be a fast language, but compiling, even without optimizations on, takes ages ...

▲

barchar a day ago | parent | next [-]

Rust encourages a kind of generic programming that can result in generating too much code.

The compilation model is vastly, vastly, vastly better than languages like C++ and C, though, and it does compile much faster than an equivalent C++ build (doesn't count if you download precompiled binaries of your c++ dependencies)

▲

cozzyd a day ago | parent [-]

But the lack of ABI stability means that's not a choice anyway, doesn't it?

▲

SAI_Peregrinus a day ago | parent [-]

Rust can compile to dynamic libraries. If you don't use the C abi you have to compile anything that loads them with the same Rust compiler version and target triple. So you need to have some way to guarantee the correct compiler is being used, e.g. Nix or Bazel.

	▲	cozzyd a day ago \| parent [-]
		And possibly compilation options?

▲

IshKebab a day ago | parent | prev | next [-]

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.

▲

Matrixik a day ago | parent | next [-]

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

▲

kibwen a day ago | parent | prev | next [-]

There's no paradox here. You can use any benchmark you like to prove that Rust is a fast language. The work that the compiler does is irrespective of the language that rustc is written in.

▲

amelius a day ago | parent [-]

Yes, the benchmark is compiler compiling itself. From scratch and incrementally.

	▲	kibwen a day ago \| parent [-]
		Unfortunately, that isn't how any of this works.

▲

saghm a day ago | parent | prev | next [-]

Have you been similarly confused by how slow compiling can be for massive C++ projects for decades? I have trouble believing that you genuinely think that's what anyone means by saying Rut is fast.

▲

pjmlp a day ago | parent [-]

In C++ case usually is the outcome of compiling everything from source, not using binary libraries for dependencies, binary caching, pre-compiled headers, incremental compilation and linking.

Some of the items tend to be rather sub-optimal in UNIX based C++ compilers.

Using Visual C++ or C++ Builder with pre-compiled headers, or modules nowadays, working only on the main application, with everything else compiled as DLLs, COM, or packages (C++ Builder specific), incremental compiler, incremental linking, hot code reloading, is rather fast for the typical compile-debug-fix workflow.

	▲	saghm 12 hours ago \| parent [-]
		The comment I responded to said "Rust claims to be a fast language, but compiling, even without optimizations on, takes ages". I agree that if you skip compiling and just reuse stuff that was already compiled, then the time it takes to compile C++ is fast, but that's not really what was being discussed.

▲

aw1621107 a day ago | parent | prev [-]

> Rust claims to be a fast language, but compiling, even without optimizations on, takes ages ...

As usual, this begs the question of "compared to what"? "Fast" languages obviously don't have some magical ability to guarantee that every program written in them is Blazing Fast(tm); without further inspection one can come to any number of other equally plausible conclusions (e.g., the program is fast for what it does).