Hacker News Reader

Comment by rwmj | Hacker News Reader

> while avoiding the performance cost of automated garbage collection

I think citation needed there. Rust encourages reference counting, which is a very costly form of garbage collection.

Rust supports reference counting through std::rc, but most of its memory management is through lifetime enforcement. Basically C++’s RAII pattern, but baked into the language via the borrow checker.

I don't think it's correct to say that Rust "encourages" reference counting. Rust's standard library provides `Rc` and `Arc`, but the default paradigm encouraged by Rust is to do no garbage collection at all (since all lifetimes are validated statically.)

Separately, there's a good argument to be made that Rust does reference counting better than C++: `shared_ptr` has to pessimistically assume use across multiple threads, while Rust allows users to safely select `Rc` instead of `Arc` when the compiler can prove that the inner type is `Sync`/`Send`. Consequently, Rust programs that do use reference counting get "free" performance compared to the equivalent C++ APIs.

std::shared_ptr says hello.

IMO reference counting(be it in C, C++, Swift/ObjC or Rust) is a sign that you have ambiguous lifetimes and strongly correlates with a design that has punted on what components "own" what parts of memory.

Even in my C++ designs I push more strongly toward single owner patterns(member vars, std::unique_ptr) and if an adjacent system needs access usually an opaque handle(that can fail to return a value) is the better than using something like std::shared_ptr.

To the point at hand, I would argue that Rust pushes more towards the single owner model with some sets of escape hatches(Rc/Arc, RefCell, etc) when upstream rigid requirements force some of this ambiguity. I've yet to see a non-GC'd language that does a better job here, and I've found the default Rust guard rails to be quite good, even at scale across developers who may not have the depth of background to understand all of the tradeoffs involved.

Rust's type system tracks ownership and one of the main reasons is so the compiler can automatically know when to free memory without runtime reference counting.

As others have said it's a bit of a stretch to say Rust "encourages" it, but I'm also not sure it's accurate to call it "very costly". It has different costs than mark and sweep, but Objective-C and Swift specifically use reference-counting because of its performance characteristics

And also in Rust you end up with less increment/decrement on the count, because you can safely borrow the interior without messing with the reference count. You really only need to mess with the count when an owner goes into or out of scope, not every reference.

and you can use non-atomic counts if you’re not multithreaded, which is also cheaper.

True! I wonder how much of the GP's viewpoint came from an assumption that reference-counted pointers have to be pessimistic and always perform locking

Rust supports reference counting, but it’s a stretch to say it encourages it. I don’t use Rc or Arc all that often.

Is ARC being very costly the reason why some people prefer Rust over swift?

Not so much when the count is either 0 or 1.

Reply on news.ycombinator.com