4 ms·

It really puzzles me that people complain about compilation speed in Rust these days: I've worked on pretty big Rust code bases with lots of dependencies also,

It really puzzles me that people complain about compilation speed in Rust these days: I've worked on pretty big Rust code bases with lots of dependencies also, and cargo check has always been pretty much instant for me, including when I'm traveling and I use my mid-range laptop from 2012! (my main desktop is from 2018, I bought it because my previous desktop, from 2009 struggled to compile servo, mostly due to having too little RAM). Debug build take a bit longer (a few seconds) on the desktop, while still staying below a minute on the laptop (remember, I'm talking about a 12 years old Clevo laptop, not a recent Macbook). It's definitely not worse than Typescript compilation or even Javascript bundling, yet we pretty much never hear complains about how typescript has too big compile times. Yes, it could be faster with a different compiler architecture, especially on clean release builds and that would be nice, but it's a very minor annoyance (I don't do a full release build unless I've updated my compiler version, which only happens a few times a year). The contrast between the discourse and my day-to-day experience on near obsolete hardware is very striking. (Compilation artifact eating up hundreds of GB of my hard drive are a much, much bigger nuisance in practice, yet nobody seem to talk about that here on HN).

nicoburns 1y ago
> I don't do a full release build unless I've updated my compiler version, which only happens a few times a year That's probably part of the difference. I do tens of these every single day. GUI apps can be quite slow in debug mode, and as you say, the compilation artifacts build up quickly, which requires a cargo clean and then a fresh build.
- littlestymaar 1y ago
  > I do tens of these every single day. Tens of clean builds? I'm very curious: why? (because obviously that puts you in a completely different situation compared to someone who can rely on incremental builds) > GUI apps can be quite slow in debug mode Full debug mode, definitely, but in that case I've always found that building the dependencies in release mode was enough, but YMMV. But then that's what incremental rebuild are about. > and as you say, the compilation artifacts build up quickly, which requires a cargo clean and then a fresh build. I've mostly experienced the PITA when working with multiple code bases over time or in parallel, but surely it doesn't happen every day, let alone multiple times per day, does it?
  - nicoburns 1y ago
    > Tens of clean builds? I'm very curious: why? It's partly a privilege of being able to. I have an MacBook M1 Pro machine with 10 cores, so clean release builds are tolerable. The slowest project to compile I work on regularly in Servo and I can do a clean release build of that in 3-4 minutes. Most of the other projects I work on it's more 30s to 2m max. It's also a disk space thing. Between working on multiple different projects (I have 200 projects in total in my "open source repos" directory, most of those I only interact with very occasionally, but 5-10 in a day wouldn't be particuarly unusual for me) and switching between branches within projects I can build up 10s of GBs of data in the target dir within a few hours. And I don't have the largest SSD, so that can be a problem! So it's become habit to cargo clean reasonably regularly. Finally, sometimes I am explicitly testing compile time performance (which requires a clean build each time) or binary size (which involves using additional cargo profiles, exacerbating the disk space issues).
pjmlp 1y ago
This sample code took 12 minutes on a clean build on my travel netbook, now dead. https://github.com/pjmlp/gwc-rs https://github.com/pjmlp/gwc-rs Maybe nowadays it is faster, I have not bothered since I made the RIR exercise. Get the community editions of Delphi, FreePascal, or D and see what a fast build means. Better yet, take the lastest version of Turbo Pascal for MS-DOS, meaning 7, and try it out on FreeDOS.
- littlestymaar 1y ago
  > This sample code took 12 minutes on a clean build on my travel netbook, now dead. Clean builds are slow indeed. But they are also once every six week at most if switch to the latest compiler at every release. > Get the community editions of Delphi, FreePascal, or D and see what a fast build means. Honestly, who cares about the difference between 1s vs 100ms vs 10ms for a build though? Rust compilation isn't optimal by any means, and it wouldn't have been workable at all in the 90s, but computers are so fast today (even 13-years old computers) it rarely matters in practice IMHO.
  - alain_gilbert 1y ago
    > Honestly, who cares about the difference between 1s vs 100ms vs 10ms for a build though? I definitely do. Not necessarily because of the 10ms vs 1s. But because of the later stage when it becomes 600ms vs 60s.
    - littlestymaar 1y ago
      > But because of the later stage when it becomes 600ms vs 60s. What later stage though, as I said I worked with big code bases on old hardware without issues. I'm simply not convinced that there exist a situation where incremental rebuild of the crate you're working on is going to take 60s, at all, especially if you're using hardware from this decade.
      - alain_gilbert 1y ago
        I have a fairly small go project (100k loc) and it takes ~30sec to build. I'd be thrilled to have it build in 300ms. (Using a macbook pro 2019)
merely-unlikely 1y ago
It's still my number one complaint about Rust, even though it has definitely gotten better over time. Partly my fault - I'm stuck on a slightly underpowered Windows machine at work. My Macs at home compile significantly faster. But as soon as I add certain crates like serde, tokio, windows, and some others, the compile times grow quickly. It also means that tasks Rust isn't necessarily designed for but can be used for (like web backends) become frustrating enough to dissuade me from using it as a do-it-all language despite certain aspects of the language being really nice. Even a 30-45 second tweak-test loop becomes annoying after a while. Again more of a personal problem than anything, but the point is I personally am constantly frustrated with the compile times.

nicoburns 1y ago

> I don't do a full release build unless I've updated my compiler version, which only happens a few times a year That's probably part of the difference. I do tens of these every single day. GUI apps can be quite slow in debug mode, and as you say, the compilation artifacts build up quickly, which requires a cargo clean and then a fresh build.

littlestymaar 1y ago
> I do tens of these every single day. Tens of clean builds? I'm very curious: why? (because obviously that puts you in a completely different situation compared to someone who can rely on incremental builds) > GUI apps can be quite slow in debug mode Full debug mode, definitely, but in that case I've always found that building the dependencies in release mode was enough, but YMMV. But then that's what incremental rebuild are about. > and as you say, the compilation artifacts build up quickly, which requires a cargo clean and then a fresh build. I've mostly experienced the PITA when working with multiple code bases over time or in parallel, but surely it doesn't happen every day, let alone multiple times per day, does it?
- nicoburns 1y ago
  > Tens of clean builds? I'm very curious: why? It's partly a privilege of being able to. I have an MacBook M1 Pro machine with 10 cores, so clean release builds are tolerable. The slowest project to compile I work on regularly in Servo and I can do a clean release build of that in 3-4 minutes. Most of the other projects I work on it's more 30s to 2m max. It's also a disk space thing. Between working on multiple different projects (I have 200 projects in total in my "open source repos" directory, most of those I only interact with very occasionally, but 5-10 in a day wouldn't be particuarly unusual for me) and switching between branches within projects I can build up 10s of GBs of data in the target dir within a few hours. And I don't have the largest SSD, so that can be a problem! So it's become habit to cargo clean reasonably regularly. Finally, sometimes I am explicitly testing compile time performance (which requires a clean build each time) or binary size (which involves using additional cargo profiles, exacerbating the disk space issues).

pjmlp 1y ago

This sample code took 12 minutes on a clean build on my travel netbook, now dead. https://github.com/pjmlp/gwc-rs https://github.com/pjmlp/gwc-rs Maybe nowadays it is faster, I have not bothered since I made the RIR exercise. Get the community editions of Delphi, FreePascal, or D and see what a fast build means. Better yet, take the lastest version of Turbo Pascal for MS-DOS, meaning 7, and try it out on FreeDOS.

littlestymaar 1y ago
> This sample code took 12 minutes on a clean build on my travel netbook, now dead. Clean builds are slow indeed. But they are also once every six week at most if switch to the latest compiler at every release. > Get the community editions of Delphi, FreePascal, or D and see what a fast build means. Honestly, who cares about the difference between 1s vs 100ms vs 10ms for a build though? Rust compilation isn't optimal by any means, and it wouldn't have been workable at all in the 90s, but computers are so fast today (even 13-years old computers) it rarely matters in practice IMHO.
- alain_gilbert 1y ago
  > Honestly, who cares about the difference between 1s vs 100ms vs 10ms for a build though? I definitely do. Not necessarily because of the 10ms vs 1s. But because of the later stage when it becomes 600ms vs 60s.
  - littlestymaar 1y ago
    > But because of the later stage when it becomes 600ms vs 60s. What later stage though, as I said I worked with big code bases on old hardware without issues. I'm simply not convinced that there exist a situation where incremental rebuild of the crate you're working on is going to take 60s, at all, especially if you're using hardware from this decade.
    - alain_gilbert 1y ago
      I have a fairly small go project (100k loc) and it takes ~30sec to build. I'd be thrilled to have it build in 300ms. (Using a macbook pro 2019)

merely-unlikely 1y ago

It's still my number one complaint about Rust, even though it has definitely gotten better over time. Partly my fault - I'm stuck on a slightly underpowered Windows machine at work. My Macs at home compile significantly faster. But as soon as I add certain crates like serde, tokio, windows, and some others, the compile times grow quickly. It also means that tasks Rust isn't necessarily designed for but can be used for (like web backends) become frustrating enough to dissuade me from using it as a do-it-all language despite certain aspects of the language being really nice. Even a 30-45 second tweak-test loop becomes annoying after a while. Again more of a personal problem than anything, but the point is I personally am constantly frustrated with the compile times.