5 ms·

> For the sake of security and reliability. I just read a few C++ vs Rust comparisons online yesterday and didn't see anything about a significant difference

> For the sake of security and reliability. I just read a few C++ vs Rust comparisons online yesterday and didn't see anything about a significant difference in security or reliability. Mind you the articles weren't very technical. How is Rust so much more secure and reliable than *modern* C++?

tester756 4y ago
I'd pick Rust over "modern" C++ just because I don't have to deal with 15 compilers, 15 IDEs, 15 build systems, decades of language experiments, kind of compiler-flags driven development
- 41b696ef1113 4y ago
  The true real win of Rust. Knowing that you are incredibly likely to be able to compile it without any hoops. Random C/C++ project can still be a roll of the dice.
  - tejohnso 4y ago
    > you are incredibly likely to be able to compile it without any hoops Nice. Does that hold true for cross compiling to arm (Rpi specifically) and Android?
    - deleted 4y ago
      [deleted]
- thoweiruo23423 4y ago
  also, know 50+ "best-use" subsets of C++.
- sseagull 4y ago
  Give rust a few decades and it will get there. Remember when python was simple? And you just had setuptools? Popularity breeds complexity and fragmentation.
  - stackbutterflow 4y ago
    Sure. In the meantime that's a few decades of better developer experience.
    - lenkite 4y ago
      More like a few decades of extreme churn. Hey dude are you using Crate #43? No, thats dead on github. Try Crate #999. No dude that uses a diff async runtime. Try Crate #888. No dude, that has protest-ware on it and the boss complained. Try Crate #888. No dude, that has incompatible dependencies. Try Crate #456. No dude, that lib causes "fearless concurrency" deadlocks with async. Try crate #999. No dude, that has a gazillion macros and compilation times approach the heat-death of the universe. Try Crate #666...and the story goes on.
      - icybauhaus 4y ago
        Surely C++ doesn't have this problem when using external libraries
      - sai_c 4y ago
        Have an upvote for making my day :-).
- robotnikman 4y ago
  I ran into those issues when trying to build some old modding software for a game that was written in C++ (Corsix Mod Studio if anyone is wondering). I was not able to figure out how to get it to build, maybe someday I'll fire up a VM running XP and whatever version of Visual Studio was popular in 2006 and try again.
- rodgerd 4y ago
  Don't worry, the GNU people are looking to fix that.
woodruffw 4y ago
The primary defining quality of Rust (in a security context) is spatial and temporal memory safety: if you're an ordinary user of Rust, you cannot write code that produces memory corruption. Modern C++ is really nice (I write mostly C++17 and later for work), and does a great job of obsoleting bug-prone patterns from earlier versions of the language. But it's still very easy to introduce memory corruption (of either sort), especially for less experienced C++ engineers. Some kinds of corruption (like double frees) have become even more common as beginner mistakes, in my experience, thanks to the complex mental model required for move construction (compared to Rust, where moves are statically checked).
- throwaway2037 4y ago
  I would call myself an average C++ programmer. Starting with move semantics in C++11 (very cool!), I found myself frequently making bugs by re-using an "already moved" container (like a vector). I couldn't find any simple way to avoid that mistake. And, from my tooling, it was a hard problem to debug, as are double frees. Do you have any advice to avoid re-using "already moved" containers?
  - woodruffw 4y ago
    Nothing great, unfortunately -- C++'s decision to leave moved-from values in a "valid but unspecified" state makes a lot of sense from a memory corruption perspective, but has caused plenty of logic bugs in my codebases as well. The best thing I've used so far is clang-tidy (specifically the "use-after-moved"[1] check). It catches some stuff though, which is better than nothing. [1]: https://clang.llvm.org/extra/clang-tidy/checks/bugprone/use-after-move.html https://clang.llvm.org/extra/clang-tidy/checks/bugprone/use-...
    - throwaway2037 4y ago
      Good point about clang-tidy. JetBrain's C++ IDE called CLion directly integrates clang-tidy. It is scary how good are some of the suggestions. Absolutely, it makes me a better C++ programmer! It feels like an oldster is tapping me on the shoulder while pair programming: "That one, over there, fix it."
