Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Rust is most definitely slow to compile compared to GCC or LLVM for C/C++. This is a known situation and has been since the pre-1.0 days because of the heavily front-loaded macro and borrow systems. It's the tradeoff you have for having a "safe" language vs a "trusting" one.

I would argue that it's not as bad as it's made out to be, especially if you're not doing full recompiles and using it on modern (2019+) hardware; but it is a noticeable difference in similar large codebases.




Rust macros are not the fault for its slowness. expansion is one of the fastest compilation phases. Time is rather spent in other steps like type checking, llvm optimizations and such. The issue is more Rust's generics as they cause a lot of code to be passed to llvm (among other issues for Rust's slowness).


Macro expansion is slow, but only noticeably in the specific situation of a) third-party proc macros, b) a debug build, and c) a few thousand invocations of said proc macros. This is because building in debug mode also compiles proc macros in debug mode, so while the macro itself compiles quickly (because it's an unoptimized build), it ends up running slowly (because it's an unoptimized build).

I know this from observing a ~90s difference between debug and release builds, of a large (mostly auto-generated) crate that had a couple of thousand `#[derive(serde::*)]`s. [1]

This doesn't affect most users, because first-party macros like `#[derive(Debug)]` etc are not slow because they're part of rustc and are thus optimized regardless of the profile, and even with third-party macros it is unlikely that they have thousands of invocations. Even if it is a problem, users can opt in to compiling just the proc macros in release mode. [2]

[1]: https://github.com/Arnavion/k8s-openapi/issues/4

[2]: https://github.com/rust-lang/cargo/issues/5622*


> Macro expansion is slow, but only noticeably in the specific situation of a) third-party proc macros, b) a debug build, and c) a few thousand invocations of said proc macros.

Oh that's interesting. But note that it's an issue caused by (from the perspective of the language) user code being slow, and also only if you compile in debug mode. You probably don't want to unconditionally compile proc macros in release mode, as most times they probably don't get invoked thousands of times. Ideally you would probably a) invoke macros in a parallel fashion, with multiple expansion threads, and b) maybe have rustc signal to cargo somehow that there are tons of invocations of a specific macro and that it might make more sense to recompile the proc macro with optimizations turned on.


It's slower then C for sure. But slower then C++? I doubt it.


C++ is only slower in heavy template metaprogramming.

Additionally thanks to heavy reliance on binary libraries, when starting a new project, we only need to compile our own code.


Rust is most comparable to C++ with heavy TMP, as it itself also makes use of templates.


To be precise, Rust generics perform monomorphization, which C++ templates also perform. But I wouldn't go so far as to compare the language to "C++ with heavy TMP", as that's far too broad of a characterization; TMP implies a lot of things, e.g. poor error messages, that Rust doesn't necessarily exhibit.


> TMP implies a lot of things, e.g. poor error messages, that Rust doesn't necessarily exhibit.

That's fair. My comment was mostly about performance.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: