Ok so garbage collection is optional, how about garbage generation? Is there any way to manually clean up resources if GOCG=off, or will memory usage continue to grow unbounded as new objects are created?

Grows unbounded. I wasn't recommending that one should set GOGC=off. Just making a remark that one could should they choose to do so.

EDIT: Sorry, I misunderstood part of your question. The memory grows unbounded unless you call runtime.GC() which triggers garbage collection. But this is a blocking call and essentially block your whole program.

I think in theory you can write code (or do some tricks) to avoid all heap allocation.

You mean not growing the heap or literally no allocation?

"In theory" being the operative words there. Turn on heap escape analysis sometime, you'll be surprised how hard it is to avoid.

Only very theoretically - in Go, you don't control whether memory goes on your stack or the heap, and heap escape analysis is notoriously unpredictable. There is no explicit free. You would have to write Go in a completely crazy way to be able to turn off the GC and have the program not grow unbounded.

You might think "I'll just use static buffers everywhere", but allocations can occur in unexpected places. The compiler does some very basic lifetime analysis to eliminate some obvious cases (loops...), but it's really hard to avoid in general.

Well, then so is in Java, with the Epsillon “GC”. But not collecting garbage is very different than manual memory management.

Arguably, one can't truly say the GC is optional, unless the language and its libraries were truly designed to work without it. In languages like Vlang, that's the case, as the GC was a late addition. If turning the GC off cripples the functionality and usefulness of the language, then there is little point in using the option.

Probably a better argument for Go (and other languages like Java) is how "tweakable" the GC is or at least describe it as the GC can be turned off, but it's not designed or useful to do so.