Comment by delluminatus | Hacker News Reader

Comment by delluminatus | Hacker News Reader

Parent Full thread

I can comment on a few of those. I'm not a Rust expert but I've been following it some. One thing I don't know about are coroutines. I know Rust has iterators but I don't think those are quite the same?

Rust uses lazy iterators for everything (including functions like map, and datatypes like arrays).

Rust actually has a full hygenic macro system (metaprogramming). IMO this is one of the coolest things about Rust.

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.

Although there are no "pure functional" (i.e. side-effect free) guarantees in Rust AFAIK, the borrow checker actually catches a lot of issues that pure functional programming is meant to fix (i.e. issues from unexpected state mutation). Also, variables in Rust are immutable by default, you have to use the "mut" keyword to make them mutable.

>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.

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