Rust Devs Think We're Hopeless; Let's Prove Them Wrong (With C++ Memory Leaks) | Hacker News Reader

Rust Devs Think We're Hopeless; Let's Prove Them Wrong (With C++ Memory Leaks)

babaei.net

27 pointszdw27 comments

Open articleView on HN

Memory leaks are by far the least interesting class of defect that Rust helps with - leaking memory is safe.

Until the kernel kills you for being OOM.

That's still safe.

EDIT: Safe in the sense you're not writing into memory you don't own, e.g. write after release, buffer overflows etc.

Program that no longer runs is the safest.

For true safety we must prevent it from being written in the first place /s

That's the true meaning of backward compatibility. The [backward] refers to the time scale.

stomps butterfly

I've just saved untold generations from certain calamity.

** 6,000,000 years later **

Butterfly King: This chimpanzee-descended motherfucker ….

I'll add that even safety itself is not the sole reason why some people prefer Rust. There's a lot to Rust besides that and sometimes it's not about memory safety as much as it is about steering you into patterns Rust devs perceive as better overall.

Possible attack vector, though.

The least interesting attack vector. You can fix it by rebooting.

And in fact is not even something that Rust does differently from C++. Memory releases in Rust are handled by dtors just like they are in C++. What a weird article.

(The only difference is that Rust defaults to moving while C++ defaults to copying, and Rust moves don't leave a moved-out object behind while C++ does, so the dtors in Rust are simpler and called fewer times than the equivalent C++ code.)

Yes, the only difference.

I’ve seen way more comments from C++ developers complaining about Rust developers insulting them than I’ve seen Rust developers actually insulting C++. It’s weird to see how attached people are to programming languages, though it’s weird to me too how attached people are to ICE/drivetrains.

I think that's because the Rust developers are having too much fun sitting on their high horse shouting about how great the horse is to need to spend time yelling about the people _not_ on the horse, while the C++ developers don't have a horse to yell about so need one to yell _at_ instead.

It’s about jobs and livelihoods, even if not everyone will admit it. It’s easy to emotional when the argument boils down to “your skills are now outdated, go learn a better one”.

It's 2025 and we are still discussing memory leaks. The very existence of this article is an indication that C++ (used like that) has an issue. Non-kernel programmers should not even be able to create memory leaks by mistake.

Well, unless they are doing something incredibly stupid including stepping over several explicit warnings of "don't do this unless you are very sure about what you are doing".

It's really a shame isn't it? It's 2025 and we still have no programming languages that have impeccable GC for automatic memory management rather than forcing programmer to wrestling and fighting for manually managing the memory [1].

Auto industry kind of solved this automation mechanism for example with the new high performance Toyota GR Corolla has a new automatic gear transmission that's proven as fast if not faster than the manual version [2]. The same goes to F1, the epitome of car racing performance.

[1] Understanding Memory Management, Part 5: Fighting with Rust (101 comments):

https://news.ycombinator.com/item?id=43882291

[2] 2025 Toyota GR Corolla's New Automatic Gearbox Democratizes Fun:

https://www.caranddriver.com/reviews/a62672128/2025-toyota-g...

This only works with the VC++ CRT, which is potentially a bit limiting!

Also, the DEBUG_NEW thing is useless in practice since, from memory, it stops you using placement new, and dependencies typically don't participate, so a zillion unlabeled leaks is the usual result from the common case of you failing to call some dependency's free function.

And the allocation IDs (and therefore _CrtSetBreakAlloc) are pretty worthless in practice for multithreaded programs, because the allocation order isn't deterministic.

I use the LEAK_CHECK_DF flag in the programs I write (and the CHECK_ALWAYS_DF is worth investigating too), but the only point is to indicate whether there are leaks on exit, yes/no. If no, great; if yes, well that's useful information, but the actual output is almost never helpful. (Though occasionally I do somehow introduce a leak from something that happens before the first thread is created.)

The problem with unsafe languages is not that you can’t write safe code in them with skill and discipline.

The problem is that programmers don’t always do that, either because they are not that experienced or they are in a hurry.

The real danger is when code is long lived and worked on by multiple people. One bad commit after a late night hacking session and now there is a zero day just waiting to be discovered.

Safe languages don’t rule that out but they make it profoundly less likely.

I write C++ all the time and I still cannot convince many developers to use unique_ptr over new. It isn't that hard to write code that doesn't leak but if you bypass the language features it cannot help you.

for that matter though I've seen rust programmers put everything in unsafe.

There's static analysis which can effectively force these things. C++ problems are self-inflicted

There is but we have code predating c++11 that isn't worth rewriting. So the static analisys is off. We do use lots of static analisys but that one is too hard to fix all the old code that we have decades of proff works and isn't leaking (much?)

I mean, a sufficiently safe language would rule it out. Either one not expressive enough to express memory unsafety (i.e. GC or fully linear types with no escape hatches) or one that requires a machine checked proof of safety to compile. These options just happen to be too big of a pain in the assembly for today's appetite.

There are lots of languages where true memory bugs are impossible. As you say they are higher level and usually GC.

Right, the interesting case would be the formal proof. Though, I suspect there are fewer high-level languages where memory bugs are actually impossible than you would naively think. I've segfaulted Python by accident, only using the standard library (concurrency shenanigans if I recall). You can probably do worse if you try. To make a truly memory-safe language, you would need to carefully design and implement the standard library, disallow all native code extensions, and probably more I'm not smart enough to figure out. So, not Java, not Python. Maybe some Schemes?

No, C++ is hopeless. No need to bend over backwards to try to disprove it. It's not only about memory safety, some of it is about legacy stuff and backwards compatibility it's forever stuck with.

c++ is a huge language, with lots of backwards compatibility.

I think c++ should keep the good modern things and fork (restart) from there by breaking backwards compatibility, c++23 will be frozen with some fixes.

Reply on news.ycombinator.com