9 ms·

The first thing I implore everyone to do when evaluating Rust is to check out a non trivial project and start hacking on it. I have always found the compiler to

The first thing I implore everyone to do when evaluating Rust is to check out a non trivial project and start hacking on it. I have always found the compiler to be unacceptably slow in these cases, especially if you come from C rather than C++. If you work your way up from Hello World you may not ever notice this until you already invested a substantial amount of effort.

Gwypaas 4y ago
I have never found this to be the case as long as you are using workspaces to split up the compilation units.
rowanG077 4y ago
Could you point me towards a project where this is the case? I want to try it out as I never found Rust slow to compile.
- deaddodo 4y ago
  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.
  - rowanG077 4y ago
    It's slower then C for sure. But slower then C++? I doubt it.
    - est31 4y ago
      Rust is most comparable to C++ with heavy TMP, as it itself also makes use of templates.
      - kibwen 4y ago
        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.
        est31 4y ago
        > 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.
    - pjmlp 4y ago
      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.
  - est31 4y ago
    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).
    - Arnavion 4y ago
      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 https://github.com/Arnavion/k8s-openapi/issues/4 [2]: https://github.com/rust-lang/cargo/issues/5622 https://github.com/rust-lang/cargo/issues/5622*
      - est31 4y ago
        > 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.
- ergonaught 4y ago
  “I’ve never been bothered by the compilation speed” is not the same thing as “It isn’t slow to compile.”
  - rowanG077 4y ago
    Sure! I didn't claim anything close "it isn't not slow to compile" and I'm not sure how you could interpret my comment like that. Notice how I clearly asked to be educated.
nicoburns 4y ago
> I have always found the compiler to be unacceptably slow in these cases, especially if you come from C rather than C++ I’ve found this to be highly dependent on the hardware you are using. On my 2015 MacBook Pro, Rust was slow enough to be annoying. On my new M1 Pro MacBook (which is ~9x faster), it’s fast enough for me not to notice compile times.
rapsey 4y ago
Slower compile times are a small price to pay for memory safety and much higher productivity.
- saagarjha 4y ago
  Slow compile times can reduce productivity.
  - rapsey 4y ago
    Not nearly as much as chasing bugs that do not happen in Rust.
    - saagarjha 4y ago
      That would depend on what you're doing, of course :)
      - rapsey 4y ago
        No not at all.
        saagarjha 4y ago
        …perhaps you lack experience of a time where fixing bugs that cannot be effectively discovered using tools available in other languages took less time than the equivalent code in Rust would take to compile?
        rapsey 4y ago
        Yet all the tools that exist still don't prevent memory safety bugs found regularly in pretty much any C codebase. Using safe rust will be a productivity boon because of its type system, crate ecosystem and memory safety.
        4y ago
pen2l 4y ago
Look into Apple silicon - lots of cache, great branch predictions, pointer-chasing prefetchers and more to subside just about all of your compiling worries.
- saagarjha 4y ago
  Hmph, I wish…
wongarsu 4y ago
On the other hand, I've always found it surprisingly easy to dive into non-trivial rust projects and start contributing, at a speed that would be unthinkable in C or C++. So I second the advise for non-trivial projects, they give a much better idea of the upsides and downsides of rust.
- 9dev 4y ago
  Is that really due to the language or that we collectively have become better in structuring software projects?
  - Sharlin 4y ago
    You can trust the compiler to yell at you when you break many invariants that would be tacit and implicit in C and even in C++ (even with best practices followed) which can make you much more productive when you’re just familiarizing yourself with a codebase. Also, the two aren’t necessarily mutually exclusive. Many people learning the language have reported being surprised by the way Rust seems to make "doing things right" the path of least effort, and this applies to best practices in general, not just memory safety.
    - db48x 4y ago
      I’ve had that experience. I had to write code for a complicated reference counted datastructure. The code was a mess at first because I was approaching it the wrong way, but once I understood it well enough to write it correctly all the pieces fell into place. Extraneous complexity was eliminated, and all the possible mistakes turned out to be impossible. The resulting code is so simple and straight forward that anyone can read it and see that it is correct. And as is traditional, the first time it compiled it was correct in all respects.
  - the__alchemist 4y ago
    I'm suspicious of this as well. It's common for OSS C and C++ projects (at least in embedded) to be mostly undocumented / few comments, have no easy way to debug by printing to console, and have a complicated build process that requires a certain OS and setup. Top doc comment: The same license info that's in every file. Not helpful for describing what the module does and how it fits in with the rest of the project.
