waffle

Perhaps the best argument against garbage collection is this:

But if I code garbage collected apps, my apps will be slower.

The prevailing opinion about GC is that apps using it will be slower, but there’s nothing that means it inherently is slower. Allocation in garbage collected apps are commonly as fast as stack allocation because the language doesn’t have to hunt for open spots.

But, okay, let’s say GC really does mean a performance hit - the net result in most cases today is usually that it does. My question in return is:

So?

Your app gets a little bit slower and you get a whole lot more productive. Moore’s law will help recuperate that time loss if not during lunch (in most cases, GC really isn’t that heavy) then easily within six months. If you continue to manage memory manually (even with the “semi-automated clutch” approach Cocoa and Objective-C takes), will you get more productive? No. Your apps will run a few milliseconds faster, maybe a few tens of milliseconds faster, and that’s it.

Unless these milliseconds really are critical to you in a documented way, why would you choose “runs slightly faster” above “makes you more productive by being able to focus on other stuff”?

I have written heavy, multi-threaded, efficient, interprocess-communicating, (”mission-critical” if you will) applications in garbage collected languages. What has been the ceiling blocking it from getting faster? Multi-threaded lock congestion. The memory limits of 32-bit Windows. In my experience, once you descend into such heavy use that the cost of GC is becoming unbearable, you’ll start to see the limits of other technologies as well, and dumping GC won’t mitigate the problem.