4 ms·

It's futile battle though to achieve both performance and safety in C++: as an example, safety requires avoiding moves, using reference counting, while achievin

It's futile battle though to achieve both performance and safety in C++: as an example, safety requires avoiding moves, using reference counting, while achieving performance means avoiding copies and passing occasional references around, among other things. That's why advertising C++ solution as fast does not work well with "but C++ can be safe too!".

bcjpjk 9y ago
Moves can be safe, and copies can be dangerous. C++ is a language that can be used like a sawed-off shotgun propped against a developer's foot, and with a hair trigger. Granted, it does not _have_ to be used this way, but it can be. A good developer can be "safe by default" and can use profile-directed optimization to speed up areas that are performance critical. A great developer can build proofs that such performance improvements maintain safety guarantees. For the average developer, following modern C++ development practices creates code on par with other languages in terms of both safety and performance. For most languages, a lot can be done in terms of optimization, profiling, and security. Even in higher-level languages, an FFI is available to rewrite critical portions of code in a lower level language for performance improvements. Careful attention to detail can provide critical performance improvements in any language without compromising on safety. Getting there requires model checking or formal methods, but that is also becoming more of a part of modern development practices.
- pjmlp 9y ago
  The problem is that many developers don't care, they just want to do something that works and move on. This is not specific to C++, but it is worse in C and C++ given the nature of these languages. It also doesn't help that management even cares less about QA than those devs.
fauigerzigerk 9y ago
Not sure I necessarily agree with all your examples, but yes, this trade-off between safety and performance does exist in C++. It is particularily acute whenever you're forced to work with third party libraries that don't agree on a single approach to memory management. Rust is essentially a bet on the impossibility of working around that trade-off in C++. And they are right, it is impossible to close that gap completely. C++ simply doesn't have the language features to enforce all necessary ownership rules without a performance penalty. But I see trouble on the horizon for Rust, because that gap is quickly shrinking to its formally irreducible minimum as more C++ libraries are adopting a "modern" style. What's left of that gap may be too small to fit an entire new programming language built around fixing this single issue.
- steveklabnik 9y ago
  Rust is more than just safety though. We had a huge community discussion last year: https://brson.github.io/fireflowers/ https://brson.github.io/fireflowers/
  - fauigerzigerk 9y ago
    I know it's more than that. But what you can't do, in my opinion, is love Rust for its other modern features and merely tolerate the new approach to memory management. Memory management in Rust is so dominant in terms of syntax and in terms of restrictions imposed on common idioms that it must be either embraced or rejected wholeheartedly. This is just my personal opinion obviously, not any sort of truth or prediction.
    - steveklabnik 9y ago
      Yeah, I totally hear you. I shared that opinion too, but, surprisingly enough, it seems to some degree that that's in the minority. Or at least, there's a pretty significant number of people who do "love Ruts for its other modern features and merely tolerate the new approach to memory management." I feel that way myself now, but figured that I was just too close to have a mainstream opinion about it :)
      - fauigerzigerk 9y ago
        That's good to know. Perhaps I just need more practice then.
    - duneroadrunner 9y ago
      Two main components of Rust's approach to memory management are i) the imposing/exploiting of scope lifetimes on objects and references, and ii) the restriction that a mutable reference may not co-exist with any other references (to the same object). I suggest that with C++ there is kind of the option of embracing the former, without so much of the latter, to achieve a performance-safety combination that is closer to Rust's than current "modern C++" practices. That's sort of the premise of the SaferCPlusPlus library [1]. If you're a C++ programmer, the barrier to adoption is low. Though without a "borrow checker" or something equivalent, you wouldn't be able to match Rust's performance-safety combination in all cases. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus https://github.com/duneroadrunner/SaferCPlusPlus edit: edited the link

bcjpjk 9y ago

Moves can be safe, and copies can be dangerous. C++ is a language that can be used like a sawed-off shotgun propped against a developer's foot, and with a hair trigger. Granted, it does not _have_ to be used this way, but it can be. A good developer can be "safe by default" and can use profile-directed optimization to speed up areas that are performance critical. A great developer can build proofs that such performance improvements maintain safety guarantees. For the average developer, following modern C++ development practices creates code on par with other languages in terms of both safety and performance. For most languages, a lot can be done in terms of optimization, profiling, and security. Even in higher-level languages, an FFI is available to rewrite critical portions of code in a lower level language for performance improvements. Careful attention to detail can provide critical performance improvements in any language without compromising on safety. Getting there requires model checking or formal methods, but that is also becoming more of a part of modern development practices.

pjmlp 9y ago
The problem is that many developers don't care, they just want to do something that works and move on. This is not specific to C++, but it is worse in C and C++ given the nature of these languages. It also doesn't help that management even cares less about QA than those devs.

fauigerzigerk 9y ago

Not sure I necessarily agree with all your examples, but yes, this trade-off between safety and performance does exist in C++. It is particularily acute whenever you're forced to work with third party libraries that don't agree on a single approach to memory management. Rust is essentially a bet on the impossibility of working around that trade-off in C++. And they are right, it is impossible to close that gap completely. C++ simply doesn't have the language features to enforce all necessary ownership rules without a performance penalty. But I see trouble on the horizon for Rust, because that gap is quickly shrinking to its formally irreducible minimum as more C++ libraries are adopting a "modern" style. What's left of that gap may be too small to fit an entire new programming language built around fixing this single issue.

steveklabnik 9y ago
Rust is more than just safety though. We had a huge community discussion last year: https://brson.github.io/fireflowers/ https://brson.github.io/fireflowers/
- fauigerzigerk 9y ago
  I know it's more than that. But what you can't do, in my opinion, is love Rust for its other modern features and merely tolerate the new approach to memory management. Memory management in Rust is so dominant in terms of syntax and in terms of restrictions imposed on common idioms that it must be either embraced or rejected wholeheartedly. This is just my personal opinion obviously, not any sort of truth or prediction.
  - steveklabnik 9y ago
    Yeah, I totally hear you. I shared that opinion too, but, surprisingly enough, it seems to some degree that that's in the minority. Or at least, there's a pretty significant number of people who do "love Ruts for its other modern features and merely tolerate the new approach to memory management." I feel that way myself now, but figured that I was just too close to have a mainstream opinion about it :)
    - fauigerzigerk 9y ago
      That's good to know. Perhaps I just need more practice then.
  - duneroadrunner 9y ago
    Two main components of Rust's approach to memory management are i) the imposing/exploiting of scope lifetimes on objects and references, and ii) the restriction that a mutable reference may not co-exist with any other references (to the same object). I suggest that with C++ there is kind of the option of embracing the former, without so much of the latter, to achieve a performance-safety combination that is closer to Rust's than current "modern C++" practices. That's sort of the premise of the SaferCPlusPlus library [1]. If you're a C++ programmer, the barrier to adoption is low. Though without a "borrow checker" or something equivalent, you wouldn't be able to match Rust's performance-safety combination in all cases. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus https://github.com/duneroadrunner/SaferCPlusPlus edit: edited the link