Hacker News Reader

Comment by barchar | Hacker News Reader

I like nimrod because it has a sane syntax. I can write a function declaration in one line of nimrod that would be 6 lines of c++. I also like Nimrod's focus on static dispatch and easy to use generics.

Rust makes me uneasy because the whole lifetime tracking adds a lot of complexity and I fear it may make some programs harder to write or some libraries harder to use. Also I think that garbage collection, if fast (which nimrod's is very much so) is the right way to go in some situations. I don't actually want to go and spend time freeing a bunch of strings right after I use them.

View on HN

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

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.

Ultimately though, if you don't have GC, you _must_ deal with lifetimes, wheather or not the compiler helps you with them.

well yes. This is true. But nimrod has (very fast) GC. And it also has destructors and RAII so if you really, really need unique_ptr style memory management you can do that. Rust has lifetime tracking but I would be interested to know how it performs against Nimrod's GC when the ownership gets really tricky.

> Rust has lifetime tracking but I would be interested to know how it performs against Nimrod's GC when the ownership gets really tricky.

You can use GC or reference counting in Rust—the same that Nimrod uses. (You could use DRC like Nimrod in Rust if you wanted, but it's not my preferred form of memory management due to the cost of making it thread safe.)

I think one issue is that people have different opinions on whether "ownership gets really tricky" is a common case or an edge case. Many people with unique_ptr experience seem to assume that Rust's owned pointer is more of the same and not really applicable when ownership is even slightly complex, but this is not the case. Rust's owned pointer is vastly more powerful than unique_ptr and in my experience (and in Rust compiler and Servo browser's experience) and "ownership gets really tricky" is an edge case.

Reply on news.ycombinator.com