4 ms·

The issue with Rust is the horrible compile times. I actively avoid Rust projects because they take too long to compile. I wish rustc had an option for disabl

• the8472 3y ago
  What are you compiling? I've "cargo install"-ed - which means deps had to be built too - two rust tools today on a 4c/8t laptop and they were done in maybe two minutes each. Building AUR packages of some C tools isn't much faster in comparison.
• deleted 3y ago
  [deleted]
• rthnbgrredf 3y ago
  How much longer does `rustc` typically take to compile the same programming tasks compared to `gcc`? Is it just "a bit" e.g. 50% slower or by an order of magnitude?
  • mostlylurks 3y ago
    It's not about the compiler, it's about the language. Rust, and C++ as well, have features that generally speaking require the compiler to do a significant amount of work to compile the program. Plain old C can easily compile more than an order of magnitude faster than an equivalent idiomatic Rust or C++ program, even if compiled with the same compiler suite (gcc).
  • fcantournet 3y ago
    You can install rust toolchain with https://rustup.rs/ https://rustup.rs/ in 1 minute, and git clone some project to see for yourself. It's impossible to answer your question directly, as it depends a lot on dependencies and language features.
  • llogiq 3y ago
    That very much depends on the code you're compiling. The factors that come into play are monomorphization (which means the compiler builds one copy of the code per type it is called for), procedural macros (which need to be fully compiled before being able to expand code using them), whether complex type shenanigans are used, etc. etc. Absent that, Rust will compile roughly as fast as C nowadays.
  • tczMUFlmoNk 3y ago
    I thought this was an interesting question, so I just compared GNU coreutils [1] and the uutils/coreutils Rust implementation [2]. I've never built either of these projects before, but I was able to easily build them both within a few minutes. I think they're of comparable size: uutils/coreutils has 102 coreutils programs, whereas GNU coreutils has 109 programs. And I liked your phrasing of testing the "same programming tasks": I'm sure that these projects have different implementation styles and philosophies, but at the end of the day they're both trying to implement a similar set of utilities. My hardware is an 11th gen Intel i7 (4-core, 8-thread) laptop. I included time to build but did excluded time to fetch dependencies. I measured real (wall) time and user time with time(1). I compiled clean release builds in both cases (I think). Here's what I found: uutils/coreutils: I fetched dependencies (`cargo fetch`) ahead of time, then just ran `time cargo build --release` to build everything. This took 1m37s wall time, 4m19s user time. It looked like about half of that time was spent compiling the `coreutils` multicall (Busybox-style) binary itself, after compiling all the individual `uu_*` utilities (`uu_cat`, etc.). GNU coreutils: I fetched dependencies (`git submodule update --init --recursive`) ahead of time, then read `README-hacking`, which indicates a three-step build process: time ./bootstrap: 2m42s wall time, 4m32s user time time ./configure: 0m36s wall time, 0m21s user time time make -j8: 0m21s wall time, 2m24s user time I don't know exactly what ./bootstrap is doing? It's a 1500-line shell script. It does seem to download pofiles at the start, so knock 10s off its runtime. A lot of its time seems to be spent in gnulib-tool(1); it runs aclocal(1) and m4(1) near the end, but I didn't notice it running cc(1). (I'm just watching top.) Maybe someone who knows this codebase better can comment how to fairly compare these. So, if we're measuring "time for clean release build on a new dev's machine (not including network fetches)", we're looking at ~200s for GNU coreutils and 97s for uutils/coreutils. If we discount ./bootstrap for whatever reason, that goes down to 57s vs. 97s. Either way, it seems within a factor of roughly 2, with the winner going one way or another depending on how you count. Methodology comments welcome. [1]: https://www.gnu.org/software/coreutils/#source https://www.gnu.org/software/coreutils/#source [2]: https://github.com/uutils/coreutils https://github.com/uutils/coreutils
    • herbstein 3y ago
      > It looked like about half of that time was spent compiling the coreutils multicall (Busybox-style) binary itself Using a different linker (like mold) might change that, if most of the time is spent linking everything together.
• queuebert 3y ago
  Compile times have greatly improved over the last few years. And if you aren't importing 100+ dependencies from Cargo.toml or using a lot of templates/traits (which I suspect kernel code won't), then it's even better. Edit: Also kernel compile times are a problem for the elite few, while kernel bugs are a problem for everyone.
  • NewJazz 3y ago
    Aren't common libraries like serde and clap known to slow down compile times?
    • sodality2 3y ago
      Yes, but Rust for Linux won’t be using these kinds of dependencies.
      • NewJazz 3y ago
        That's a good point. Rust in the Kernel is different from the general ecosystem.
    • vlovich123 3y ago
      The first time you build, sure but that’s true for C/C++ applications too (boost command_line or applications with lots of protobufs). Overall my experience that build times on Rust are waaaaaay better than C++ all things being equal (i.e. similar level of features). And honestly the developer experience of clap I’ve found to be a lot faster to work with than equivalent libraries in TypeScript which is saying something considering the typing on Rust is a lot more strict and cumbersome to work with.
    • junon 3y ago
      Yes, but not substantially - at least in comparison to *-sys crates which (surprise!) compile C/C++ most of the time.
