You are severely mistaken about GC then. GC means to a large extent that programmers should know what their objects are doing. Perhaps even more so than in a non-GC'ed language.
The inherent problem with GC is when you put it into hands of people without that knowledge. Then the GC will save them and reclaim their data, whereas it would otherwise be a space leak and dead program. This means that you will have programs that work, but they will run slowly. GC-fanatics like me say that the program has bad productivity since it spends all its time in the garbage collector.
The advantage of GC though is this: If you know what you are doing, you don't need to manage memory in about 90% of your program. It is often either good enough or way faster than doing it yourself. Both in raw performance and in programmer time. A hint is that most modern parallelizing malloc routines use garbage collection internally to make them run more concurrently and faster :)
For the last 10%, the solution is the same as in any other language. You allocate large chunks of memory and then you handle that memory yourself. The advantage is that you only have to do this for a small part of your program and that means you can build software much faster.
The only place where GC is provably a bad idea is in hard real time systems.
> Programmers should know what their objects are doing.
Programmers "should" do lots of things, but designing as if they actually do is usually a mistake. (If vehicle passengers behaved appropriately, air bags wouldn't be a good idea.)
It's better to design wrt what programmers actually do or get new programmers.
I believe that Rob Pike has made the point that garbage collection is required to make the concurrency model practicable. Being Go's foremost raison d'être, its use of CSP should not be ignored or abused, or you won't be getting much out of Go. That's not to say that low-latency garbage collection isn't interesting, or that Go's authors haven't been around this block. (You might be interested to read http://doc.cat-v.org/inferno/concurrent_gc/concurrent_gc.pdf )
Agreed. But sometimes you can know what your object are doing but not want to manage them.
It's tangential, but in my experience coding in Java or any other GC enabled language doesn't mean you can completely ignore the memory management. You still have to watch for leaks, unefficiencies or anything you would have cared for if you managed memory yourself.
