[winter_blue]

I don't know if I would acknowledge that there are problems that have GC as the only and best solution. Perhaps there are certain specific memory management problems for which a GC is the best solution. But what if you avoid that entire class of problems by adopting certain programming paradigms, or by the design of your programming language? For instance, Rust ensures memory safety without a GC. And while I write C++, I rarely find myself directly call new -- most of my objects are allocated by STL containers and via stack building.

[johncolanduoni]

Rust is horrifically bad at dealing with non-trivial cyclical structures for a number of reasons, not having a GC being one of them.

[wspeirs]

Beyond "not having GC", what are those reasons? I'm new to Rust and curious...

[steveklabnik]

See http://smallcultfollowing.com/babysteps/blog/2015/04/06/mode... and its linked post; they cover some of the ways you can write general graphs in Rust. It's a bit differently than you'd do it elsewhere.

Of course, if you're willing to give up some safety internally, you can also implement them the same was as you could in C or C++.

[johncolanduoni]

Inherited mutability and no aliasing mean cyclical structures tend to be a fairly complicated mess of RefCell/Cells. The borrow checker is very good at handling ordered lifetimes but cannot handle more complicated access patterns without the runtime checks in RefCells.

There are graph libraries, but these only help with structures that are graphs in the strict sense (all edges are created equal and not actually part of the structure) as opposed to structs with one or more fields that reference (and have shared ownership of) another node in the graph.

[saucetenuto]

Right, but then you also shouldn't be using the techniques described in the article, right? To put it another way, there's no case where deferred collection with smart pointers is better than real GC.