> Not quite the case (brew install glew glfw3 on OSX) Sure, for OS X and Linux distros. What about Windows? No external dependencies is better all around. > b

> Not quite the case (brew install glew glfw3 on OSX) Sure, for OS X and Linux distros. What about Windows? No external dependencies is better all around. > but the problem is more that it requires cgo at all. You'll always be using CGO to make C calls, which OpenGL is. > One or two years ago I tried to use a package (I can't remember the name of and I'm at work) which was pure go for GL bindings, generated from the OpenGL specs, but it lacked a few wrappings and boxings here and there, making some calls particularly ugly and really not trivial, so I fell back to go-gl/gl (which requires glew). You'd be talking about Glow, most likely. For which the document outlines, is replacing go-gl/gl. It's gotten a lot nicer and works much better. > Of course you still need to link with something (such as glfw) that pops up a window, but that's one thing less to achieve cross-compilation. BTW with recent Go it works fine when built as a dylib, it's just tougher to distribute (on OS X at least, due to stored paths). You don't have to deal _at all anymore_ after this change! =) The Go tool builds the C sources directly, as it would Go source files. No external library installation needed: it's included. > From a more general dependency management PoV, I'm a bit anxious about how this is handled though, as this sets an uneasy precedent. "Forcing" the change is unwelcome this way as it significantly breaks the compatibility promise. Short of solutions like semantic versioning dependency management systems, the Go community has been idiomatically handling such incompatibilities at the library name level (foo, foo2, foo3 or bar.v1, bar.v2, bar.v3, or straight up another name). When handling such situations I'd rather have deprecation warnings on the README and when calling the code, pointing people to the new location, but keeping my current code working. I promise you personally that we are fully aware of the issues and breaking backwards compatibility with this change. For that exact reason we've announced it loud and clear. Myself and many other people whom I consider very smart were involved in this decision, which was not taken lightly. We chose what we believe to be the best path: breaking compatibility today, for a future where we will likely never have to again. I enjoyed reading your thoughts, and I think this will do you a lot of good should you try using the packages again =)