There's a fair amount of implicit allocation in Go. When you reference a slice, you create a slice descriptor, which takes up space. Maps, channels, and goroutines all allocate. It's not impossible to avoid allocation in a block of code, but it's not just avoiding explicit allocation.

How do interrupts work in this system? Do they map to goroutines, or what?

The thing is, this allocation is usually on the stack. With a bit of experience, it is relatively easy to write your program such that all these allocations are on the stack. The compiler also gives you a clear breakdown on which objects are allocated on the heap. It is one big advantage of Go vs. Java for example, that you do get much better control about the allocation. All Go types are "value types", so this creates much more control and less memory pressure. (Except for interfaces, they are great when you need dynamic typing, but they behave more like reference types and do some unavoidable heap allocation, so avoid them in code parts which must not allocate from the heap.)

No, it's really not. How do you allocate a data structure on the stack and then call a function passing a pointer to it at a polymorphic call site in Go? (A polymorphic call site is one in which the compiler cannot statically tell which function is being called.)

Yes, it is possible. The Go GC is written in the Go subset that can be compiled without heap allocation. The compiler even has a switch for this, which turns any heap allocation into a compile error. This is a subset of all possible Go programs, but still a very useful one.

What is the compiler switch?

Sorry, I don't know and haven't been able to locate it in the help for the build tool, but it was mentioned in a talk about the GC, especially about it being written in Go itself.

Interfaces allow polymorphic coding, and they support stack allocated data structures last I checked.

I didn't say you couldn't make polymorphic calls in Go. I said that they don't mix well with relying on escape analysis to avoid tracing GC.

Oh I see what you mean. Yeah forcing vars to actually be stack allocated can be challenging when using interfaces everywhere. What are the Go authors' opinions on improving escape analysis?

I think it's a design issue that can't be truly solved, period. You could try stuff like k-CFA I guess.

What is k-CFA ?

Ah neat, thanks.