imron 4y ago
> How is Rust so much more secure and reliable than *modern* C++? Rust catches things like use-after-free at compile time. *modern* C++ still lets things slip through e.g. #include <iostream> #include <string> #include <string_view> int main() { std::string s = "Hellooooooooooooooo "; std::string_view sv = s + "World\n"; std::cout << sv; // oops, use after free return 0; }
- DannyBee 4y ago
  If by "slip through", you mean "warns you about by default", then yes it lets it slip through. clang++ -std=c++17 test.cc a.cc:7:29: warning: object backing the pointer will be destroyed at the end of the full-expression [-Wdangling-gsl] std::string_view sv = s + "World\n"; ^~~~~~~~~~~~~ In any case, I think the philosophical differences between C++ and Rust are well understood, and the different views of the cost/benefits there are also well understood. In practice, rust will take over when it convinces enough C++ developers that the tradeoff is worthwhile. That rarely happens by CTO's, or anyone else, telling everyone they are doing it wrong, but instead by helping people see easier ways of doing things, and ways to get work done faster/etc. Or, you know, waiting for everyone who does it the old way to die.
  - encryptluks2 4y ago
    - imron 4y ago
      For trivial examples like this, it's easy to spot. For modifications on a large codebase months (or years) after the original code happened, it saves significant time and effort to have the compiler catch bugs like this at compile time.
  - imron 4y ago
    > If by "slip through", you mean "warns you about by default", then yes it lets it slip through. My bad. I should have been more modern. Try this one: #include <iostream> #include <string> #include <string_view> int main() { std::string s = "Hellooooooooooooooo "; std::string_view sv {s + "World\n"}; // {now even more modern and warning free} std::cout << sv; // oops, use after free return 0; }
dodobirdlord 4y ago
Memory unsafety makes securing large codebases difficult because even minor errors in unimportant parts of a codebase have the potential to compromise an entire binary if an attacker can figure out how to get execution to reach the unsafe code and exploit it. Human code review is fallible and junior engineers exist, so if you want to be confidant that your codebase is free of such vulnerabilities you need to depend on static analysis. Rust makes this a lot easier because a lot of the guarantees you'd want to make using static analysis on your C/C++ codebase are built into the language, and the language helpfully flags for you the sections of code that need careful human scrutiny.
pornel 4y ago
The type system can express thread-safety. If you try to touch a data structure from a wrong thread, it will stop you at compile time. You don't need to fuzz such problems under a sanitizer. You have a compile-time guarantee for your entire codebase and even your dependencies. If you try to use a thread-unsafe library from a parallelized code, it won't compile, and it will show you exactly which field of which struct needs to be wrapped in atomic or mutex to work (at this point people say "but what about deadlocks!?". They are very easy to track down compared to heisenbug memory corruption.) This makes parallelization of code relatively easy and way more reliable. Rust markets this as "Fearless concurrency".
ModernMech 4y ago
Using modern C++ is like walking a tightrope. If you stay within the constraints, you'll do mostly fine. But it's a fine balancing act and there's a steep cliff to fall off if you don't pay enough attention. Look at it from the perspective of someone brand new to C++. How do they know what is "modern" and the right way to do things, versus "legacy" and the wrong way to do things? As a beginner, there are thousands of resources available to you on the internet -- some new, some decades old -- with code of varying quality that may or may not be "modern". All of it is valid C++ and will compile, but some of it may have footguns that are nonobvious to the new programmer. There's no "modern only" compiler that will reject said footguns, because C++ takes the position that leaving the footguns there is a feature. This isn't the case with Rust. Maybe it will become more like C++ in the future as the language changes, only time can tell. But for now, code that compiles in Rust is guaranteed to be free from various classes of bugs that still are possible to compile in C++, despite "modern" C++ having fixed various issues. Another way of saying this is that "just use modern C++" is a variation of "you're holding it wrong" or "just don't write buggy code", which has proven not to be scalable advice that leads to safer software.

