I like not having to think about lifetimes and ownership when I'm building a tree for example, and for most of what I do I can afford the performance hit.
Is there a reason you'd not just throw RC-like solutions on it? Ie the GC is basically going to employ a handful of techniques with overhead like RC, memory Arenas, etc - which you could also use in Rust.
So i imagine you know this, is it the syntax you're trying to avoid? Ie wrapping a lot of things in RC's is annoying?
A few reasons. Like you said, syntax, wrapping and unwrapping is annoying. Also, RC doesn't cover cases with cyclic references. I think the difference is that for me GC is the default. For me, you need a good reason to not use a GC. Moderns GCs are very, very good and like I said I'd need a good reason to not use it. That's personal though, and I understand that not everyone agrees.
I don't know this field, perhaps my bar is low because of Python lol, but Go's GC has very short GC pauses. So short that it makes non-GC'd usecases less attractive imo.
My big issue with Go's GC, or GC's in general, is consistency. Go's GC can still be variable in pause time iirc. But it's been ~3 years since i've worked in it - so maybe my memory is wrong :)
From what I understand Python uses reference counting, which is a type of garbage collection that allows you to have deterministic performance, almost no "pauses" but at the cost of performance.
About the consistency, I think that's not a GC problem in general. For example, Java's ZGC has constant pause times: https://malloc.se/blog/zgc-jdk16.
So i imagine you know this, is it the syntax you're trying to avoid? Ie wrapping a lot of things in RC's is annoying?