It's been a while, but I've written a new blog post:
Rust disallows memory unsafety, but memory leaks are possible.
Only because of logic errors, not because of wrong memory management by the language itself. So this statement is wrong - with same logic you can write "Rust is unsafe!!1" because Rust allows you to execute unsafe code.
While it is true that the memory leaks are due to errors, I do not think that is a particularly useful sentiment for discussing languages. If we were to discount the possibility for logic errors, then we could just say all Rust code is bugfree, indeed, all code in any language is bugfree: "the only way to get a bug is if the programmer makes mistakes, but these don't count". Memory leaks and memory unsafety are different and are handled differently by Rust: you can make all the errors you want in safe Rust code and you'll never get memory unsafety, but this isn't true about memory leaks.
One of the major motivations for Rust is that people make mistakes: programmers are human and logic errors do happen. There would not be nearly as much reason for Rust to exist if this was not true.
(These sort of discussions discount the features pretty much all languages have for side-stepping guarantees, such as those for FFI, or else the discussion would be again uninteresting: all languages would seem to have no guarantees.)
1 Like
indeed, all code in any language is bugfree
No, even Rust has cases, when successfully compiled code will panic - "unwrap", out of bounds access and others. It's exactly where language does not give gurantees. Some languages do not give gurantees about memory management - you just need to do it manually and compiler don't check it. Some languages allow you to write mutexes without checking race conditions and deadlocks. Not all compiled code is guranteed to be bugfree, but Rust gives gurantee about RAII and your statement exactly about this.
My point was that programmer mistakes are something that cannot be dismissed, so waving away memory leaks as just "logic errors" means one needs to wave away other sorts of bugs for the same reason.
The Rust team regards panics as contract violations (programmer errors): for instance, with unwrap, the programmer should be sure that the Option will be Some, and thus if it ever panics the programmer made a mistake, believing that a None could never occur (e.g. insufficient input validation). Similarly, a programmer could incorrectly assume that their graph processing code avoids reference cycles, but carefully constructed input might be able to cause one to happen.
Being a little facetious:
even Rust has cases, when successfully compiled code will leak memory - "forget", strong reference cycles and others.
As my article mentions, Rust does put effort into reducing memory leaks via RAII, but RAII (and hence Rust) does not ensure that no leaks are possible. Rust may guarantee that local variables never leak when they go out of scope by running destructors automatically (unless the value has been moved out, of course), but that is covering just one way to leak memory: it is a common one, but it isn't the only one. Having this guarantee about one possibility is good, but it doesn't mean there's a guarantee about all possibilities.
To reiterate the article: std::mem::forget is safe, and hence memory leaks are not outlawed in safe Rust.