it’s important to note that memory safety is only one kind of bug. Plenty of go and java programs are memory safe with a litany of bugs - and are probably directly protecting an order or two magnitude more of your personal data than Rust and C++ - even without discussing relatively safe languages (interpreted but with various implementations) like Python, PHP, and Ruby.
The thing is Rust also does great on the "other bugs" side.
The standard library and ecosystem follow the philosophy of making it easy to do the right thing, and preferably impossible to do the wrong thing; made possible by a very expressive type system. Of course logic bugs are possible in any language, and I wouldn't suggest rewriting a battle-tested Java application in Rust. But if you are already committed to rewriting (or starting a greenfield project) then Rust is a good choice for more reasons than just memory safety.
In my experience a memory error is often the result of a logic bug - that is the "first failure" of an existing issue in C++ is a memory error, but the originating logic error still exists and would just cause a different issue under "memory safe" languages. It would still be a bug, and may cause security issues.
IMHO the big advantage here is not languages that are memory safe, so much as catch many of those misunderstandings at compile time, or runtime in a better way than "Crash" or worse - silent corruption (Much of this is available for c++ in static analysis and sanitizers and other runtime checks, but them being non-default options seems to make them oddly ignored). I feel them being non-default also means there isn't the same focus on performance - and it's an everything-debug-and-slow-as-hell with a UX purely designed around the dev debugging their own code, or no-checking-at-all-no-brakes rather than in between.
The classic "memory errors" that are purely local and just not checking the bounds of an array or similar have been pretty much eliminated if you actually use the features (containers, iterators etc.) of the c++ standard library.
The problem with memory unsafe languages isn't that they can crash. It's that they won't crash. And instead allow an attacker to load up malicious code into the application.
> better way than "Crash" or worse - silent corruption
My point is that the current crop of c++ compilers and standard library implementations have the ability to check for the vast majority of these issues, just they're relegated to non-default "debug" options.
Just flipping that, so you had some level of checking on by default and you had to explicitly ask for "Go fast and break things" mode would help - as it feels like the vast majority of native code doesn't need to get that last few percent. And even that is questionable, I remember doing some (micro-)benchmarks on simple stuff like array bounds checking and the performance difference on modern big CPUs was pretty much within noise. Maybe it's a big deal on microcontrollers or small embedded systems, but that's the "I Know What I'm Doing" non-default mode is for.
> better way than "Crash" or worse - silent corruption
My apologies, I could have sworn that your text was 'better way than "Crash" <end>'. And not in fact, 'better way than "Crash" or worse - silent corruption'.
Although, silent corruption is a possible problem in memory safe languages. True, memory safety gives you some sort of protections, but threads and/or setting the wrong value can still give a memory safe corruption.
No, I was talking about the ability for an attacker to craft malicious input such that a memory unsafe program begins executing that input as if it were the program. Something that you generally do not have to worry about in a memory safe language.
I think I edited it within seconds of posting, it was just "Or worse" IIRC, and noticed I'd missed it when rewording it just before posting. I guess you were lucky enough to see it immediately :P It's a bad habit of mine to post then re-read with fresher eyes and notice problems in my comments - exactly like this clarification.
Security of technology is really a process, not a boolean. "Memory Safe" doesn't mean "Safe", and "Not the current crop of Memory Safe" languages doesn't mean "Unsafe". There's so much we can do with the tools we have right now to help with current codebases and apps, too many people seem to have the idea you have to do a ground up rewrite using the latest and greatest language, or you're an idiot and/or lazy.
Honestly, the whole world isn't going to be rewritten in rust tomorrow, imagine the time and effort that would take and all the other errors a ground-up rewrite of well-tested systems would cause. But we can probably rebuild 90% of the existing world in a "Safer" manner right now. We should be promoting that too, and not let perfection be the enemy of better.
> But we can probably rebuild 90% of the existing world in a "Safer" manner right no
I strongly agree with this mindset. The only caveat I would offer is that some architectural structures that c and c++ allow probably don't amend themselves to fixing even if you can detect them.
Although just like you can write any language horribly, I think you can write almost any language well.
It's hard to see how tools that allow you to do that can be a bad thing. I'm certainly not going to be paying to rewrite everything from the ground up in rust or otherwise.
>> it’s important to note that memory safety is only one kind of bug.
Is it? Large companies with huge code bases (meaning lots of statistical significance) have said 70 percent of their CVEs could not have happened if that code was written in Rust. Not only are those kinds of errors very common, they can be IMHO a pain to debug.
So given the prevalence of memory safety issues, why do you find it important to remind people that other kinds of bugs exist?
There's a theory that C programs are better designed from an implementation perspective and from a feature perspective precisely because it's so difficult to work with. The cost of implementing architectural complexity is so high that people put in extra thought and effort to discover the simplest design that can possibly work, which means better-understood and more reliable systems.
Same thing with features. Fewer, better-vetted features mean more secure systems.
C encourages better, simpler designs, but at the cost of making it nearly impossible to write safe code. Garbage-collected languages remove entire classes of errors, but they make it easier to implement lazy, unnecessarily complex designs.
Maybe Rust offers the best of both worlds? (I say this mostly but not entirely tongue in cheek.)
> Maybe Rust offers the best of both worlds? (I say this mostly but not entirely tongue in cheek.)
AFAIK Rust's solution for tree/graph is to replace pointers by indexes. IMHO this is worse because if you get it wrong with pointers you may have a core, with indexes you just get silently the wrong node..
