5 ms·

I was partly relying on the context offered by the article and my parent comment to imply that sure, Rust's compiler isn't the fastest in class, but the team ha

I was partly relying on the context offered by the article and my parent comment to imply that sure, Rust's compiler isn't the fastest in class, but the team has identified speed as a major outstanding problem and is working very actively to address it. Compilers are pretty hard. Languages like C and Go are able to short circuit the problem by having a simplistic type system, but the Rust team's main option here is hard work, and so far they seem to be more than willing to engage in it. > At best it can beat C++ compilers - C++ being a language whose build times people love to bemoan - but usually it does far worse. Citation needed on that one. How can you even make that kind of comparison fairly?

nickpsecurity 9y ago
It's one of those things that's happened to so many people with so many C++ compilers on projects of any significant size that almost everyone says it. Happened to me with several where I moved from a Pascal-like language to find the compile time terribly slow even when I barely used the language. A lot of it is do to how the language's syntax, semantics, and esp templating are designed. Plenty of languages with even more flexibility compile faster than C++ due to better design.
- brandur 9y ago
  Oh totally agreed that C++'s compilation times are (quite infamously) a mess. I think that my parent was asserting that Rust's compile times are "usually ... far worse" (the "it" in the quote above is a reference to Rust). For all I know, that might be true, but it's one of those "citation needed" type things.
  - nickpsecurity 9y ago
    Maybe I misread as I quickly moved through the thread. It does look ambiguous now. All I'll claim is horrible compile times on C++. I'm not sure where Rust is at now.
    - pjmlp 9y ago
      On personal projects sadly slower than C++ equivalents. But I do take advantage of all VC++ improvements for fast C++ compilation, even playing around with the ongoing research work for C++ modules.
      - nickpsecurity 9y ago
        How does it compare to the free C++ compilers in building large projects like you described in other post on 30 vs 5 min?
  - pjmlp 9y ago
    Personal experience. It takes me about half an hour to update rustfmt, racer and rustsym, every time a new Rust release comes out. On a dual core with 8 GB and HDD. On the same computer, any of my VC++ 2015/2017 builds, configured to take advantage of incremental compilation and linking, using forward classes and PIMPL idioms, with all third party dependencies already available as binary dependencies, takes around 5 minutes. Lack of incremental compilation and cargo not being able to deal with binaries dependencies has putted me off, after all if I want slow builds I can have them already in C++ when I go template meta-programming craziness, which are not that slow when using the experimental work Microsoft is doing with C++ modules. Also since our use of C++ is constrained to libraries used from Java/.NET/Android/iOS, the build times are usually relatively fast. Hard to sell Rust to anyone on the team, if that means their workflow would become slower, in spite of the safety improvements over C++.
    - oblio 9y ago
      Well, as you said, C++ had a ton more effort poured into the toolchain, at this stage.
    - MaulingMonkey 9y ago
      If my github api-fu is correct that's what, 40kloc for the rust side of things? Doesn't seem unreasonable times (vs C++) for a full rebuild on that machine - which I'd generally want to do for anything but the most trivial C++ toolchain bump too (in fact, I'm usually forced to) making a comparison against incremental builds very apples-to-oranges IMO. What's your C++ LOC/full rebuild like? I'm used to ~100kloc of C++ taking half an hour per config+platform on a 4-6 core, 16GB+, SSD machine. Less hygenic than your codebase sounds like, but with some beefy PCHs. Toolchain updates are usually a full day affair in this context, although that's not entirely from just the compiler bump. Of course, incremental vs full rebuilds are no contest. Rust is at least working on incremental builds now that they have MIR AFAIK. And binary cargo support would be really nice as well. As would be compiling in general.

nickpsecurity 9y ago

It's one of those things that's happened to so many people with so many C++ compilers on projects of any significant size that almost everyone says it. Happened to me with several where I moved from a Pascal-like language to find the compile time terribly slow even when I barely used the language. A lot of it is do to how the language's syntax, semantics, and esp templating are designed. Plenty of languages with even more flexibility compile faster than C++ due to better design.

brandur 9y ago
Oh totally agreed that C++'s compilation times are (quite infamously) a mess. I think that my parent was asserting that Rust's compile times are "usually ... far worse" (the "it" in the quote above is a reference to Rust). For all I know, that might be true, but it's one of those "citation needed" type things.
- nickpsecurity 9y ago
  Maybe I misread as I quickly moved through the thread. It does look ambiguous now. All I'll claim is horrible compile times on C++. I'm not sure where Rust is at now.
  - pjmlp 9y ago
    On personal projects sadly slower than C++ equivalents. But I do take advantage of all VC++ improvements for fast C++ compilation, even playing around with the ongoing research work for C++ modules.
    - nickpsecurity 9y ago
      How does it compare to the free C++ compilers in building large projects like you described in other post on 30 vs 5 min?
- pjmlp 9y ago
  Personal experience. It takes me about half an hour to update rustfmt, racer and rustsym, every time a new Rust release comes out. On a dual core with 8 GB and HDD. On the same computer, any of my VC++ 2015/2017 builds, configured to take advantage of incremental compilation and linking, using forward classes and PIMPL idioms, with all third party dependencies already available as binary dependencies, takes around 5 minutes. Lack of incremental compilation and cargo not being able to deal with binaries dependencies has putted me off, after all if I want slow builds I can have them already in C++ when I go template meta-programming craziness, which are not that slow when using the experimental work Microsoft is doing with C++ modules. Also since our use of C++ is constrained to libraries used from Java/.NET/Android/iOS, the build times are usually relatively fast. Hard to sell Rust to anyone on the team, if that means their workflow would become slower, in spite of the safety improvements over C++.
  - oblio 9y ago
    Well, as you said, C++ had a ton more effort poured into the toolchain, at this stage.
  - MaulingMonkey 9y ago
    If my github api-fu is correct that's what, 40kloc for the rust side of things? Doesn't seem unreasonable times (vs C++) for a full rebuild on that machine - which I'd generally want to do for anything but the most trivial C++ toolchain bump too (in fact, I'm usually forced to) making a comparison against incremental builds very apples-to-oranges IMO. What's your C++ LOC/full rebuild like? I'm used to ~100kloc of C++ taking half an hour per config+platform on a 4-6 core, 16GB+, SSD machine. Less hygenic than your codebase sounds like, but with some beefy PCHs. Toolchain updates are usually a full day affair in this context, although that's not entirely from just the compiler bump. Of course, incremental vs full rebuilds are no contest. Rust is at least working on incremental builds now that they have MIR AFAIK. And binary cargo support would be really nice as well. As would be compiling in general.