6 ms·

As a former C++ developer, claims that rust compilation is slow leave me scratching my head.

shadowgovt 1y ago
I thorougly enjoy all the work on encapsulation and reducing the steps of compilation to compile, then link that C does... Only to have C++ come along and undo almost all of it through the simple expedient of requiring templates for everything. Oops, changed one template in one header. And that impacts.... 98% of my code.
eikenberry 1y ago
Which is one of the reasons why Rust is considered to be targeting C++'s developers. C++ devs already have the Stockholm syndrome needed to tolerate the tooling.
- MyOutfitIsVague 1y ago
  Rust's compilation is slow, but the tooling is just about the best that any programming language has.
  - GuB-42 1y ago
    How good is the debugger? "edit and continue"? Hot reload? Full IDE? I don't know enough Rust, but I find these aspects are seriously lacking in C++ on Linux, and it is one of the few things I think Windows has it better for developers. Is Rust better?
    - adastra22 1y ago
      No idea because I never do that. Nor does any rust programmer I know. Which may answer your question ;)
      - frollogaston 1y ago
        "Rust devs don't use debuggers" isn't a good answer. The one time I used Rust for some project like 7 years ago, I did have to use a debugger, and it was fine.
      - GuB-42 1y ago
        If programmers don't use a debugger, that's because the debugger is bad. For me, the ideal debugger is one you never leave. That is you are in a debugging session, maybe with your code running, or stopped on a breakpoint, and you write your code without leaving the session. You can see the values of your variables as you type them, the branches that will be taken, etc... When an error condition happen, you break on it, and still without leaving the session, you can fix the code, roll back before the error happened and see if it passes. IntelliJ is close to that, and it seems like some tools from the video game industry are even better. Debugging should be natural, it shouldn't be something you pull out as a last resort. If it is not natural, it is a bad debugger, or a bad development environment, period. Maybe there are reasons for why it is bad, maybe the language designers have other priorities, which is acceptable, but it doesn't change the fact that it is bad. Same goes for slow compile times by the way.
    - mdaniel 1y ago
      > How good is the debugger? "edit and continue"? Relevant: Subsecond: A runtime hotpatching engine for Rust hot-reloading - https://news.ycombinator.com/item?id=44369642 https://news.ycombinator.com/item?id=44369642 - June, 2024 (36 comments) > Full IDE? https://www.jetbrains.com/rust/ https://www.jetbrains.com/rust/ (newly free for non-commercial use) > find these aspects are seriously lacking in C++ on Linux https://www.jetbrains.com/clion/ https://www.jetbrains.com/clion/ (same, non-commercial)
    - steveklabnik 1y ago
      > debugger I've only ever really used a debugger on embedded, we used gdb there. I know VS: Code has a debugger that works, I'm sure other IDEs do too. > edit and continue Hard to do in a pre-compiled language with no runtime, if you're asking about what I think you're asking about. > Hot reload Other folks gave you good links, but this stuff is pretty new, so I wouldn't claim that this is great and often good and such. > Full IDE I'm not aware of Rust-specific IDEs, but many IDEs have good support for Rust. VS: Code is the most popular amongst users according to the annual survey. The Rust Project distributes an official LSP server, so you can use that with any editor that supports it.
      - izacus 1y ago
        So the answer is very clear "no" on all accounts, just like for other languages built by people who don't understand the value of good tooling.
        frollogaston 1y ago
        I haven't used Rust much, but the tooling felt very solid. There's a default package manager that works well, unlike many other languages including C++ and somehow Python. Debugging is fine. Idk why you expected edit-and-continue, it's not like you get that in C++ either.
        GuB-42 1y ago
        You have "edit and continue" in Visual Studio (the real IDE, not VS Code). And I mentioned it as a downside of C++ on Linux, and I would expect a language that has "the best" tooling to have that. C++ tooling isn't that great, but it has one thing going for it: it is popular in the video game industry, and the video industry has some of the best tools. And sure enough, if by tooling you mean "package management", I'd say everything is better than C++, and on the other side, it seems that cargo is pretty good. I don't know how they tackle the "left-pad" problem that plagues npm though. By that I mean supply-chain attacks.
        1y ago
  - adastra22 1y ago
    Slow compared to what? I’m still scraping my head at this. My cargo builds are insanely fast, never taking more than a minute or two even on large projects. The only ahead of time compiled language I’ve used with faster compilation speed is Go, and that is a language specifically designed around (and arguably crippled by) the requirement for fast compilation. Rust is comparable to C compilation, and definitely faster than C++, Haskell, Java, Fortran, Algol, and Common Lisp.
    - deleted 1y ago
      [deleted]
    - johnisgood 1y ago
      Just a few days ago I used cargo to install something. It took like two minutes at the last stage. Definitely not comparable to C or Fortran. I never had to wait that much before. With C++? Definitely. Never with C though.
    - eikenberry 1y ago
      In addition to Go, off the top of my head, you have D, V-lang, Zig, Lua and every interpreted language (including Haskell and Common Lisp, as they both have interpreters). Traditional compiled languages always had terrible UX in this regard which, IMO, is why interpreted languages like Python and Ruby got so popular.
