Mysteriously, I have lost my Journeyman status. Perhaps someone bumped me back to Observer, I'm not sure. Oh, well.

I wanted to post a couple of points about C and C++ not having garbage collection:

• It's the programmer's responsibility to use an appropriate resource control mechanism.
• Garbage collection is only the 'magic' solution for memory. What about other resources? Is the runtime system smart enough to run the GC when you're out of filehandles? How about when you're out of foos?
• Do you really want garbage collection to be an integral feature of a language you used to right an OS?

In my opinion, a language that gives you choice and flexibility in resource control techniques is much better and a big win over a language that doesn't.

In my StreamModule system, I use reference counting for a data structure (the structure representing a sequence of bytes) that can only be a DAG by the rules under which it is built. This is exactly the appropriate technique. The reference counting overhead is incurred in a very predictable and controllable manner.

I even have a small infrastructure (smart pointer classes and a mixin class that has the counter) built up to make it easy for a certain data structure to participate in reference counting where appropriate. In fact, in the combining list tails problem that someone mentions is a perfect candidate for using this infrastructure.

If ever I wanted cycle-resistant mark & sweep style garbage collection, I could find it or implement it and use it for exactly those data structures it was appropriate for. With a little discipline in how you use pointers and a little programmer prodded compiler assistance, you can operate a non-conservative mark & sweep collector in an environment that doesn't enforce one from the top down.

In Python, Perl, and other such 'scripting' languages, garbage collection is the right answer. In Java, it's a descision I strongly question. In C, C++, Ada, FORTRAN, and other such 'systems' languages, it's the wrong answer.