I see what you are saying, but unfortunately garbage collectors in their present form are more evil than good. They are fine in some situations, but may turn to a problem in others. For example, you may get very undesirable effects if you are creating and destroying a large number of objects in a time-critical application (a game, etc).
So, languages that provide no way of controlling allocation have relatively limited application compared to those that do provide full control over memory allocation.
By "relatively limited" I mean just relatively, that is, the reason Python, Ruby, Perl, PHP, Java, C# and Lisp with their GC facility exist is that it works most of the time, but there are certain areas where you have no choice other than C/C++. Kernels, compilers (including Lisp compilers), game engines, everything that deals with hardware, image, audio and video processing, etc etc.
This is an endless list where you really have no choice. Try to write a VST plug-in in Lisp, for example, that would add a reverb and will be able to do it on 8 audio channels in real-time on a 3GHz CPU.
> I see what you are saying, but unfortunately garbage collectors in their present form are more evil than good.
Wrong
> They are fine in some situations, but may turn to a problem in others.
Correct.
> For example, you may get very undesirable effects if you are creating and destroying a large number of objects in a time-critical application (a game, etc).
Not if you're using a reasonable real-time GC.
If allocation and reuse is occuring, memory management code is being executed.
GCs tend to run a bit slower, but you get faster development. Sometimes that's a good trade, and sometimes it isn't. (My real-time friends are correct when they say that late answers are wrong answers. However, it's also true that wrong answers are wrong answers.)
> compilers (including Lisp compilers)
Wrong again.
> everything that deals with hardware, image, audio and video processing
Wrong again. (Yes, lots of such systems are built with C/C++ but folks have done them with GC languages.)
And, our python friends have figured out that one can use C/C++ as an extension language for the heavy processing, where very little memory management occurs, and python everywhere else, getting the benefit of both worlds.
This is important because, when you get down to it, most of the applications that have lots of signal processing and the like are actually a couple of time-critical small kernels surrounded by lots of other code. Said other code dominates development time so GC for it is a big win.
> game engines
Yes and no, because "game engine" covers a wide range of things (from physics and rendering through high level "AI") and it depends on the available processing power.
I remember seeing exactly the same argument wrt assembly language vs C.
One interesting thing about the "performance is everything" crowd is how many of them use gcc even though there are other compilers for many ISAs that deliver significantly better performance.
So, languages that provide no way of controlling allocation have relatively limited application compared to those that do provide full control over memory allocation.
By "relatively limited" I mean just relatively, that is, the reason Python, Ruby, Perl, PHP, Java, C# and Lisp with their GC facility exist is that it works most of the time, but there are certain areas where you have no choice other than C/C++. Kernels, compilers (including Lisp compilers), game engines, everything that deals with hardware, image, audio and video processing, etc etc.
This is an endless list where you really have no choice. Try to write a VST plug-in in Lisp, for example, that would add a reverb and will be able to do it on 8 audio channels in real-time on a 3GHz CPU.