Memory leaks are by far the least interesting class of defect that Rust helps with - leaking memory is safe.
Arnavion · 15h ago
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.)
dmit · 15h ago
Yes, the only difference.
airstrike · 16h ago
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.
jayd16 · 16h ago
Possible attack vector, though.
andrewflnr · 16h ago
The least interesting attack vector. You can fix it by rebooting.
genter · 16h ago
Until the kernel kills you for being OOM.
YZF · 16h ago
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.
scotty79 · 16h ago
Program that no longer runs is the safest.
aquariusDue · 16h ago
For true safety we must prevent it from being written in the first place /s
dmit · 15h ago
That's the true meaning of backward compatibility. The [backward] refers to the time scale.
drivingmenuts · 15h ago
stomps butterfly
I've just saved untold generations from certain calamity.
** 6,000,000 years later **
Butterfly King: This chimpanzee-descended motherfucker ….
linotype · 15h ago
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.
squirrellous · 9h ago
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”.
sunrunner · 14h ago
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.
yusina · 15h ago
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".
teleforce · 9h ago
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):
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.)
api · 16h ago
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.
bluGill · 15h ago
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.
on_the_train · 15h ago
There's static analysis which can effectively force these things. C++ problems are self-inflicted
bluGill · 9h ago
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?)
andrewflnr · 15h ago
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.
shmerl · 15h ago
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.
fithisux · 13h ago
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.
(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.)
EDIT: Safe in the sense you're not writing into memory you don't own, e.g. write after release, buffer overflows etc.
I've just saved untold generations from certain calamity.
** 6,000,000 years later **
Butterfly King: This chimpanzee-descended motherfucker ….
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".
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...
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 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.
for that matter though I've seen rust programmers put everything in unsafe.
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.