No mention of goroutines or concurrency in the post. Is it addressed by the project at all? I can't imagine that the GTK main loop will deal well with being cooperatively scheduled -- the UI would block any time another goroutine ran on the same OS thread.
Ideally the GTK main loop would run in its own OS thread, and there would need to be a way to ensure that no GTK calls happen in other goroutines. Other (threaded) environments tend to handle this by deferring via a one-off "idle" function that is scheduled and run by the GTK main loop for things like that.
We do try to deal with concurrency and goroutines as much as we can. I'd recommend taking a look at the (rather simple) goroutine example as part of the gtk package. Unfortunately though, as you said, GTK is not thread safe (calling GTK from multiple threads was deprecated as of the last release I believe) and calls must be made using glib.IdleAdd() to run the functions in GTK's main loop context.
Ideally the GTK main loop would run in its own OS thread, and there would need to be a way to ensure that no GTK calls happen in other goroutines. Other (threaded) environments tend to handle this by deferring via a one-off "idle" function that is scheduled and run by the GTK main loop for things like that.