7 ms·

Where do you get that sense that Rust results in memory leaks? Is that just an assumption you’re making about languages without garbage collection, or are there

Where do you get that sense that Rust results in memory leaks? Is that just an assumption you’re making about languages without garbage collection, or are there examples you’re aware of Rust applications having to deal with runaway memory consumption?

Xylakant 5y ago
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.
- bsder 5y ago
  You are invoking std::mem::forget which is explicitly for circumventing destructor execution and then complaining about leaks. Okay. The documentation page for std::mem::forget goes through all the alternatives you should try before resorting to std::mem::forget. Now, perhaps std::mem::forget should be marked unsafe. However, you don't just "accidentally" run std::mem::forget. BTW, one of the problems with GC languages is the fact that you never know when your destructor might get run (ie. object gets reclaimed) so your GC thinks life is just fine but ... oops ... you just ran out of file descriptors because they are all waiting to be reclaimed.
  - lillecarl 5y ago
    C# has disposable objects (an interface), they require you to call dispose manually, though the "using" syntax makes this automatic once the variable goes out of scope so unless you're passing the object with an FD around you don't really notice it. Though if you miss the using on a disposable object you're leaking, so you need tooling to help you remember. That's how they solve it, C# is my fav language, but it's probably because I've only really spent time in C++ and C#, the rest is just "scripting". So the syntax is familiar.
  - robotnaoborot 5y ago
    Depends on gc implementation. With reference counting it's pretty predictable.
  - afdbcreid 5y ago
    > perhaps std::mem::forget should be marked unsafe It was in the past IIRC. The problem is that there are multiple ways to leak resources in safe Rust (e.g. creating `Rc` cycles), and the compiler cannot prevent them all. So leaking is safe, and because it's also useful sometimes, `std::mem::forget()` and friends (e.g. `Box::leak()`) are also safe. That being said, it is pretty hard to accidentally leak memory.
  - etra0 5y ago
    Doing std::mem::forget is not unsafe as you cannot get any sort of undefined behavior which is what Rust protects you from [0]. Leaking is pretty safe, not always desired but definitely not dangerous like random pointers derefs. But as OP says, leaking accidentally is uncommon. [0] https://doc.rust-lang.org/nomicon/safe-unsafe-meaning.html https://doc.rust-lang.org/nomicon/safe-unsafe-meaning.html
  - Xylakant 5y ago
    I'm not complaining - I'm pointing out that leaking memory is considered "safe" in the rust memory model to the point where there is a safe method in the stdlib to do so.
- pornel 5y ago
  Rust is precise with what it guarantees, but don’t take “not an absolute guarantee in every case” as “no guarantee at all”. Leaking in Rust requires either explicit leaking function call, leaking in C/FFI code, or a type that is 1. recursive 2. refcounted 3. with interior mutability, and 4. a programming error in use of such type. If any of these four conditions aren’t met, it can’t leak.

Xylakant 5y ago

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.

bsder 5y ago
You are invoking std::mem::forget which is explicitly for circumventing destructor execution and then complaining about leaks. Okay. The documentation page for std::mem::forget goes through all the alternatives you should try before resorting to std::mem::forget. Now, perhaps std::mem::forget should be marked unsafe. However, you don't just "accidentally" run std::mem::forget. BTW, one of the problems with GC languages is the fact that you never know when your destructor might get run (ie. object gets reclaimed) so your GC thinks life is just fine but ... oops ... you just ran out of file descriptors because they are all waiting to be reclaimed.
- lillecarl 5y ago
  C# has disposable objects (an interface), they require you to call dispose manually, though the "using" syntax makes this automatic once the variable goes out of scope so unless you're passing the object with an FD around you don't really notice it. Though if you miss the using on a disposable object you're leaking, so you need tooling to help you remember. That's how they solve it, C# is my fav language, but it's probably because I've only really spent time in C++ and C#, the rest is just "scripting". So the syntax is familiar.
- robotnaoborot 5y ago
  Depends on gc implementation. With reference counting it's pretty predictable.
- afdbcreid 5y ago
  > perhaps std::mem::forget should be marked unsafe It was in the past IIRC. The problem is that there are multiple ways to leak resources in safe Rust (e.g. creating `Rc` cycles), and the compiler cannot prevent them all. So leaking is safe, and because it's also useful sometimes, `std::mem::forget()` and friends (e.g. `Box::leak()`) are also safe. That being said, it is pretty hard to accidentally leak memory.
- etra0 5y ago
  Doing std::mem::forget is not unsafe as you cannot get any sort of undefined behavior which is what Rust protects you from [0]. Leaking is pretty safe, not always desired but definitely not dangerous like random pointers derefs. But as OP says, leaking accidentally is uncommon. [0] https://doc.rust-lang.org/nomicon/safe-unsafe-meaning.html https://doc.rust-lang.org/nomicon/safe-unsafe-meaning.html
- Xylakant 5y ago
  I'm not complaining - I'm pointing out that leaking memory is considered "safe" in the rust memory model to the point where there is a safe method in the stdlib to do so.
pornel 5y ago
Rust is precise with what it guarantees, but don’t take “not an absolute guarantee in every case” as “no guarantee at all”. Leaking in Rust requires either explicit leaking function call, leaking in C/FFI code, or a type that is 1. recursive 2. refcounted 3. with interior mutability, and 4. a programming error in use of such type. If any of these four conditions aren’t met, it can’t leak.