modernerd 4y ago
I class Bevy as a “non trivial” project. It's also an example of how to immediately set new Rust devs up with better system performance to reduce the problem you mention where compilation becomes a bottleneck as a project grows. https://bevyengine.org/learn/book/getting-started/setup/ https://bevyengine.org/learn/book/getting-started/setup/ The early setup docs offer ways to improve compile speeds. Some help all Rust projects (change your linker) and others are specific to Bevy (enable dynamic linking if you're not on Windows). Yes, it's a little jarring for an intro to game development with Rust to start with, “first, change a bunch of things so your compile speeds don't suck by default”. But I appreciated it because it helps you evaluate Bevy properly (it's as fast as it'll get from that point) and it also made my non-game Rust project workflows faster. Bevy also sets expectations well about the initial slow-ish build (“This will take some time as you are essentially building an engine from scratch. You will only need to do a full rebuild once. Every build after this one will be fast!”).
- vvanders 4y ago
  Yeah Bevy does a fantastic job here(which given the focus on iteration time for gamedev makes sense). With the dynamic link feature it takes about 1s to compile + link and Bevy is very much a nontrivial runtime/library that makes use of lots of Rust features.
demindiro 4y ago
> have always found the compiler to be unacceptably slow in these cases How slow is "unacceptably" slow? Personally I do not find this to be an issue the vast majority of the time. Especially in combination with cargo watch which can automatically run a check/build/tests/... whenever a change is made.
kibwen 4y ago
I work on quite a large Rust project, and my regular `cargo check` takes around 5 seconds. Of course, I'd be happy if it were instantaneous, but "two deep breaths" worth of turnaround time is hardly a deal-breaker, especially given all the bugs that the compiler prevents for free that I don't need to spend time tracking down. EDIT: I checked just now and it takes one second to `cargo check` the shallowest crate in our workspace, and six to check the deepest.
sanderjd 4y ago
I think this is good advice! But YMMV; I've also always found the compiler to be slow, but acceptably so for what it's giving me.
WuxiFingerHold 4y ago
Splitting your projects in smaller packages by using workspaces helps a lot reducing the compile time.

Gwypaas 4y ago

I have never found this to be the case as long as you are using workspaces to split up the compilation units.

rowanG077 4y ago

Could you point me towards a project where this is the case? I want to try it out as I never found Rust slow to compile.

deaddodo 4y ago
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.
- rowanG077 4y ago
  It's slower then C for sure. But slower then C++? I doubt it.
  - est31 4y ago
    Rust is most comparable to C++ with heavy TMP, as it itself also makes use of templates.
    - kibwen 4y ago
      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.
      - est31 4y ago
        > 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.
  - pjmlp 4y ago
    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.
- est31 4y ago
  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).
  - Arnavion 4y ago
    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 https://github.com/Arnavion/k8s-openapi/issues/4 [2]: https://github.com/rust-lang/cargo/issues/5622 https://github.com/rust-lang/cargo/issues/5622*
    - est31 4y ago
      > 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.
ergonaught 4y ago
“I’ve never been bothered by the compilation speed” is not the same thing as “It isn’t slow to compile.”
- rowanG077 4y ago
  Sure! I didn't claim anything close "it isn't not slow to compile" and I'm not sure how you could interpret my comment like that. Notice how I clearly asked to be educated.

nicoburns 4y ago

> I have always found the compiler to be unacceptably slow in these cases, especially if you come from C rather than C++ I’ve found this to be highly dependent on the hardware you are using. On my 2015 MacBook Pro, Rust was slow enough to be annoying. On my new M1 Pro MacBook (which is ~9x faster), it’s fast enough for me not to notice compile times.

rapsey 4y ago

Slower compile times are a small price to pay for memory safety and much higher productivity.

