4 ms·

It’s not complex problems. It’s being close to the metal. Rust isn’t bad but it’s still not as good as C or C++ if you need to get every last bit of performance

by api 6y ago

It’s not complex problems. It’s being close to the metal. Rust isn’t bad but it’s still not as good as C or C++ if you need to get every last bit of performance or need to be really close to the OS and hardware. Rust is coming along though. It’s the first language I have seen that might unseat C++.

otabdeveloper4 6y ago
> It’s the first language I have seen that might unseat C++. Doubtful, as C++ has language standards and a visible, comprehensible story on how they evolve. C++ has also been evolving faster than Rust. Right now Rust fills the "C++ with training wheels" niche - when you need a language in this space but don't have the energy or time to disentangle the sordid story of all the crufty legacy systems built around C++ after all this time. But in principle if somebody made a well thought-out onboarding story for C++ then there's be little point in Rust. P.S. But you say "my borrow checker" - well, sorry to disappoint you, people don't really care and actually view it as an impediment in learning Rust, not as a feature. If Rust had no borrow checker it'd be an even more popular language.
- Cyph0n 6y ago
  The borrow checker is one of Rust’s selling main selling points, and was what got me into the language. If you don’t see the value of compile-time memory safety in Rust, you probably haven’t spent hours debugging subtle runtime memory safety errors in a large C application.
  - otabdeveloper4 6y ago
    Read my post again, please. The people who choose Rust over C++ aren't (generally speaking, there are of course exceptions) doing because of the borrow checker. They're doing because Rust has Cargo and C++ doesn't.
    - steveklabnik 6y ago
      I think it is extremely hard to generalize here.
  - ncmncm 6y ago
    This, anyway, is correct: In 30 years of coding maximal-performance C and C++ systems, I have not spent hours debugging subtle runtime memory safety errors. I have spent strictly more time tracking down compiler bugs. I can count on one hand the memory errors I have debugged in five years. The longest took a half-hour. (Code that used a "relaxed" atomic load was moved to a place where it needed "acquire" -- which is the default.) So, I eagerly prefer (rounding up) 2.5 hours of debugging spent in five years over spending 5 extra hours every week -- 1750 hours in 5 years -- waiting on builds from a very slow compiler. (I don't know any reason why the Rust compiler could not be two orders of magnitude faster, and notably faster than a C++ compiler.) My experience may be unusual in that I do not habitually depend on code badly-written by other people. My complaints about other people's code I do use are more typically about performance, conformability to requirements, or poor usability.
    - Cyph0n 6y ago
      I haven't been writing C for anywhere as long as you have, but I have definitely spent quite a bit of time printf() debugging and digging through corefiles in GDB. I also have never had to deal with compiler bugs, but that could be because IOS-XR uses a stable/old compiler toolchain. I could be wrong, but I would wager that you are definitely an outlier among C and C++ developers. For the remaining majority, I believe that the compile-time memory safety guarantees that Rust provides are huge. As to why your experience is different, it could be that you're simply (1) a talented programmer, (2) work with talented programmers, or (3) don't work on a large and complex legacy codebase, or some combination of the above.
MrBuddyCasino 6y ago
> Rust isn’t bad but it’s still not as good as C or C++ Can you elaborate in what way? I was under the impression the amount of low-level control was equal.
- steveklabnik 6y ago
  I work at a company where we're doing software at all levels of the stack, from the firmware up. It is all in Rust. Even our firmware. It's working really well for us.
elb2020 6y ago
I think it's fair to call it a complex problem, if referring to the task itself, of creating performant software (which I assume is what he did). I agree with otabdeveloper in general. I'm learning C++, and over the past year there has been many occasions where I've found myself dumbfounded by patterns in the language. But, in 99% of the cases, the outcome is that the patterns are there for a reason. And the reason is performance.
- Cyph0n 6y ago
  But Rust is a direct counterexample: it gives you comparable performance[1] to C++ while helping you avoid the common memory safety pitfalls of C++. [1]: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rust-gpp.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... (these benchmarks are not representative of all workloads, but it gives you a general idea)
socialdemocrat 6y ago
Funny how people obsess about getting "every last bit of performance" and yet we are building applications in layers upon layers inside bloated Web browsers... I think that is a bigger problem than using a language that gives you 10% less performance than C++. And anyway algorithms are typically are more important than the language in terms of performance.

by api 6y ago

otabdeveloper4 6y ago

> It’s the first language I have seen that might unseat C++. Doubtful, as C++ has language standards and a visible, comprehensible story on how they evolve. C++ has also been evolving faster than Rust. Right now Rust fills the "C++ with training wheels" niche - when you need a language in this space but don't have the energy or time to disentangle the sordid story of all the crufty legacy systems built around C++ after all this time. But in principle if somebody made a well thought-out onboarding story for C++ then there's be little point in Rust. P.S. But you say "my borrow checker" - well, sorry to disappoint you, people don't really care and actually view it as an impediment in learning Rust, not as a feature. If Rust had no borrow checker it'd be an even more popular language.

Cyph0n 6y ago
The borrow checker is one of Rust’s selling main selling points, and was what got me into the language. If you don’t see the value of compile-time memory safety in Rust, you probably haven’t spent hours debugging subtle runtime memory safety errors in a large C application.
- otabdeveloper4 6y ago
  Read my post again, please. The people who choose Rust over C++ aren't (generally speaking, there are of course exceptions) doing because of the borrow checker. They're doing because Rust has Cargo and C++ doesn't.
  - steveklabnik 6y ago
    I think it is extremely hard to generalize here.
- ncmncm 6y ago
  This, anyway, is correct: In 30 years of coding maximal-performance C and C++ systems, I have not spent hours debugging subtle runtime memory safety errors. I have spent strictly more time tracking down compiler bugs. I can count on one hand the memory errors I have debugged in five years. The longest took a half-hour. (Code that used a "relaxed" atomic load was moved to a place where it needed "acquire" -- which is the default.) So, I eagerly prefer (rounding up) 2.5 hours of debugging spent in five years over spending 5 extra hours every week -- 1750 hours in 5 years -- waiting on builds from a very slow compiler. (I don't know any reason why the Rust compiler could not be two orders of magnitude faster, and notably faster than a C++ compiler.) My experience may be unusual in that I do not habitually depend on code badly-written by other people. My complaints about other people's code I do use are more typically about performance, conformability to requirements, or poor usability.
  - Cyph0n 6y ago
    I haven't been writing C for anywhere as long as you have, but I have definitely spent quite a bit of time printf() debugging and digging through corefiles in GDB. I also have never had to deal with compiler bugs, but that could be because IOS-XR uses a stable/old compiler toolchain. I could be wrong, but I would wager that you are definitely an outlier among C and C++ developers. For the remaining majority, I believe that the compile-time memory safety guarantees that Rust provides are huge. As to why your experience is different, it could be that you're simply (1) a talented programmer, (2) work with talented programmers, or (3) don't work on a large and complex legacy codebase, or some combination of the above.

MrBuddyCasino 6y ago

> Rust isn’t bad but it’s still not as good as C or C++ Can you elaborate in what way? I was under the impression the amount of low-level control was equal.

steveklabnik 6y ago
I work at a company where we're doing software at all levels of the stack, from the firmware up. It is all in Rust. Even our firmware. It's working really well for us.

elb2020 6y ago

I think it's fair to call it a complex problem, if referring to the task itself, of creating performant software (which I assume is what he did). I agree with otabdeveloper in general. I'm learning C++, and over the past year there has been many occasions where I've found myself dumbfounded by patterns in the language. But, in 99% of the cases, the outcome is that the patterns are there for a reason. And the reason is performance.

Cyph0n 6y ago
But Rust is a direct counterexample: it gives you comparable performance[1] to C++ while helping you avoid the common memory safety pitfalls of C++. [1]: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rust-gpp.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... (these benchmarks are not representative of all workloads, but it gives you a general idea)

socialdemocrat 6y ago

Funny how people obsess about getting "every last bit of performance" and yet we are building applications in layers upon layers inside bloated Web browsers... I think that is a bigger problem than using a language that gives you 10% less performance than C++. And anyway algorithms are typically are more important than the language in terms of performance.