3 ms·

Is it me or is this substantially uglier than the C version?

• robbrown451 10y ago
  I would expect it would be, for a barebones GUI program. Now make a real program, where 90% of the logic isn't specifically UI stuff, and the benefits of doing it in Go makes more sense.
• f2f 10y ago
  every beginning is hard, but at least it doesn't deal with resolving DLL procedure addresses by hand, which it would've had to do if syscall.NewLazyDLL wasn't available. after a while things will settle down and this "hello world" program will boil down to something much simpler, like: import "win" func PopWin(text string) { win.NewWindow(text, ...) } also keep in mind that this is the version that purposely avoids using C and, as a consequence, can be cross compiled for windows on every machine with Go installed. there are benefits to that.
• tomjen3 10y ago
  It is, but that is because it has to refer it directly and import a lot of stuff you get for free in C, when you import windows.h I don't think it would be that ugly if you compared it C code that didn't include windows.h
• lloeki 10y ago
  This kind of thing is bound to get better as it gets wrapped in with a more idiomatic interface. Things like https://github.com/go-gl/gl https://github.com/go-gl/gl started as ugly hacks requiring passing unsafe pointers and stuff around but have made great strides since then. I don't know the details and I'm thinking aloud right now, but the comments about "windows.h", constants, and accessing C via cgo possibly point to an automatically generated solution (possibly leveraging "go generate"). Whatever, native GUI bindings has been a key factor for the adoption (or lack thereof) of some languages where they would have otherwise been perfectly fine.