> D with `@nogc` is also going in the other direction, trying to avoid the GC. > Rust is hard to judge, Arc<T> is easier to use than its ownership system and > so people end up using it in lots of places where it's not required. Maybe, I > don't know its ecosystem well enough to judge really.
The problem I am getting at here is multiple or shared ownership. Pretty much all methods to avoid GC come down to assigning responsibility for deallocating memory to one entity that can be determined at compile time. When you cannot figure that out statically, you have to resort to a runtime mechanism. One common example is [hash consing](https://en.wikipedia.org/wiki/Hash_consing), which is used to implement things such as [binary decision diagrams](https://en.wikipedia.org/wiki/Binary_decision_diagram). The lifetime of any given value under such a scheme cannot be determined statically. Another (and more commonplace) example is that of a shared global (or even thread-local) cache. Assume that you have a function proc f(x: A): B = ... Run Now, for performance reasons, we want to keep recently computed values in an LRU cache, indexed by keys of type A and containing values of type B. As the lifetime of any stored key or value is unpredictable due to LRU cache semantics, but the module also doesn't know how long the caller will hold on to either the argument or the result, there is no real way to bound the lifetime on either the caller or the callee side. You will need either reference counting (thus also most likely changing the interface) or use copying to avoid multiple ownership, with all the costs that entails. Rust's borrow checker actually goes to considerable effort to make it possible to avoid falling back to reference counting in more cases, but that's also why it is so complex and it still needs a reference counting scheme to deal with many cases of multiple or shared ownership.
