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++?
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).
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-...
Move constructor. Constructs the container with the contents of other using move semantics. Allocator is obtained by move-construction from the allocator belonging to other. After the move, other is guaranteed to be empty().
Which can be a useful property at times, but also means tooling won't help you here since it's not an obvious bug.
This doesn't change the surrounding point however, which is Rust's philosophy of safeness by construction: if a particular piece of code is safe, then no safe (i.e., invariant-preserving) use of it can be unsafe. That alone makes Rust's security properties strictly better than those of C++, where even the modern safer paradigms can violate underlying invariants.
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;
} 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 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.
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;
}This is why I say it takes extra work to get things wrong. Every example purporting to show "unavoidable" memory faults is super contrived. You have to turn off compiler warnings to be able to miss it.
It might seem contrived, and it is, but it's the essence of a bug that has happened in the real world, distilled to a 10 line example.
And yeah, "use things properly or they will blow up", but enough people don't do that (or mostly do but occasionally slip up) that it becomes a problem.
Of those use-after-free bugs that exist, they are a large source/percentage of the exploitable security bugs in C++ apps for sure. But again, it's not like apps are usually just littered with use-after-free. Like you may find one in a several million line of code app. They are not that common of a mistake, and FWIW, 100% of them are catchable with things like MSAN.
So people make mistakes. C++ makes certain kinds of those mistakes easy. Rust makes them hard or impossible. I don't think you will find any disagreement about this.
Again - this sort of thing is not going to convince anyone to use rust that doesn't want to already, for lots of reasons, not the least of because they think they are unlikely to make mistakes that matter :)
All this sort of thing does it turn people off from considering it for real, when they should!
(and i say all of this as someone who is funding efforts to replace billions of lines of C++ - i have no love for C++ over rust or vice versa. I just think the current approach here seems very unlikely to result in increased adoption)
For sure! It's those one-every-million-lines-of-code ones that are the problem, and that slip through code review and rear their head only in production at odd hours of the day.
> this sort of thing is not going to convince anyone to use rust that doesn't want to already
My post was in reply to someone asking the question what does Rust give you over modern C++, and this was an example showing that modern C++ still has its holes.
I'm not a Rust absolutist, nor do I think everything should be written (or rewritten) in Rust, but the biggest thing going in its favour is that offloads the cognitive load of checking lifetimes and ownership to the compiler, and that turns whole classes of runtime bugs in to compile time bugs.
clang++ test.cc -std=c++17 -Werror=dangling-gsl.
test.cc:7:29: error: object backing the pointer will be
destroyed at the end of the full-expression [-Werror,-
Wdangling-gsl]
std::string_view sv = s + "World\n";
^~~~~~~~~~~~~
I do think Rust has lots to offer, but i think the eternal argument here about what the compiler lets you do vs not is not likely to be a winning one with the C++ developers you see who don't want to move over.
If you want to write safe c++ you have to understand memory and lifetimes and what the code is doing. Humans have been shown to be quite bad at doing this - even experienced programmers.
Rust offloads that work to the compiler.
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".
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.
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
Nice.
Does that hold true for cross compiling to arm (Rpi specifically) and Android?
Remember when python was simple? And you just had setuptools? Popularity breeds complexity and fragmentation.
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.