News for hackers. Stuff that matters.
Re:Why is D's garbage collection slower than GO's? by zozbot234 on Saturday October 29, 2022 @05:50AM (#33382527)
> But with with Swift, Rust and modern C++ the argument can be made that GC doesn't bring anything to the table.

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.

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.

Re:Why is D's garbage collection slower than GO's? by ninkendo on Sunday October 30, 2022 @03:54PM (#33398004)
The specific point I’m making is that the “interesting case” is rare. Rare enough that I’ve never seen it in person.