6 ms·

How does modern C++ compare to Rust? As in, if someone is already familiar with C++, and is willing and able to use c++20, and maybe beyond, features, are there

How does modern C++ compare to Rust? As in, if someone is already familiar with C++, and is willing and able to use c++20, and maybe beyond, features, are there still some compelling reasons to switch to Rust?

Yoric 3y ago
Rust does have a few drawbacks (custom allocators, some people miss sfinae, I don't). However, the Rust standard library is, IMHO, vastly better designed that the C++ stdlib, in particular when it comes to concurrency. Also, the toolchain is quite good. And of course, linting is miles ahead of C++ and will presumably stay there forever, as Rust code is much easier to analyze than C++. So, I would say yes, it is worth. But truly, it probably depends on what you're coding.
- pavlov 3y ago
  IMO a major exception is that if you’re interfacing with complex C++ libraries, it’s probably better to stay in C++ land rather than try to make it work from Rust. (Fixing bugs involving FFI is truly the worst, and C++ is particularly hairy to wrap from other languages.) One strategy is to put a minimal application-specific C layer around your C++ library, and call that from the Rust app. I’ve done that in the past and it kept the Rusties on the team happy enough. But you need to be fairly certain that the API can remain small enough and high-level enough even as needs grow, because nobody wants to be maintaining a C wrapper of hundreds of API calls a few years down the road.
pjmlp 3y ago
Assuming that you also make use of static analysis as part of the language, mostly developer culture. In C++ circles, safety conscious developers are always fighting against C like code, or disabling bounds checking. If you are in a team that values bounds checking enabled by default, and where C style coding is forbidden unless for FFI reasons, then it is another matter. See Jason Turner's starter packs. https://youtu.be/ucl0cw9X3e8 https://youtu.be/ucl0cw9X3e8
- alchemist1e9 3y ago
  Not a video fan and you have another comment mentioning static analysis I replied to. I have hunch you have something important to say about C++ static analysis and I’m curious as it could be a worthy topic for people to discuss. Tell us more if you can, even high level.
  - pjmlp 3y ago
    Answered on the other thread. Basically it isn't perfect as solution, but by enabling them as if they part of the language, we get to clean up wrong defaults, and force best practices, specially if they are integrated as part of a CI/CD pipeline, including breaking the build when they aren't followed upon. It isn't a fullproof solution, but better than nothing, and plenty of domains aren't going to switch to anything else anyway. It is kind of ironic that even C's authors saw the need of such tooling and created lint in 1979, but apparently the FOSS hardly cared about such kind of tooling until clang came to be.
    - tialaramex 3y ago
      FWIW it's foolproof not "fullproof". The correct analysis is that this is proof against fools, in the same way that e.g. a rainproof electrical box is proof against rain, or a bulletproof armoured vehicle is proof against bullets. This is an example of an eggcorn, humans acquire language by exposure, you misunderstand a word or saying, you analyse its apparent meaning based on what you thought you understood, and then you apply that analysis, it's a completely normal part of human language use. In some cases, eggcorns become normalised enough that it's reasonable to say they're just a variant use, but in most cases they'd be regarded as errors, and so it's probably useful to know if you've picked up any eggcorns. https://en.wikipedia.org/wiki/Eggcorn https://en.wikipedia.org/wiki/Eggcorn
      - pjmlp 3y ago
        Fair enough, thanks for the correction.
nicoburns 3y ago
Maintaining memory safety, thread safety, and avoiding UB is still much easier in Rust than C++. In C++ you have be vigilant to avoid a mistake slipping in. In Rust, you get a compile error if you make a mistake.
- wanttocomment 3y ago
  All rust code is UB because there is no spec. I don't mean this as a knock against rust, but against UB fear.
  - nicoburns 3y ago
    That is not what UB means. Undefined Behaviour is behaviour that the compiler is allowed to assume will never happen, and which can consequently cause miscompilations due to optimisation passes gone wrong if it does in fact occur in the source code. It's true that Rust does not have a written specification that clearly delineates what is and isn't UB in a single place. But: 1. UB is impossible in safe code (modulo bugs in unsafe code) 2. There are resources such as the Rustinomicon (https://doc.rust-lang.org/nomicon/ https://doc.rust-lang.org/nomicon/) that provide a detailed guide on what is and isn't allowed in unsafe code. In practice, it's much easier to avoid UB in Rust than it is in C++.
    - mr_00ff00 3y ago
      I am familiar with UB as a result of memory unsafety, but the way it is talked about it sounds like the only ways to ever cause UB is with memory unsafety. Based on that definition it feels like it should be possible to have UB outside of memory violations, is there really no UB in languages like Java/Haskell/Go?
      - nicoburns 3y ago
        You can have it for reasons other than memory safety, for example signed integer overflow is UB in C and C++ (but not in Rust). However, higher level languages typically go to great lengths to avoid it. For example, in Java you will get a NullPointerException rather a null pointer actually being dereferenced, which immediately rules out any UB due to a pointer being dereferenced where doing so is not allowed.
mgaunard 3y ago
"modern c++" is an expression people have been using for 20 years. The reality is that C++ can be used very well and very badly. What makes C++ code good or not is not defined by the fact it's more or less C++, but rather by who wrote it.
- tialaramex 3y ago
  Much more than 20 years. Andrei Alexandrescu wrote "Modern C++ Design" at the turn of the century and it was published in February 2001.
  - mgaunard 3y ago
    how is that "much more" than 20 years?
kitkat_new 3y ago
> n, if someone is already familiar with C++, and is willing and able to use c++20, and maybe beyond, features, are there still some compelling reasons to switch to Rust? imho Rust is modern C++ done right (i.e. without all the baggage from the C++ past due to backwards compatibility) -> less mental overhead, still safer, more convenient features, less debugging, proper tooling...
- shrimp_emoji 3y ago
  I think Rust is "C done right". It feels more like C than C++. To do C++ right, you'd need to do "marriage of OOP and low level programming" right, which is probably impossible because it's the most cursed combination of ideas ever conceived. WAIT, I take it back -- D improves on C++, so it's "C++ done right". :D
  - kitkat_new 3y ago
    > To do C++ right, you'd need to do "marriage of OOP and low level programming" right, not really, C++ is a multiparadigm language, so is Rust
School-Cotton 3y ago
The main compelling reason is that rust is much simpler and easier to use and understand. The “rust is difficult” meme came from people who don’t primarily use c++.
- sidlls 3y ago
  I used to use primarily C++ (haven't for a few years, at least professionally). Non-trivial Rust is not much simpler and easier to use or understand. It has different kinds of complexity that can easily make it as inscrutable as non-trivial C++ code.
gemstones 3y ago
One feature of Rust that I don't see talked about as much is the ability for research to make its way into language improvements. Lots of PhD research in non-GC languages goes like, "assume C or C++ but written in a really specific way", where the research is interesting but there are too many corner cases to deal with when applied to a real project. Rust makes so many guarantees that I expect some of that Ph.D research will start to turn into concrete language improvements in ways it never could before. It'll be very exciting to watch the next 5-10 years of Rust as the best overlooked research ideas start to have a viable path to production projects.

Yoric 3y ago

Rust does have a few drawbacks (custom allocators, some people miss sfinae, I don't). However, the Rust standard library is, IMHO, vastly better designed that the C++ stdlib, in particular when it comes to concurrency. Also, the toolchain is quite good. And of course, linting is miles ahead of C++ and will presumably stay there forever, as Rust code is much easier to analyze than C++. So, I would say yes, it is worth. But truly, it probably depends on what you're coding.

pavlov 3y ago
IMO a major exception is that if you’re interfacing with complex C++ libraries, it’s probably better to stay in C++ land rather than try to make it work from Rust. (Fixing bugs involving FFI is truly the worst, and C++ is particularly hairy to wrap from other languages.) One strategy is to put a minimal application-specific C layer around your C++ library, and call that from the Rust app. I’ve done that in the past and it kept the Rusties on the team happy enough. But you need to be fairly certain that the API can remain small enough and high-level enough even as needs grow, because nobody wants to be maintaining a C wrapper of hundreds of API calls a few years down the road.

pjmlp 3y ago

Assuming that you also make use of static analysis as part of the language, mostly developer culture. In C++ circles, safety conscious developers are always fighting against C like code, or disabling bounds checking. If you are in a team that values bounds checking enabled by default, and where C style coding is forbidden unless for FFI reasons, then it is another matter. See Jason Turner's starter packs. https://youtu.be/ucl0cw9X3e8 https://youtu.be/ucl0cw9X3e8

alchemist1e9 3y ago
Not a video fan and you have another comment mentioning static analysis I replied to. I have hunch you have something important to say about C++ static analysis and I’m curious as it could be a worthy topic for people to discuss. Tell us more if you can, even high level.
- pjmlp 3y ago
  Answered on the other thread. Basically it isn't perfect as solution, but by enabling them as if they part of the language, we get to clean up wrong defaults, and force best practices, specially if they are integrated as part of a CI/CD pipeline, including breaking the build when they aren't followed upon. It isn't a fullproof solution, but better than nothing, and plenty of domains aren't going to switch to anything else anyway. It is kind of ironic that even C's authors saw the need of such tooling and created lint in 1979, but apparently the FOSS hardly cared about such kind of tooling until clang came to be.
  - tialaramex 3y ago
    FWIW it's foolproof not "fullproof". The correct analysis is that this is proof against fools, in the same way that e.g. a rainproof electrical box is proof against rain, or a bulletproof armoured vehicle is proof against bullets. This is an example of an eggcorn, humans acquire language by exposure, you misunderstand a word or saying, you analyse its apparent meaning based on what you thought you understood, and then you apply that analysis, it's a completely normal part of human language use. In some cases, eggcorns become normalised enough that it's reasonable to say they're just a variant use, but in most cases they'd be regarded as errors, and so it's probably useful to know if you've picked up any eggcorns. https://en.wikipedia.org/wiki/Eggcorn https://en.wikipedia.org/wiki/Eggcorn
    - pjmlp 3y ago
      Fair enough, thanks for the correction.

nicoburns 3y ago

Maintaining memory safety, thread safety, and avoiding UB is still much easier in Rust than C++. In C++ you have be vigilant to avoid a mistake slipping in. In Rust, you get a compile error if you make a mistake.

wanttocomment 3y ago
All rust code is UB because there is no spec. I don't mean this as a knock against rust, but against UB fear.
- nicoburns 3y ago
  That is not what UB means. Undefined Behaviour is behaviour that the compiler is allowed to assume will never happen, and which can consequently cause miscompilations due to optimisation passes gone wrong if it does in fact occur in the source code. It's true that Rust does not have a written specification that clearly delineates what is and isn't UB in a single place. But: 1. UB is impossible in safe code (modulo bugs in unsafe code) 2. There are resources such as the Rustinomicon (https://doc.rust-lang.org/nomicon/ https://doc.rust-lang.org/nomicon/) that provide a detailed guide on what is and isn't allowed in unsafe code. In practice, it's much easier to avoid UB in Rust than it is in C++.
  - mr_00ff00 3y ago
    I am familiar with UB as a result of memory unsafety, but the way it is talked about it sounds like the only ways to ever cause UB is with memory unsafety. Based on that definition it feels like it should be possible to have UB outside of memory violations, is there really no UB in languages like Java/Haskell/Go?
    - nicoburns 3y ago
      You can have it for reasons other than memory safety, for example signed integer overflow is UB in C and C++ (but not in Rust). However, higher level languages typically go to great lengths to avoid it. For example, in Java you will get a NullPointerException rather a null pointer actually being dereferenced, which immediately rules out any UB due to a pointer being dereferenced where doing so is not allowed.

mgaunard 3y ago

"modern c++" is an expression people have been using for 20 years. The reality is that C++ can be used very well and very badly. What makes C++ code good or not is not defined by the fact it's more or less C++, but rather by who wrote it.

tialaramex 3y ago
Much more than 20 years. Andrei Alexandrescu wrote "Modern C++ Design" at the turn of the century and it was published in February 2001.
- mgaunard 3y ago
  how is that "much more" than 20 years?

kitkat_new 3y ago

> n, if someone is already familiar with C++, and is willing and able to use c++20, and maybe beyond, features, are there still some compelling reasons to switch to Rust? imho Rust is modern C++ done right (i.e. without all the baggage from the C++ past due to backwards compatibility) -> less mental overhead, still safer, more convenient features, less debugging, proper tooling...

shrimp_emoji 3y ago
I think Rust is "C done right". It feels more like C than C++. To do C++ right, you'd need to do "marriage of OOP and low level programming" right, which is probably impossible because it's the most cursed combination of ideas ever conceived. WAIT, I take it back -- D improves on C++, so it's "C++ done right". :D
- kitkat_new 3y ago
  > To do C++ right, you'd need to do "marriage of OOP and low level programming" right, not really, C++ is a multiparadigm language, so is Rust

School-Cotton 3y ago

The main compelling reason is that rust is much simpler and easier to use and understand. The “rust is difficult” meme came from people who don’t primarily use c++.

sidlls 3y ago
I used to use primarily C++ (haven't for a few years, at least professionally). Non-trivial Rust is not much simpler and easier to use or understand. It has different kinds of complexity that can easily make it as inscrutable as non-trivial C++ code.

gemstones 3y ago

One feature of Rust that I don't see talked about as much is the ability for research to make its way into language improvements. Lots of PhD research in non-GC languages goes like, "assume C or C++ but written in a really specific way", where the research is interesting but there are too many corner cases to deal with when applied to a real project. Rust makes so many guarantees that I expect some of that Ph.D research will start to turn into concrete language improvements in ways it never could before. It'll be very exciting to watch the next 5-10 years of Rust as the best overlooked research ideas start to have a viable path to production projects.