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 wit

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.