synth-ruiner So, as a long time Go developer, I think most of the flack it gets is either a misunderstanding or no longer valid.
Error handling in Go is explicit because the alternative is Exceptions which tend to encourage passing an error on to upper layers in a non-obvious way, when often the problem can be handled immediately and better in the context of where it was first encountered. Coming from years of Java and C++ development, Exceptions are much harder to reason about and can be maddening to track down the source without good tooling.
Package management in Go was largely solved with the introduction of Go Modules. Before that, the biggest problem was many competing solutions that were cumbersome and problematic when crossing from one project to another. Most Go projects have standardized on modules now which has been a godsend for the rest of us. The only real complexity left there is multiple-versioning of modules with the same major version and that's just a matter of time.
Garbage collection hasn't been a problem in Go for a really long time. Most garbage collection happens asynchronously and the stop-the-world pauses are sub-millisecond in most cases now. Nowhere near disruptive enough to cause problems. Let's also realize that C++ used to be garbage collected and that Java still is, both having no problems at all handling GUI without freezing things.
George As far as Fyne itself is concerned I think it's a decent start at a Go toolkit, but I'm not really fond of its insistence on following Material Design principles. That tends to lead to UI which have too much space where they don't need it and not enough space where they do. I also think there's a tendency to not have enough contrast between colors which is bad for accessibility.
