Hacker News Reader

Comment by pcwalton | Hacker News Reader

> Also I think that garbage collection, if fast (which nimrod's is very much so) is the right way to go in some situations.

Definitely in some situations garbage collection is the right thing. But Nimrod's garbage collector is not thread safe...

> I don't actually want to go and spend time freeing a bunch of strings right after I use them.

That isn't how Rust works. The compiler automatically frees things via RAII.

View on HN

RAII is sorta by definition immediate. They are freed right when they exit scope, this can be annoying for large tree structures.

Yeah the GC not being thread safe can be annoying. CSP works OK and if you need more performance a thread safe GC may not be fast enough anyway. If rust can pull off ownership tracking between threads in an easy-to-use way then I would be super excited.

Well, you don't have to free in your destructor eagerly: you could incrementally release if you wanted to, and still use RAII. But you're right of course that RAII makes it simplest to eagerly deallocate.

Eager deallocation is usually what you want anyway, because of its cache effects and because you can just release the memory back to the free list (or the OS) and forget about it. If you repeatedly allocate and deallocate a similarly sized block, for example, eager deallocation means that your block will stay in L1 if it fits.

Um, what are you talking about.

There's a separate heap per thread and data sharing among threads ins't allowed. It's perfectly thread safe.

The language doesn't enforce that GC'd pointers don't pass between threads. The GC can silently free stuff you didn't want freed if you pass objects between threads. This is not a property of a thread-safe GC.

Yes, but in practice practically everything in Nimrod is a value, not a ref, so GC'd pointers are an extremely rare duck.

Reply on news.ycombinator.com