Benchmarking and profiling are both built into the language, which is pretty nice. But you’re right, Go is designed for safety over control. High performance Go comes down to avoiding allocations; there’s not too much else you can do at the language level.
Not sure if you can even control GCs that well some times. In Java I've worked on projects that never GC once they reach a steady state. I'm not sure I could do the same in Go, or maybe the techniques are just more involved or different?
The technique is basically to preallocate your structs and reuse them via *sync.Pool, never allocate on a hot path. I don't know about "never" GC but it at least minimizes GC, and the pauses are very short.
