Hacker News Reader

Comment by veddan | Hacker News Reader

>Rust does not use reference-counting GC. Instead, it has a fairly unique borrow checking system for garbage collection, which not only handles cleaning up memory but also cleaning open sockets, file handlers, etc. There is a generic type implementation of a reference counted variable you can use, though.

Rust does not have garbage collection, unless you count using types like Rc<T> garbage collection. It has destructors, just like C++, and uses them for cleaning up resources like file handles and memory. Lifetimes do not really interact with destructors. They're part of the type system and do not have any effect on the generated code.

View on HN

I was given the impression that as soon as the lifeline was out of scope, the resources were cleaned.

So it acts like a GCed language in most ways, in that, most of the time you don't have to worry about cleaning up after yourself, and that it is hard to memory leak.

If you'd like to call that a form of GC, I'd prefer to call it "compile-time GC" to avoid confusion. I rarely see "garbage collection" being used to refer to anything other than dynamic garbage collection.

> I was given the impression that as soon as the lifeline was out of scope, the resources were cleaned.

And you are right.

Even though GP is almost right, lifetimes do interact with destructors and, in fact, dictate when values go out of scope and hence when drop (Rust destructor) is called.

> So it acts like a GCed language in most ways, in that, most of the time you don't have to worry about cleaning up after yourself

Nope. In Rust you almost always have to worry about cleaning up although not explicitly, but via lifetime and ownership management.

Sometimes you're lucky and those lifetimes can be inferred, but you still have to think about ownership a lot.

> and that it is hard to memory leak.

But not in the same way.

In Rust you can memory leak only when:

- Using GC like Arc or Rc with cycles.

- On blocks/fns marked as unsafe (which are mandatory for unsafe operations).

- Running into a Rust bug.

> And you are right. Even though GP is almost right, lifetimes do interact with destructors and, in fact, dictate when those are called.

It's actually the other way around: scoping dictates when destructors are called and the length of the lifetimes of borrowed pointers etc.

That is, the main factor is scoping, and lifetimes just reify that into something the programmer and compiler can reason about, to ensure safety.

> That is, the main factor is scoping

Sorry, I meant (and I guess myrryr meant too) ownership instead of lifetimes. I was in the process of ninja-editing my comment when I saw your reply :P

Ownership dictates when a value goes out of scope and hence when the destructor is called.

Reply on news.ycombinator.com