saagarjha 4y ago
Slow compile times can reduce productivity.
- rapsey 4y ago
  Not nearly as much as chasing bugs that do not happen in Rust.
  - saagarjha 4y ago
    That would depend on what you're doing, of course :)
    - rapsey 4y ago
      No not at all.
      - saagarjha 4y ago
        …perhaps you lack experience of a time where fixing bugs that cannot be effectively discovered using tools available in other languages took less time than the equivalent code in Rust would take to compile?
        rapsey 4y ago
        Yet all the tools that exist still don't prevent memory safety bugs found regularly in pretty much any C codebase. Using safe rust will be a productivity boon because of its type system, crate ecosystem and memory safety.
        4y ago

pen2l 4y ago

Look into Apple silicon - lots of cache, great branch predictions, pointer-chasing prefetchers and more to subside just about all of your compiling worries.

saagarjha 4y ago
Hmph, I wish…

wongarsu 4y ago

On the other hand, I've always found it surprisingly easy to dive into non-trivial rust projects and start contributing, at a speed that would be unthinkable in C or C++. So I second the advise for non-trivial projects, they give a much better idea of the upsides and downsides of rust.

9dev 4y ago
Is that really due to the language or that we collectively have become better in structuring software projects?
- Sharlin 4y ago
  You can trust the compiler to yell at you when you break many invariants that would be tacit and implicit in C and even in C++ (even with best practices followed) which can make you much more productive when you’re just familiarizing yourself with a codebase. Also, the two aren’t necessarily mutually exclusive. Many people learning the language have reported being surprised by the way Rust seems to make "doing things right" the path of least effort, and this applies to best practices in general, not just memory safety.
  - db48x 4y ago
    I’ve had that experience. I had to write code for a complicated reference counted datastructure. The code was a mess at first because I was approaching it the wrong way, but once I understood it well enough to write it correctly all the pieces fell into place. Extraneous complexity was eliminated, and all the possible mistakes turned out to be impossible. The resulting code is so simple and straight forward that anyone can read it and see that it is correct. And as is traditional, the first time it compiled it was correct in all respects.
- the__alchemist 4y ago
  I'm suspicious of this as well. It's common for OSS C and C++ projects (at least in embedded) to be mostly undocumented / few comments, have no easy way to debug by printing to console, and have a complicated build process that requires a certain OS and setup. Top doc comment: The same license info that's in every file. Not helpful for describing what the module does and how it fits in with the rest of the project.

modernerd 4y ago

I class Bevy as a “non trivial” project. It's also an example of how to immediately set new Rust devs up with better system performance to reduce the problem you mention where compilation becomes a bottleneck as a project grows. https://bevyengine.org/learn/book/getting-started/setup/ https://bevyengine.org/learn/book/getting-started/setup/ The early setup docs offer ways to improve compile speeds. Some help all Rust projects (change your linker) and others are specific to Bevy (enable dynamic linking if you're not on Windows). Yes, it's a little jarring for an intro to game development with Rust to start with, “first, change a bunch of things so your compile speeds don't suck by default”. But I appreciated it because it helps you evaluate Bevy properly (it's as fast as it'll get from that point) and it also made my non-game Rust project workflows faster. Bevy also sets expectations well about the initial slow-ish build (“This will take some time as you are essentially building an engine from scratch. You will only need to do a full rebuild once. Every build after this one will be fast!”).

vvanders 4y ago
Yeah Bevy does a fantastic job here(which given the focus on iteration time for gamedev makes sense). With the dynamic link feature it takes about 1s to compile + link and Bevy is very much a nontrivial runtime/library that makes use of lots of Rust features.

demindiro 4y ago

> have always found the compiler to be unacceptably slow in these cases How slow is "unacceptably" slow? Personally I do not find this to be an issue the vast majority of the time. Especially in combination with cargo watch which can automatically run a check/build/tests/... whenever a change is made.

kibwen 4y ago

I work on quite a large Rust project, and my regular `cargo check` takes around 5 seconds. Of course, I'd be happy if it were instantaneous, but "two deep breaths" worth of turnaround time is hardly a deal-breaker, especially given all the bugs that the compiler prevents for free that I don't need to spend time tracking down. EDIT: I checked just now and it takes one second to `cargo check` the shallowest crate in our workspace, and six to check the deepest.

sanderjd 4y ago

I think this is good advice! But YMMV; I've also always found the compiler to be slow, but acceptably so for what it's giving me.

WuxiFingerHold 4y ago

Splitting your projects in smaller packages by using workspaces helps a lot reducing the compile time.