tester756 4y ago

I'd pick Rust over "modern" C++ just because I don't have to deal with 15 compilers, 15 IDEs, 15 build systems, decades of language experiments, kind of compiler-flags driven development

41b696ef1113 4y ago
The true real win of Rust. Knowing that you are incredibly likely to be able to compile it without any hoops. Random C/C++ project can still be a roll of the dice.
- tejohnso 4y ago
  > you are incredibly likely to be able to compile it without any hoops Nice. Does that hold true for cross compiling to arm (Rpi specifically) and Android?
  - deleted 4y ago
    [deleted]
thoweiruo23423 4y ago
also, know 50+ "best-use" subsets of C++.
sseagull 4y ago
Give rust a few decades and it will get there. Remember when python was simple? And you just had setuptools? Popularity breeds complexity and fragmentation.
- stackbutterflow 4y ago
  Sure. In the meantime that's a few decades of better developer experience.
  - lenkite 4y ago
    More like a few decades of extreme churn. Hey dude are you using Crate #43? No, thats dead on github. Try Crate #999. No dude that uses a diff async runtime. Try Crate #888. No dude, that has protest-ware on it and the boss complained. Try Crate #888. No dude, that has incompatible dependencies. Try Crate #456. No dude, that lib causes "fearless concurrency" deadlocks with async. Try crate #999. No dude, that has a gazillion macros and compilation times approach the heat-death of the universe. Try Crate #666...and the story goes on.
    - icybauhaus 4y ago
      Surely C++ doesn't have this problem when using external libraries
    - sai_c 4y ago
      Have an upvote for making my day :-).
robotnikman 4y ago
I ran into those issues when trying to build some old modding software for a game that was written in C++ (Corsix Mod Studio if anyone is wondering). I was not able to figure out how to get it to build, maybe someday I'll fire up a VM running XP and whatever version of Visual Studio was popular in 2006 and try again.
rodgerd 4y ago
Don't worry, the GNU people are looking to fix that.

woodruffw 4y ago

The primary defining quality of Rust (in a security context) is spatial and temporal memory safety: if you're an ordinary user of Rust, you cannot write code that produces memory corruption. Modern C++ is really nice (I write mostly C++17 and later for work), and does a great job of obsoleting bug-prone patterns from earlier versions of the language. But it's still very easy to introduce memory corruption (of either sort), especially for less experienced C++ engineers. Some kinds of corruption (like double frees) have become even more common as beginner mistakes, in my experience, thanks to the complex mental model required for move construction (compared to Rust, where moves are statically checked).

throwaway2037 4y ago
I would call myself an average C++ programmer. Starting with move semantics in C++11 (very cool!), I found myself frequently making bugs by re-using an "already moved" container (like a vector). I couldn't find any simple way to avoid that mistake. And, from my tooling, it was a hard problem to debug, as are double frees. Do you have any advice to avoid re-using "already moved" containers?
- woodruffw 4y ago
  Nothing great, unfortunately -- C++'s decision to leave moved-from values in a "valid but unspecified" state makes a lot of sense from a memory corruption perspective, but has caused plenty of logic bugs in my codebases as well. The best thing I've used so far is clang-tidy (specifically the "use-after-moved"[1] check). It catches some stuff though, which is better than nothing. [1]: https://clang.llvm.org/extra/clang-tidy/checks/bugprone/use-after-move.html https://clang.llvm.org/extra/clang-tidy/checks/bugprone/use-...
  - throwaway2037 4y ago
    Good point about clang-tidy. JetBrain's C++ IDE called CLion directly integrates clang-tidy. It is scary how good are some of the suggestions. Absolutely, it makes me a better C++ programmer! It feels like an oldster is tapping me on the shoulder while pair programming: "That one, over there, fix it."

