I’ve yet to meet one who actually didn’t end up with some safety issue in their code. Not all of their code mind you, but even a couple times can be significant.
Like you, I like memory safe languages because they let me think about my problem and trust the tooling to catch entire classes of mistakes for me
The claim I've heard (and I think also made) is a bit different from that. It's more like: "dealing with memory corruption issues isn't a significant portion of the debugging effort in [idiomatic] C++ code". i.e. the claim is not that you somehow won't run into them; rather, the claim is that they form a small fraction of the actual bugs you run into (either count-wise or time-wise), if you're writing C++ "properly". (If I had to make up a number, I'd say < 5%.)
This obviously isn't to say memory safety isn't an issue, or that security is a negligible property. Rather, it's to point out that most issues are of a different kind, and if you think that memory safety will decrease your workload significantly, that's unlikely to be the case if you're writing C++ with the correct idioms.
I think this response is usually in response to claims about how (say) a language like Rust results in N times faster development than C++. If that's truly the case, it's unlikely to be due to memory safety per se, but due to other factors.
I worked on a very large C++ codebase that compiled to webassembly, which runs sandboxed in people's browsers. It only talked to one (trusted) server.
Like any project, we had plenty of logic bugs every release. They would often result in odd artifacts on the screen and sometimes a crash.
Only 5% of our bugs were related to memory unsafety, and they also resulted in odd artifacts on the screen and sometimes a crash.
In other words, memory unsafety wasn't much of a concern in practice. It was as bad as any logic bug.
This was the main reason we stuck with C++, rather than spend SWE-years migrating to a more memory-safe language.
(I know this is ironic coming from me, who designs a memory-safe language full-time!)
From security risks to simple crashes, C++’s unsafe nature has caused a lot of issues in production in my experience. From renders and apps that crash to subtle security bugs.
Not having to focus on those when shipping software to customers means I can focus more on the actual logic and the associated bugs instead. I’m not getting back crash reports and CVEs that sucks up my time.
My users in turn aren’t getting affected by my crashes and security issues. Every person who reviews my code can also understand the language guarantees and stop passing my code through that lens and instead focus their mental energy on the other aspects of my code, like catching logic bugs.
The effects of a memory safe language extend very far
Zig is vastly safer than Rust unsafe. That's worth noting.
So while Rust's memory safety features is something I love, I absolutely hate the Rust community pushing mem safety as a panacea.
In my line of work, as an embedded programmer, Zig is vastly more appropriate.
Rust and Zig can co-exist just fine.
Here's one of the efforts in this direction (for anyone who hasn't seen it): https://www.chromium.org/Home/chromium-security/memory-safet...