[Arch485]

I've never really had the urge to use GC in Rust, but if I were to speculate, I'd say easier cyclic references would be one benefit. And depending on the specific GC implementation, you can probably get around many of Rust's ownership rules because Gc<T> pointers are usually `Copy`, so you can pass things around everywhere and not think about references/ownership as much.

[mayhemducks]

Okay I could see that - like implementing linked lists would be easier yeah?

I just feel like not having GC is sort of a deliberate, core design choice for the language. Having strict ownership rules and being forced to think about references feels like a feature not a bug you know? Adding GC feels analogous to the "++" in C++ to me.

Not that I have anything against the efforts people are putting into it though - I'm genuinely curious about what it lets me do better/faster within rust.

[WorldMaker]

GC is a similar but different set of strict ownership rules (and its own versions of being forced to think about reference invariants). There's an inherently interesting Venn Diagram overlap between Rust borrow mechanics and GC, they aren't entirely separate worlds. They are more like related worlds with slightly different trade-offs. (Similarly there's C# and .NET actively exploring GC-safe relatives of Rust's borrow mechanics in Memory<T>/Span<T> space right now, to great effect.)

In terms of practical, yeah a doubly linked list (or trees with bidirectional pointers to both parent and children, etc) is especially easier to implement in a GC environment than with Rust borrow checking alone. You can do it without a GC, but a GC can be a helpful intermediary.

[Arch485]

I agree completely; I think choosing Rust and then adding a GC is a weird design choice. If I was in a situation where I really, truly needed GC for my memory management, I wouldn't use Rust.