Nothing stops you from leaking memory in Rust either, it is considered memory safe, see std::mem::forget. Rust only safes you from use-after-free and double-free.
A practitioner oughtn't hit this at all, since the cited chapter contains no leaks. It's actually quite difficult to leak memory accidentally in Rust, short of using the `std::mem::forget` function whose sole purpose is to deliberately leak memory (which can be useful for C interop).
Strictly speaking Rust doesn't prevent memory leaks. You can easily create cycles in reference counted types, or `std::mem::forget` something. No use of unsafe required either.
That said as long as you don't build graphs with reference counted types it's hard to leak memory by accident.
Not if they have circular references... (I agree that Rust makes it difficult to do this accidentally)
Also, remember mem::forget() is not unsafe
I'm pointing this out because I don't want people to have wrong expectation of Rust. Rust doesn't prevent memory leak. Rust doesn't consider memory leak to be "unsafe". Even the Rust team themselves have pointed this out multiple times.
Somehow people are still repeating that Rust can rid you of memory leaks. And I'm downvoted just because I'm pointing out facts. Sigh.
While it is not part of the memory safety guarantee of safe Rust, in practice it is much harder to accidentally leak memory in Rust than in C++. There is no counterpart to the C++ new operator in Rust; no commonly-used language feature or standard library function puts the burden of explicitly freeing memory on the programmer.
For those who are interested in why leaking memory isn't disallowed by Rusts safety guarantees, have a look at the documentation of the (AFAIK) only safe function in the standard library that leaks memory: https://doc.rust-lang.org/std/mem/fn.forget.html
Rust doesn't enforce that. Recently it was shown that Rust can leak memory. Memory safety is the real thing it guarantees, without the cost of a GC. "Easy, safe, zero overhead memory management" might be a one line pitch.
Rust prevents memory leaks about as well as GC'd languages do. (mem::forget in Rust could easily be written in your GC'd language. Rc/Arc leaks are more of an issue, but they're pretty rare because reference counting is uncommon in Rust.)
As lmkg pointed out, leaking memory is considered safe in Rust. There are a number of factors here:
- Leaking memory doesn't cause Undefined Behavior. It might eventually cause your program (or your whole machine) to lock up or crash, but there are many types of bugs that can do that.
- Categorically preventing memory leaks is difficult without a garbage collector. The biggest problem is that you can use reference counted smart pointers like Arc<T> to create reference cycles. Preventing you from doing that at the language level would be too constraining for a lot of real world programs. (In practice, those programs need to break cycles manually using "weak" references.)
- The difference between "reachable" and "unreachable" leaks isn't so big in practice. For example, if I'm caching some data in a global HashMap, I might forget to clear that map, or I might not clear it frequently enough. If the map ends up consuming all of my memory, the effect on my program is the same as if I'd just leaked all that memory. Either way, I need to debug what's going on and make a code fix. (In fact, at least some of the leaks that the Actix post is referring to are this sort of reachable leak.)
For all these reasons put together, Rust allows safe code to leak memory. In fact, there's even a safe standard library function for doing it (https://doc.rust-lang.org/std/mem/fn.forget.html). But it's quite rare to run into unreachable memory leaks in practice, because destructors almost always free memory for you automatically.
FWIW Rust doesn't consider leaking an object to be unsafe. In fact, there's a std::mem::forget() function that can be used to do precisely this. Before Rust 1.0 it was marked `unsafe`, but it was determined that the existence of Rc allowed for creating retain cycles in safe Rust, and "fixing" this was prohibitively complicated, and since it was possible to leak values in safe rust, std::mem::forget() was therefore determined to not be unsafe. This was also when "leaking values isn't a violation of safety" was turned into an actual principle, as opposed to just a hunch that a bunch of people had, and the one API that relied on leaking being unsafe was removed (this was the API for scoped threads, which was marked as unstable right before 1.0 came out, and subsequently an alternative stable safe API for doing scoped threads was hashed out in the crates ecosystem).
Rust as a language does not protect against memory leaks - std::mem::forget even explicitly does so. Generally garbage collected languages do, so trading go for rust increases the risk of having memory leaks.
It does work in rust. you just cannot rely on Drop for memory-safety. If you mem::forget a struct that holds onto some other resource then all that means is that you're committing that resource to the lifetime of the process. We usually call that a leak but it can be intentional.
reply