- zozbot234 1y ago
  > Stockholm syndrome A.k.a. "Remember the Vasa!" https://news.ycombinator.com/item?id=17172057 https://news.ycombinator.com/item?id=17172057
- galangalalgol 1y ago
  Also modern c++ with value semantics is more functional than many other languages people might come to rust from, that keeps the borrow checker from being as annoying. If people are used to making webs of stateful classes with references to each pther. The borrow checker is horrific, but that is because that design pattern is horrific if you multithread it.
MobiusHorizons 1y ago
Things can still be slow in absolute terms without being as slow as C++. The issues with compiling C++ are incredibly well understood and documented. It is one of the worst languages on earth for compile times. Rust doesn’t share those language level issues, so the expectations are understandably higher.
- int_19h 1y ago
  But it does share some of those issues. Specifically, while Rust generics aren't as unstructured as C++ templates, the main burden is actually from compiling all those tiny instantiations, and Rust monomorphization has the same exact problem responsible for the bulk of its compile times.
- const_cast 1y ago
  Rust shares pretty much every language-level issue C++ has with compile times, no? Monomorphization explosion, turing-complete compile time macros, complex type system.
  - steveklabnik 1y ago
    There's a lot of overlap, but not that simple. Unless you also discount C issues that C++ inherits. Even then, there's subtleties and differences between the two that matter.
- pjmlp 1y ago
  And easily solved with incremental compilers, incremental linkers, external templates and nowadays modules.
oreally 1y ago
Classic case of: New features: yes Talking to users and fixing actual problems: lolno, I CBF
pjmlp 1y ago
Not sure about you, but traditionally my C++ have always been faster than out of the box experience with Rust. Thanks to pre-compiled headers, incremental compiler, incremental linker, and using binary libraries for all dependencies. Nowadays modules as well. Rust compiles from scratch, some crates might get compiled multiple times due to conflicting configurations on the dependency graph, binary libraries require additional setup for something like scache.

I thorougly enjoy all the work on encapsulation and reducing the steps of compilation to compile, then link that C does... Only to have C++ come along and undo almost all of it through the simple expedient of requiring templates for everything. Oops, changed one template in one header. And that impacts.... 98% of my code.

eikenberry 1y ago

Which is one of the reasons why Rust is considered to be targeting C++'s developers. C++ devs already have the Stockholm syndrome needed to tolerate the tooling.

MyOutfitIsVague 1y ago
Rust's compilation is slow, but the tooling is just about the best that any programming language has.
- GuB-42 1y ago
  How good is the debugger? "edit and continue"? Hot reload? Full IDE? I don't know enough Rust, but I find these aspects are seriously lacking in C++ on Linux, and it is one of the few things I think Windows has it better for developers. Is Rust better?
  - adastra22 1y ago
    No idea because I never do that. Nor does any rust programmer I know. Which may answer your question ;)
    - frollogaston 1y ago
      "Rust devs don't use debuggers" isn't a good answer. The one time I used Rust for some project like 7 years ago, I did have to use a debugger, and it was fine.
    - GuB-42 1y ago
      If programmers don't use a debugger, that's because the debugger is bad. For me, the ideal debugger is one you never leave. That is you are in a debugging session, maybe with your code running, or stopped on a breakpoint, and you write your code without leaving the session. You can see the values of your variables as you type them, the branches that will be taken, etc... When an error condition happen, you break on it, and still without leaving the session, you can fix the code, roll back before the error happened and see if it passes. IntelliJ is close to that, and it seems like some tools from the video game industry are even better. Debugging should be natural, it shouldn't be something you pull out as a last resort. If it is not natural, it is a bad debugger, or a bad development environment, period. Maybe there are reasons for why it is bad, maybe the language designers have other priorities, which is acceptable, but it doesn't change the fact that it is bad. Same goes for slow compile times by the way.
  - mdaniel 1y ago
    > How good is the debugger? "edit and continue"? Relevant: Subsecond: A runtime hotpatching engine for Rust hot-reloading - https://news.ycombinator.com/item?id=44369642 https://news.ycombinator.com/item?id=44369642 - June, 2024 (36 comments) > Full IDE? https://www.jetbrains.com/rust/ https://www.jetbrains.com/rust/ (newly free for non-commercial use) > find these aspects are seriously lacking in C++ on Linux https://www.jetbrains.com/clion/ https://www.jetbrains.com/clion/ (same, non-commercial)
  - steveklabnik 1y ago
    > debugger I've only ever really used a debugger on embedded, we used gdb there. I know VS: Code has a debugger that works, I'm sure other IDEs do too. > edit and continue Hard to do in a pre-compiled language with no runtime, if you're asking about what I think you're asking about. > Hot reload Other folks gave you good links, but this stuff is pretty new, so I wouldn't claim that this is great and often good and such. > Full IDE I'm not aware of Rust-specific IDEs, but many IDEs have good support for Rust. VS: Code is the most popular amongst users according to the annual survey. The Rust Project distributes an official LSP server, so you can use that with any editor that supports it.
    - izacus 1y ago
      So the answer is very clear "no" on all accounts, just like for other languages built by people who don't understand the value of good tooling.
      - frollogaston 1y ago
        I haven't used Rust much, but the tooling felt very solid. There's a default package manager that works well, unlike many other languages including C++ and somehow Python. Debugging is fine. Idk why you expected edit-and-continue, it's not like you get that in C++ either.
        GuB-42 1y ago
        You have "edit and continue" in Visual Studio (the real IDE, not VS Code). And I mentioned it as a downside of C++ on Linux, and I would expect a language that has "the best" tooling to have that. C++ tooling isn't that great, but it has one thing going for it: it is popular in the video game industry, and the video industry has some of the best tools. And sure enough, if by tooling you mean "package management", I'd say everything is better than C++, and on the other side, it seems that cargo is pretty good. I don't know how they tackle the "left-pad" problem that plagues npm though. By that I mean supply-chain attacks.
        1y ago
