Just want to remind everyone that only 1% of vulnerabilities are memory related in the average Joe's code.
And only 20% of memory related bugs are use-after-free which the borrow checker fighting is for.
And 100% of the use-after-free exploits were to gain admin rights on an already hacked Windows (all windows) computer.
So for the vast majority of people the borrow checker adds nothing.
The vast majority of memory safety bugs (extreme pro level, super hard to exploit, only worth it in massively adopted evil outer world facing software) can be fixed by using C++26 with array bounds checking and forced initialisation.
These last two things that Rust forces catch 70-80% of the memory problems the borrow checker only 20-30% only use-after-free.
Most problems by far for normal developers are supply chain attacks, exposing api keys, remote code execution, wrong input validation, wrong auth-flow.
You're reading the CVEs of sudo and ssh and think your code will be hacked like that.
PHP is memory safe and still many people hack wordpress plugins.
> Just want to remind everyone that only 1% of vulnerabilities are memory related in the average Joe's code.
Unless your point is merely that average Joes write such terrible code that you don't even need memory safety issues to exploit their software, [citation needed]
Google says memory safety issues are 75% of exploited zero days. (https://security.googleblog.com/2024/10/safer-with-google-ad...)
Most memory bugs in Chromium are in V8, either entirely in the JIT or at the boundary with C++. Rust wouldn't help here because the borrow checker can't see through these boundaries, and it's precisely this opacity where the developers also lose track of things.
Which isn't to say Rust wouldn't have caught many of the other memory safety issues, but 75% is horribly misleading.
And at least in Chromium project, half of those memory safety issues are use-after-free: https://www.chromium.org/Home/chromium-security/memory-safet...
My understanding is that they claim that the average Joe writes code in a garbage-collected memory-safe language.
Which is... true? but irrelevant. Such applications are not suggested to be ported to Rust. Of course, some people still do that, because they like Rust; but that's their personal choice.
The point is that memory issues are a smallish number of issue compared to the larger ecosystem of vulnerabilities, and choosing to port everything to Rust is like over-optimizing. Well, that’s my 2 cents.
For a language as ugly as Rust, my thought is that people should actually be using Ada, and have a mathematically provable correctness angle; not just a replacement for C/C++ with memory safety.
> The point is that memory issues are a smallish number of issue compared to the larger ecosystem of vulnerabilities
If memory safety issues are 75% of exploited zero days it sounds to me like they're the biggest issue in the ecosystem by far.
Perhaps. But what percentage of exploits are actually zero days versus, say, 10 days or 100 days?
Most exploited code probably exists in the application layer in a high-level, memory safe language. I would wager that but I don’t have time to cite ten papers on HN.
Rust and Ada are about equally safe, both have advantages and disadvantages. Perhaps you're thinking about SPARK ADA, but that's a different kettle of fish.
It's a bit like saying you should program in C, because formal verification tool X generates C code hence C is safe.
Rust and non-SPARK Ada are not equally safe. Ada is unsafe in the presence of data races, and also has runtime checks that slow it down, or you disable them and then it's even less safe.
Yeah SPARK ADA is what I meant :)
I think formal verification is the way to go with AI moving forward.
Rust is a beautiful language. Gorgeous.
Hrmm. I don't think there exists a set of compiler flags that will just make an existing C++ (or, worse, a mixed C and C++) project safe to the extent that you suggested. The STL hardening flags don't help for ordinary arrays that aren't accessed via smart pointers, and they don't help code that uses a pointer+offset style of access. As for UAF, nothing in C++ comprehensively prevents you from accessing an invalid stored reference even if you have cranked up the hardening mode to DEBUG. Rust, on the other hand, affirmatively prevents that.
"extreme pro level"
how old are you?
I do not believe that I agree, and I am not sure about all of your numbers.
The borrow checker does add something, but it definitely costs something as well in multiple ways, also in terms of how it is done in Rust and at a programming language design perspective.
It would be very funny if you were batting for Rust, and just having a laugh at others here.
Any sources for these numbers?
90℅ of all statistics is made up.