Even if true, that's overly dismissive and unactionable, especially when several programming languages bake the same reference counting into their most basic re

Even if true, that's overly dismissive and unactionable, especially when several programming languages bake the same reference counting into their most basic reference semantics, as a poor man's half baked non-sweeping garbage collector. Further - find me a programmer who always designs code properly, and you will have found me a liar. One actionable alternative is explicit owner/borrowing smart pointers, which assert if an owner is destroyed while borrowers are pending - which while not eliminating bugs, at least makes them much shallower to debug. I don't have hands on experience with that style - I inherit codebases and their existing coping patterns too often - but I hear good things from those who do. Another actionable alternative is resorting to a proper garbage collector. Or using a proper COM pointer type. Or RIIR. I resort to Rc/Arc in Rust much less than I resort to shared_ptr in C++ (although it still has its niches.) Then again, I used Arc twice just yesterday: https://github.com/MaulingMonkey/rust_http_chat_server/blob/master/src/main.rs https://github.com/MaulingMonkey/rust_http_chat_server/blob/... `Common` (shared between request-handling worker threads) could be made static instead of Arc (although this would eliminate having separate isolated state for, say, different hosts?) Or I could use a scoped thread API that ensures the worker threads are cleaned up before the main thread does, and leave it on the stack instead. The standard library's scoped threads are nightly-only, but there are third party crates - or I could roll my own with `unsafe { ... }`. `Arc<String>` messages (shared between chat history broadcasting threads until every recipient has sent out a reply) could be simply deep copied. Given the small typical message sizes, that might even be cheaper (although with the heap allocs I wouldn't bet on it.) Or a proper thread safe mpmc FIFO container could be used, although none is in the standard library. A 200 LOC monolithic main.rs isn't exactly well designed, but it didn't need to be. That's a cop-out, but I suspect your pull requests won't be forthcoming either ;).