Re:Why is D's garbage collection slower than GO's?
by ninkendo on Saturday October 29, 2022 @08:44AM
(#33383574)
I mean, what you’re saying is probably technically true for very specific problems that are contrived specifically to show shortcomings in refcounting, but in practice I’ve never seen it matter.
Weak and unowned pointers are pretty simple to deal with, and I’ve never seen a situation where it’s really confusing whether a pointer should be strong or weak in swift. Everything mostly just works, and if you need to point back to the object that owns you, it’s usually pretty clear by the abstraction you’re building that you need a weak/unowned reference to do it.
Re:Why is D's garbage collection slower than GO's?
by zozbot234 on Saturday October 29, 2022 @10:10AM
(#33384165)
> and if you need to point back to the object that owns you
That's not the interesting case; that is indeed easily addressed by "weak" pointers. What's interesting is the case of a spaghetti reference graph where none of the objects definitely "owns" any other, and even the choice of GC roots might be dynamic.
GC will always be needed to solve problems dealing with general graphs containing possible cycles. Not coincidentally, this describes many of the GOFAI problems for which GC (in the context of LISP) was first developed.