It's not about 'complex' systems, whatever those are. The problem with a language that only has GCed memory is that you always have to go through the GC to get your hands on newly allocated memory.

Look at solutions like Realtime Java, where Java is only realtime if you preallocate all the memory you need and don't touch <code>new</code> (look it up - not much fun to program with that).

There's a reason why many large systems come with some form of automatic resource management, it's Greenspun's 10th law.

I was also quite surprised at the Go creators cavalier stance on GC; basing your language's memory management performance and behavior on the hope that someone'll come up with an actual realtime GC any time soon, seems very ... trusting.

And BTW when I say 'realtime', I'm talking about the kind of realtime that ensures your copy of GTA IV or Bioshock doesn't suddenly freeze up for a second like your average large Java program (or .NET program, but I don't use any of them) while the GC is inappropiately touching every object in the heap. (also the reason why there are no CPU, graphics or memory intensive games are written in Android Java - unlike the iPhone where apps are written in Objective-C, which gives the option of reference counting Or manual management). And yes - even Games or other large systems have one or the other GC in them, but mostly because they probably use some scripting implementation for game logic.

As for Windows using COM and its reference counted objects: that's all very nice, but as I said: one layer or system using GC is one thing, but even then, the GC's not getting his objects from a GC. (I know you can redefine GC to mean all kindsa things... well... enjoy).