this post was submitted on 12 Mar 2026
28 points (96.7% liked)

Programming

26072 readers
116 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] lordbritishbusiness@lemmy.world 8 points 3 days ago (1 children)

This is my favourite take so far from this post:

"Google’s own data from September 2024 shows that Android’s memory safety vulnerabilities dropped from 76% to 24% over just six years — not by retrofitting safety features onto existing C++ code, but by writing new code in memory-safe languages (Rust, Kotlin, Java). Google’s security blog makes a fascinating observation: vulnerabilities have a half-life. Code that’s five years old has 3.4x to 7.4x lower vulnerability density than new code, because bugs get found and fixed over time. The implication is striking — if you just stop writing new unsafe code, the overall vulnerability rate drops exponentially without touching a single line of existing C++."

Starting to transition away is perhaps the best step if these stats ring true. Then actively seeking out bad C++ practices is probably going to quietly pay dividends as well.

[–] eleijeep@piefed.social 2 points 2 days ago (1 children)

The preceding paragraph is this:

These are massive, legacy-heavy codebases where much of the code predates modern C++ practices. Code written with raw new/delete, C-style arrays, char* string manipulation, manual buffer management — the full catalogue of pre-C++11 antipatterns. And there’s a conflation problem: the studies report “C/C++” as a single category. The Windows kernel is largely C, not C++. Android’s HAL and native layer are heavily C. Modern C++ with RAII, smart pointers, and containers is a fundamentally different beast than malloc/free C code, but the statistic treats them as one.

And then after the paragraph you quote, the author just blasts along with the conclusion that code should be rewritten in memory safe languages like Rust, Kotlin and Java, without even touching on their own observation that modern C++ facilities do make a difference to prevalence of bugs.

What is the reduction in bug rate when rewriting legacy C++ with raw memory management vs. modern C++ with RAII and reference counted pointers? We don't know and they don't want to ask, because it would challenge their main thesis.

I don't disagree that modern C++ safety still relies on the programmer making the right choices, whereas with a truly memory-safe language the compiler makes those decisions for you. But to sidestep the question completely is disingenuous and serves to make those of us who actually care about the specifics (C++ programmers, the people they're trying to convince to retrain) to be incredibly suspicious of the whole argument.

[–] FizzyOrange@programming.dev 1 points 2 days ago

modern C++ facilities do make a difference to prevalence of bugs.

This is true, but just saying "write modern C++!" doesn't actually work in practice. First, there are a ton of footguns that even best-practice C++ doesn't avoid. Using std::shared_ptr? Great, you're probably going to avoid memory leaks. Null pointer dereference? Not so much. What's the modern C++ way to avoid integer overflow?

Second, it's pretty much impossible to completely avoid raw pointers etc. even if you're trying, and good luck getting your colleagues to actually try. I can't even get mine to write proper commit messages. You need a machine forcing them to do it properly. Something they can't opt out of (or at least where opting out isn't the easy lazy option).

So yeah it's better to use modern C++ and it is an improvement, but not enough the change the conclusion that you should just use Rust instead.