GTK 4.0

Linking GTK to Go is not a particularly good example. Though I haven't got any experience with integrating GTK and Go programs specifically, I am certain from doing so with other C libraries that the GObject object system is not to blame here.

Go and anything non-Go do not mix particularly well and the Go community's answer is "CGo is not Go", with the implied notion that we'd all be better off just reimplementing our C and C++ libraries in Go. Sure, Go's foreign function interface support can be used for easy things and there's even some documentation, but as soon as you want to do something nontrivial, possibly with callbacks into Go from C, your life gets interesting, and not in a good way. Once you are done fighting the garbage collector and the magic protecting it, the fun shifts to a build system that does not handle non-trivial cases such as (cross-compiling or figuring out custom search paths for headers and libraries) particularly well. You end up adding build scripts or Makefiles or lengthy instructions. If you expect others to use your Go library of C bindings (i.e. build it from source), explaining the non-standard build system or instructions then becomes a major source of entertainment.

Very little of this has anything to do with the Go runtime having a garbage collector.