On 1/7/2013 3:11 PM, H. S. Teoh wrote:
I think much of the aversion to GCs is misplaced. I used to be very aversive of GCs as well, so I totally understand where you're coming from. I used to believe that GCs are for lazy programmers who can't be bothered to think through their code and how to manage memory properly, and that therefore GCs encourage sloppy coding. But then, after having used D extensively for my personal projects, I discovered to my surprise that having a GC actually *improved* the quality of my code -- it's much more readable because I don't have to keep fiddling with pointers and ownership (or worse, reference counts), and I can actually focus on how to make the algorithms better. Not to mention the countless frustrating hours spent chasing pointer bugs and memory leaks are all gone -- 'cos I don't have to use pointers directly anymore.
I had the same experience. For the first half of my programming career, I regarded GC as a crutch for loser programmers. After working on Symantec's Java compiler, and later implementing Javascript, I discovered that I was quite wrong about that, pretty much the same as you.
One thing I'd add is that a GC is *required* if you want to have a language that guarantees memory safety, which D aims to do. There's an inescapable reason why manual memory management in D is only possible in @system code.
Interestingly, carefully written code using a GC can be *faster* than manual memory management, for a number of rather subtle reasons.
