Earlier quoted context omitted.
Yes, because one can either turn off the GC, allocate memory up front (arena style), or call C or Assembly from Go. The performance is likely to be good enough with GC turned on, though, because it is unusually fast.
Turning off the GC isn't the blocker. Plenty of GC languages manage. I'm more interested in how Go handles graphics APIs and binding a render thread or working with GUI threads considering how goroutines are done. Does one need to write non-idiomatic go, avoiding goroutines or is there some trick? For example, GTK isn't thread safe so you can't just use that library without considering that.
Go is great for image/draw and things like passing pixels: (C.uint)buffer.Pix
It comes down to Google wanting Go to use the web as the interface, which in practice means not doing dynamic linking (except in Windows.)
To your question, go gui apps will have 'runtime.LockOsThread()' near the start so it's all green/light/go threads and only 1 OS thread.