We program industrial embedded Java devices such as JStamp/JStik, and C code on Atmel AVRs. The AVR C doesn't have any GC, or even malloc and free - it's all static. We get by fine actually, but these are relatively small, focussed low level apps. Deterministic behavior is essential. So is hard realtime performance. This comes for free with C and careful programming, even on a 16 Kbyte (code) and 1 KByte (data) device. Using I/O and timer interrupts we can create the equivalent of simple multi-threading apps with basically zero overhead. On the small embedded java devices (CLDC, with 2-4 MBytes Flash and 512 KBytes or more RAM) we can choose to use GC or not, and sometimes we have a single thread which does not use GC (and in fact can pre-empt it with ~1 usec context switch). So my point in recounting all that is that programming without GC or with limited GC is likely to be with us for a long time, at least on resource-constrained embedded devices. There GC is the exception, not the norm. And such devices run the machines and equipment all around us.

The most important feature of garbage collection is that you can make the languages more safe. A memory model where pointers are always null or pointing to an object instance is impossible in a non trivial non garbage collected language.

I'm ok w/ old non garbage collected languajes like C, C++, Pascal, etc.. But why on earth would I consider a NEW language that is not garbage collected. That would be a step back in evolution.

In both Java and C++, you need to be careful about the usage and the proper de-allocation of memory. I would say more so in Java than in C++! I have often felt that GCed languages gives us a false sense of security. I have too often been bowled out by innocuous looking inner classes keeping big objects within them. Now with the advent of Closures, it would be far too easy for us to get 'leaked'.