We adopted Rust for its security and are seeing a 1000x reduction in memory safety vulnerability density compared to Android’s C and C++ code. But the biggest surprise was Rust’s impact on software delivery. With Rust changes having a 4x lower rollback rate and spending 25% less time in code review, the safer path is now also the faster one.
(Emphasis in original.)
Of course, we should probably take the numbers with a grain of salt here; it’s not a controlled scientific experiment, and the estimated vulnerability density for Rust in particular was calculated with a numerator of 1, so it could be way off.
Still, I think it’s a good reminder that advocacy for using Rust over C and C++ isn’t purely out of some irrational fanboy-ism for the language. The numbers here would have to be extremely off for there not to be a major effect.
Further down in the article:
This near-miss inevitably raises the question: “If Rust can have memory safety vulnerabilities, then what’s the point?”
The point is that the density is drastically lower. So much lower that it represents a major shift in security posture. Based on our near-miss, we can make a conservative estimate. With roughly 5 million lines of Rust in the Android platform and one potential memory safety vulnerability found (and fixed pre-release), our estimated vulnerability density for Rust is 0.2 vuln per 1 million lines (MLOC).
Our historical data for C and C++ shows a density of closer to 1,000 memory safety vulnerabilities per MLOC. Our Rust code is currently tracking at a density orders of magnitude lower: a more than 1000x reduction.
Using the sum of C and C++ is a bit misleading. If you use C++20 or later with containers, smart pointers, … the number of memory safety problems goes down a lot. But if you include all the problems from C and older C++…
Ah but then you would actually have to use C++ /jk
On the phoronix forums there are people seething about Rust nonstop. Rust in the linux kernel is their favorite enemy and they will have very strong opinions about it without ever having written rust nor a line of code in the kernel.
Rust won’t 100% replace C++ code in old code bases but I’m convinced that in 5-10 years the amount of new C++ code will fall behind Rust code.
5 years is optimistic. More likely 10-20 years at least. Established languages have a lot of inertia and it takes a very long time for that to change.
language popularity can change pretty quickly
according to the tiobe index, in 1985, lisp was the 2nd most popular programming language and c++ was the 10th. fast-forward 5 years and c++ took the 2nd place, while lisp fell down to 7th place. i wouldn’t be surprised if something similar happened between c++ and rust
Inertia also accounts for time and popularity. The longer something has been around and popular the more inertia it has and the harder it is for something to change it. Back in 1985 things had a lot less inertia then they do today - C and C++ have been gaining it constantly for 30 years since then.
To me the inertia could be measured in time to refactor projects.
How much time would it take to refactor or create a net new replacement of all of the lisp code of 1985 in active production vs all of the c++ in active production today.
I do not know the numbers but I would hypothesis a staggering delta in hours needed from the then to now. Even with advancements in code change velocity of today
Considering the fact that there are crucial programs all across platforms that are written in Assembly and are still very relevant. This couldn’t be more true.
@shape_warrior_t I think faster delivery is also a consequence of a good DX,
managing dependencies and building with cargo is probably less cumbersome than installing specific toolchain and fighting makefiles and CMake.I’m not sure that’s a factor here because Google doesn’t use CMake or Cargo (at least not the way we all use it).
