cross-posted from: https://feddit.org/post/21743329

Fortunately, data demonstrates that making a better choice does not require daunting multiyear rewrites of existing codebases. Security can be dramatically improved by incrementally shifting the development of just new code to memory-safe languages. If these vulnerabilities can be avoided with low impact on other development goals, then choosing to introduce new ones should increasingly be considered unacceptable, and our goal should be for vulnerabilities to become increasingly impossible to introduce.

[…] This leads to a counterintuitive insight that defies some popular anecdotes: The most vulnerable code in your project is not some dusty legacy component, but the code being written today. This is because, like most bugs, vulnerabilities have a half life. The longer code exists and is exercised, the more likely its flaws are to be found and fixed, leaving the freshest code with the highest concentration of bugs.

[…]

Beyond stability, there have also been gains in development velocity. Change lead time, the time it takes for a code commit to be successfully deployed, is a critical measure of efficiency. One of the largest factors in this metric is often code-review latency. Our data shows a fascinating trend: As our developer community has gained experience with Rust, the time required for code reviews has decreased (see figure 4b). Rust changes tend to go through fewer revisions and spend less time in the review cycle, with an approximately two times faster median code review in 2024 compared with C++.