The nice thing about the Go GC is, it runs completely in parallel to your program, so that there are no significant GC pauses any more (typically far below the millisecond range, rather microseconds).
Broadly, yes, Go's GC is quite fast and unobtrusive. They've done a good job tuning it for many purposes. On the post's programs though it's quite possible it doesn't come into play at all, as the compiler keeps things on the stack when possible.
But like all GCs, there are cases where it has issues. Anecdotally, I've seen multiple cases where "ballast"[1] reduced RPC response times by around 25%. A bit of GC tuning on some tests sped them up by over 10x (due to pathological thrashing - each test would go from just-below the GC threshold to just-over). Etc. Granted, it's usually on not-great code, but the point still stands - if you care about performance, GC cannot be ignored, regardless of how good its marketing is.
Ada with the Ravenscar profile enabled is a good choice for such scenarios. Together with a real-time operating system it allows you to satisfy hard real-time guarantees. As you certainly know, though, hard real-time constraints require hardware validation.
Yea, for a lot of requirements hard realtime isn't necessary and at least some older linux systems can be tuned to remove almost all jitter giving very good 99.9th percentile figures. I've even seen it done with zero alloc java
