Comment by dataflow | Hacker News Reader

Comment by dataflow | Hacker News Reader

Parent Full thread

> I’ve met a lot of seasoned C++ developers who tell me the memory safety won’t be an issue in practice. Hell, I’m sure I’ve said it before too.

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.

To add to that, there are some applications for which memory unsafety just doesn't cause that much harm.

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!)

The issue isn’t that patching and fixing code to be safe takes a ton of your own time, but it’s about the risk to everyone using your code.

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

Running inside a memory safe virtual machine is obviously safe though, that doesn’t mean the language itself is safe.

The problem with memory safety bugs is that they are uniquely exploitable. Even if memory bugs only take 5% of your time as a dev, there have been numerous studies showing that for large projects, memory bugs form roughly 2/3ds of CVE causing bugs.

Yeah that's why many C++ folks are continually trying to improve memory safety too.

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...

Honestly, I think what you describe is a much more defensible claim--in fact, I suspect it's true that the vast majority of bugs in C++ code aren't memory safety. I've often seen the stronger claim that memory safety problems don't come up at all in idiomatic C++, though, and that isn't true.

Fun fact: There's been a number of spectacular memory safety bugs in Rust programs where you have no option but to go unsafe. Which, in real systems programming, is quite often...

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.

As one of the people who often make this argument, this is spot on: I continually see people who say they are spending some ridiculous amount of time actively debugging memory safety issues as part of their normal development, and to me that indicates they are either an amateur or an idiot... like I just can't imagine what that must be like for them, as pretty much the only time I have to spend any serious amount of time tracking down an issue with memory corruption in my projects is when I run into some weird build system issue (which is sometimes caused by actual compiler bugs in clang/gcc that I have to painstakingly bisect and report upstream, but is sometimes an issue with an SDK or linker) that results in incorrect code being executed. I am not, under any circumstance, claiming that my software is free of bugs! I am 100% kept awake at night by the idea that someone will find a serious and exploitable mistake somewhere; but, almost by definition, that obscure issue isn't something that is taking any of my development time because, if I knew about it, I would already have fixed it and that would result in never having exploitable bugs in production software... put differently, unless you are being actively negligent, any dangerous/exploitable memory errors in your code aren't issues you are actively debugging: they are unknown sleeper issues (and then: issues which I will then claim are likely to be trivial to analyze and fix once seen). The point of using a memory safe language isn't to make your development faster: it is to make your development correct.

Reply on news.ycombinator.com