Hacker News Reader

Comment by jdf | Hacker News Reader

I forgot to add - I partially agree with you about the productivity of GC. For non-performance sensitive code, GC simplifies a lot. Otherwise, I find Go much nicer to reason about than Java since it has real arrays (value types!).

But I find it a mixed bag of whether the naive Go version of something that shares memory by GC is simpler than the naive Rust version of something that shares memory. Sometimes ref-counting (Rc<T> in Rust) is fine, although that's more expensive than GC. Sometimes Rust's ownership model nudges you to make the code much simpler and makes it clear that something only has a single writer. Sometimes you wish you were in C and just did it yourself...

View on HN

> Sometimes ref-counting (Rc<T> in Rust) is fine, although that's more expensive than GC.

To nitpick: The jury's still out on that one, because Rc in Rust isn't thread-safe reference counting. I believe that non-thread-safe reference counting is quite competitive with global, cross-thread tracing GC.

When people (rightly) talk about how much slower reference counting is than tracing GC, they're almost always talking about either thread-safe tracing GC vs. thread-safe reference counting or single-threaded tracing GC vs. single-threaded reference counting. When you compare Rc to a typical multithreaded GC'd language, you're comparing multithreaded tracing GC to single-threaded reference counting, which is a much more interesting comparison.

Yes, this is a great point! I was a bit sloppy in my wording above.

> When people (rightly) talk about how much slower reference counting is than tracing GC, they're almost always talking about either thread-safe tracing GC vs. thread-safe reference counting or single-threaded tracing GC vs. single-threaded reference counting.

Reference counting has always been slower, even in single-threaded cases. This should be obvious because pure reference counting requires modifying counts whenever locals are assigned, which happen orders of magnitude more often than main memory updates, and now each local assignment requires touching main memory too.

As soon as you defer these updates somehow to recover that cost, you've introduced partial tracing. You can find papers from way back acknowledging this overhead, and suggesting optimizations [1].

[1] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.25.9...

> This should be obvious because pure reference counting requires modifying counts whenever locals are assigned, which happen orders of magnitude more often than main memory updates, and now each local assignment requires touching main memory too.

I guess so, but it's worth noting that this isn't the case in Rust, because Rc benefits from move semantics. Most assignments don't touch the reference counts at all.

Right, Rust's borrowing is like the optimization link I provided, just slightly less general IIRC.

> Sometimes ref-counting (Rc<T> in Rust) is fine, although that's more expensive than GC.

This is a very interesting and hard comparison to make.

The marginal cost of GCing one more thing is much less than the marginal cost of RCing one more thing. But you need to pay the cost of the GC runtime to get there, and Rust doesn't, so it's a rather hard comparison to make.

However, the cost of RCing something itself is pretty small (and you don't RC very often in Rust anyway), so this rarely matters :)

Reply on news.ycombinator.com