I suppose if you're writing a Triple-A video game or real-time/firmware? (neither of which are "server")
Outside of those cases, Rob Pike has given some discussion on interior pointers and how it's possible to limit the amount of garbage generated:
http://talks.golang.org/2012/splash.article#TOC_14.
(along with the usual techniques, like object pools, used with good success in JavaScript and Android games).
This is incorrect. I've written a bunch of ARM firmware in Go and I've seen server applications that use custom allocators for allocation sensitive code.
"Ultimately, though, it sounds like you want a language which has no garbage collection, and Go is not that language. Language constructs will allocate memory in ways that are not immediately obvious, so there is no reasonable way for a Go program to completely manage its own memory."
Of course you can write memory pools and free lists—you can write them in any language—but, like other languages, the GC will still trace them during mark time and there is no safety provided by the language if you return an object to the pool that's still in use, or leak objects by forgetting to reuse them, and so on.
The fact is that programming in Go, for all practical purposes, requires using a garbage collector.
When you manually allocate memory you are naturally responsible for the lifecycle of that memory. In Go you allocate such memory outside the GC to avoid tracing.
The issue, as Ian pointed out, is that it's hard to pinpoint when GC allocations occur. Language constructs allocate in ways that are not immediately obvious.
Do you write kernels? No? Then shut the fuck up with your GC FUD. Lisp somehow managed to get past that and become the golden child of HN; will it take 50 years and pg's blessing before people stop whining about this in every Go thread?
That is why it fails as a replacement for C like it was originally marketed to be. But fits nicely as a replacement for python. People can start getting concurrency, limited type safety, and reasonable performance without having to really learn anything. The switch from python to go is pretty much trivial.
Outside of those cases, Rob Pike has given some discussion on interior pointers and how it's possible to limit the amount of garbage generated: http://talks.golang.org/2012/splash.article#TOC_14. (along with the usual techniques, like object pools, used with good success in JavaScript and Android games).