Hacker News Reader

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.

View on HN

No, go is not for native gui apps. I recently made some rough go bindings to minifb and while easy to do, it wasn't productive at all. Errors are hard to follow; are they go or minifb? Callbacks work until I have too many calls then the app might freeze altogether.

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.

Offhand, I think the general pattern is to bind related external libraries (E.G. a gui stack) into one agent thread and use channels to send it messages.

Reply on news.ycombinator.com