4 ms·

> while avoiding the performance cost of automated garbage collection I think citation needed there. Rust encourages reference counting, which is a very costl

• faitswulff 4y ago
  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.
• kstrauser 4y ago
  Not so much when the count is either 0 or 1.
• mikebenfield 4y ago
  Rust supports reference counting, but it’s a stretch to say it encourages it. I don’t use Rc or Arc all that often.
• vvanders 4y ago
  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.
• richdougherty 4y ago
  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.
• woodruffw 4y ago
  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.
• brundolf 4y ago
  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
  • steveklabnik 4y ago
    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.
    • brundolf 4y ago
      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
• singularity2001 4y ago
  Is ARC being very costly the reason why some people prefer Rust over swift?