imron 4y ago

> How is Rust so much more secure and reliable than *modern* C++? Rust catches things like use-after-free at compile time. *modern* C++ still lets things slip through e.g. #include <iostream> #include <string> #include <string_view> int main() { std::string s = "Hellooooooooooooooo "; std::string_view sv = s + "World\n"; std::cout << sv; // oops, use after free return 0; }

DannyBee 4y ago
If by "slip through", you mean "warns you about by default", then yes it lets it slip through. clang++ -std=c++17 test.cc a.cc:7:29: warning: object backing the pointer will be destroyed at the end of the full-expression [-Wdangling-gsl] std::string_view sv = s + "World\n"; ^~~~~~~~~~~~~ In any case, I think the philosophical differences between C++ and Rust are well understood, and the different views of the cost/benefits there are also well understood. In practice, rust will take over when it convinces enough C++ developers that the tradeoff is worthwhile. That rarely happens by CTO's, or anyone else, telling everyone they are doing it wrong, but instead by helping people see easier ways of doing things, and ways to get work done faster/etc. Or, you know, waiting for everyone who does it the old way to die.
- encryptluks2 4y ago
  - imron 4y ago
    For trivial examples like this, it's easy to spot. For modifications on a large codebase months (or years) after the original code happened, it saves significant time and effort to have the compiler catch bugs like this at compile time.
- imron 4y ago
  > If by "slip through", you mean "warns you about by default", then yes it lets it slip through. My bad. I should have been more modern. Try this one: #include <iostream> #include <string> #include <string_view> int main() { std::string s = "Hellooooooooooooooo "; std::string_view sv {s + "World\n"}; // {now even more modern and warning free} std::cout << sv; // oops, use after free return 0; }

dodobirdlord 4y ago

Memory unsafety makes securing large codebases difficult because even minor errors in unimportant parts of a codebase have the potential to compromise an entire binary if an attacker can figure out how to get execution to reach the unsafe code and exploit it. Human code review is fallible and junior engineers exist, so if you want to be confidant that your codebase is free of such vulnerabilities you need to depend on static analysis. Rust makes this a lot easier because a lot of the guarantees you'd want to make using static analysis on your C/C++ codebase are built into the language, and the language helpfully flags for you the sections of code that need careful human scrutiny.

pornel 4y ago

The type system can express thread-safety. If you try to touch a data structure from a wrong thread, it will stop you at compile time. You don't need to fuzz such problems under a sanitizer. You have a compile-time guarantee for your entire codebase and even your dependencies. If you try to use a thread-unsafe library from a parallelized code, it won't compile, and it will show you exactly which field of which struct needs to be wrapped in atomic or mutex to work (at this point people say "but what about deadlocks!?". They are very easy to track down compared to heisenbug memory corruption.) This makes parallelization of code relatively easy and way more reliable. Rust markets this as "Fearless concurrency".

ModernMech 4y ago

Using modern C++ is like walking a tightrope. If you stay within the constraints, you'll do mostly fine. But it's a fine balancing act and there's a steep cliff to fall off if you don't pay enough attention. Look at it from the perspective of someone brand new to C++. How do they know what is "modern" and the right way to do things, versus "legacy" and the wrong way to do things? As a beginner, there are thousands of resources available to you on the internet -- some new, some decades old -- with code of varying quality that may or may not be "modern". All of it is valid C++ and will compile, but some of it may have footguns that are nonobvious to the new programmer. There's no "modern only" compiler that will reject said footguns, because C++ takes the position that leaving the footguns there is a feature. This isn't the case with Rust. Maybe it will become more like C++ in the future as the language changes, only time can tell. But for now, code that compiles in Rust is guaranteed to be free from various classes of bugs that still are possible to compile in C++, despite "modern" C++ having fixed various issues. Another way of saying this is that "just use modern C++" is a variation of "you're holding it wrong" or "just don't write buggy code", which has proven not to be scalable advice that leads to safer software.