- adastra22 1y ago
  Slow compared to what? I’m still scraping my head at this. My cargo builds are insanely fast, never taking more than a minute or two even on large projects. The only ahead of time compiled language I’ve used with faster compilation speed is Go, and that is a language specifically designed around (and arguably crippled by) the requirement for fast compilation. Rust is comparable to C compilation, and definitely faster than C++, Haskell, Java, Fortran, Algol, and Common Lisp.
  - deleted 1y ago
    [deleted]
  - johnisgood 1y ago
    Just a few days ago I used cargo to install something. It took like two minutes at the last stage. Definitely not comparable to C or Fortran. I never had to wait that much before. With C++? Definitely. Never with C though.
  - eikenberry 1y ago
    In addition to Go, off the top of my head, you have D, V-lang, Zig, Lua and every interpreted language (including Haskell and Common Lisp, as they both have interpreters). Traditional compiled languages always had terrible UX in this regard which, IMO, is why interpreted languages like Python and Ruby got so popular.
zozbot234 1y ago
> Stockholm syndrome A.k.a. "Remember the Vasa!" https://news.ycombinator.com/item?id=17172057 https://news.ycombinator.com/item?id=17172057
galangalalgol 1y ago
Also modern c++ with value semantics is more functional than many other languages people might come to rust from, that keeps the borrow checker from being as annoying. If people are used to making webs of stateful classes with references to each pther. The borrow checker is horrific, but that is because that design pattern is horrific if you multithread it.

MobiusHorizons 1y ago

Things can still be slow in absolute terms without being as slow as C++. The issues with compiling C++ are incredibly well understood and documented. It is one of the worst languages on earth for compile times. Rust doesn’t share those language level issues, so the expectations are understandably higher.

int_19h 1y ago
But it does share some of those issues. Specifically, while Rust generics aren't as unstructured as C++ templates, the main burden is actually from compiling all those tiny instantiations, and Rust monomorphization has the same exact problem responsible for the bulk of its compile times.
const_cast 1y ago
Rust shares pretty much every language-level issue C++ has with compile times, no? Monomorphization explosion, turing-complete compile time macros, complex type system.
- steveklabnik 1y ago
  There's a lot of overlap, but not that simple. Unless you also discount C issues that C++ inherits. Even then, there's subtleties and differences between the two that matter.
pjmlp 1y ago
And easily solved with incremental compilers, incremental linkers, external templates and nowadays modules.

oreally 1y ago

Classic case of: New features: yes Talking to users and fixing actual problems: lolno, I CBF

pjmlp 1y ago

Not sure about you, but traditionally my C++ have always been faster than out of the box experience with Rust. Thanks to pre-compiled headers, incremental compiler, incremental linker, and using binary libraries for all dependencies. Nowadays modules as well. Rust compiles from scratch, some crates might get compiled multiple times due to conflicting configurations on the dependency graph, binary libraries require additional setup for something like scache.