[badhombres]

I'm curious why there isn't a push for more support in desktop gui for Go.

Is it because desktop gui is not as supported in modern times and Go is a recent language that is carrying that attitude or is it because Go attracts more web developers in general and they already have web applications as their solution for a gui?

Maybe something else?

[ainar-g]

In my opinion, there may be two types of problems.

The first is organizational. Maintaining a cross-platform GUI library takes a lot of time, effort, and reasonable knowledge of the platforms it targets, so that would need a dedicated team of at least a few people. Which is not impossible, but you need to actually do this. The closest thing to such project seems to be Gio, but I haven't tried it, so I don't know if it's any good.

The second is technological. Most ways of interacting with (native) GUIs involve FFI, and in particular C. And cgo has known limitations and performance issues, to say nothing about the fact that using cgo make cross-compilation significantly harder. So a lot of Go projects tend to just avoid any project that involves cgo.

Again, that's just my opinion as a Go developer.

[throwaway894345]

I've looked into building cross-platform GUI toolkits before and I think you're underselling the difficulty pretty considerably. To build these toolkits, you need expertise in everything from graphics programming to text rendering (which itself is surprisingly pernicious: https://gankra.github.io/blah/text-hates-you/) to accessibility and more. And then there are things which are just "regular hard" like constraint solvers for layout engines, designing a decent API, etc.

[oxplot]

There seems to be a POC that attempts to load dynamically linked libraries on linux (and elsewhere on windows) without CGO: https://github.com/golang/go/issues/18296#issuecomment-46847...

[badhombres]

Valid points about FFI. That makes me think if Go devs cared enough about Desktop GUI, then they would try to make that weak point stronger. Their focus is elsewhere (networking, cli tools, web) which doesn't rely on FFI as much.

[mountainriver]

Eh a lot of people have, the issue is with Go’s memory model and how that maps to the C memory model. It requires what they call “trampolining” which caused a performance hit.

Interestingly, Rust originally used a similar memory model to Go, but then when they hit this problem decided to take another route.

This has the unfortunate side effect of making most machine learning also not practical in Go.

[throwaway894345]

On the other hand, it has had the fortunate side effect of minimizing the amount of code which depends on C, which makes building and packaging software (including cross compilation) super simple.

That said, I'd like to know more about the limitations regarding machine learning. Presumably most machine learning stuff isn't implemented in C?

[mountainriver]

The ML limitations are that all the low level vector and acceleration libraries are written in C or C++. The GPU libraries are the real kicker, there isn't any great way around this except to trampoline over to C, that trampolining takes time which chews into your acceleration. Ironically Python is much faster than Go for ML because of this.

[electroly]

PyTorch and TensorFlow are both primarily C++ codebases.

[usrbinbash]

IMO, it's because the primary use case for Go isn't GUI programming.

The language absolutely is a generalpurpose language, and making great GUI libs with it is certainly possible, as shown by Fyne (yes, I know it's still new, give it time).

That being said, most people using Go build server side code and frameworks with it, aka. things that live as daemons in some rack or in a docker swarm. If there is an front-end to these kinds of applications, it's usually web based.

[Thaxll]

One thing is probably that FFI in Go is not on the same level compared to other languages, so binding to existing in C/C++ is not that popular.