3 ms·
Good luck with this. I find GC programming really hard as any small mistake snowballs and becomes super hard to find during debugging. Some of the mistakes see
by papaf 9y ago
Good luck with this. I find GC programming really hard as any small mistake snowballs and becomes super hard to find during debugging.
Some of the mistakes seen by the author could just be the original programmers being tired of painful debugging.
- WalterBright 9y agoThe mistakes seen by the author aren't bugs. They're just less performant algorithmic choices. One charge not leveled at D's GC is bugginess. The GC has proven to be pretty robust.
- gwbas1c 9y agoWhat are you talking about? GC programming is usually the easiest to avoid small mistakes. Circular references? GC will collect them! (Reference counting does not handle circular references.) Usually the two mistakes with GC are forgetting to empty collections, (which is also a problem with manual memory management,) and relying on finalizers to clean up resources. GC will not "read your mind" and magically close your open sockets, release your file handles, and dereference your static references. It just frees you from the tedium of releasing transient memory, like strings; and it frees you from tracking lifetimes of memory when you don't need to. In my experience, the programmers who have trouble with GC are the ones who don't understand the difference between memory management and resource management.
- distances 9y agoThey meant implementing the GC itself.