• Analemma_ 3y ago
  I haven’t done any Rust-on-Linux development, but it seems like this would be a non-issue there? A lot of the compile time issues for Rust come from cargo packages pulling in tons of monomorphized types, but I assume Rust-on-Linux has few-to-no dependencies (I’m pretty sure they don’t even use the standard library).
  • sodality2 3y ago
    Yeah, when I’m doing zero-dependency development my compile times from scratch are never more than 5 seconds. Standard library actually shouldn’t increase compile time at all really, since it’s prebuilt and included for most platforms (excepting -Z build-std).
    • Analemma_ 3y ago
      I didn't mean to imply that the Rust standard library increases compile times, just that Rust-on-Linux is so dependency-lite (as evidenced by the lack of std) that I expect compile times to be good.
      • sodality2 3y ago
        True, I just mentioned that because it's bitten me before and I didn't expect it at all :)
• Kenji 3y ago
  Is there evidence that Rust compiles any slower than C++? Granted, it doesn't compile at the speed of C, but it does a lot more and you can write a lot denser code, so one line of Rust may easily supplant dozens of lines of C.
• spease 3y ago
  Compared to C, yes. However the tradeoff you get is tighter iteration, with more errors being found at compile-time rather than having to wait for runtime. If you have to restart an embedded system or schedule a job on a cluster to properly test, that can work out to huge savings. It would still be nice to see them substantially improve. I know there’s been effort to get debug mode to build substantially faster with cranelift, but I forget if that’s in stable now.
  • Laaas 3y ago
    Indeed, I'm merely complaining as an entitled end-user. As a developer Rust is much better than C.
• aw1621107 3y ago
  According to pcwalton appears avoiding monomorphization on its own may be unlikely to yield substantial gains [0]: > I doubt that a hypothetical version of Rust that avoided monomorphization would compile any faster. I remember doing experiments to that effect in the early days and found that monomorphization wasn't really slower. That's because all the runtime bookkeeping necessary to operate on value types generically adds up to a ton of code that has to be optimized away, and it ends up a wash in the end. As a point of comparison, Swift does all this bookkeeping, and it's not appreciably faster to compile than Rust; Swift goes this route for ABI stability reasons, not for compiler performance. > What you would need to go faster would be not only a non-monomorphizing compiler but also boxed types. That would be a very different language, one higher-level than even Go (which monomorphizes generics). [0]: https://news.ycombinator.com/item?id=38224941 https://news.ycombinator.com/item?id=38224941
• dymk 3y ago
  It's way faster than C++ - doubly so if you count "time spent grokking a compiler error" - and if that's the other option (it usually is), I'll take Rust
  • IshKebab 3y ago
    I agree it's faster than C++, but Linux is written in C which is much faster the C++ or Rust. Still, I would say Rust is fast enough now that compile time isn't a show stopper.
  • offices 3y ago
    If you spend enough time with C++ you become a compiler error transpiler that converts 100 lines of angle-bracket spam into what it 'really' means.
    • dymk 3y ago
      I eventually got to that point, but my doctor said the ulcer was getting out of control
• diarrhea 3y ago
  True, but I've been highly bullish on that: if that's a core complaint, it seems one of the easier ones to improve in the medium term. A host of other issues, which Rust notably doesn't suffer from, are almost "unfixable", even in the long term: think build system, type system, memory safety. Rust is fine in these regards.
• tmtvl 3y ago
  The only problem with Rust is that it has ALGOL syntax. If it had Lisp syntax it would be the perfect language.