

Go-gl: Massive Overhaul - slimsag
https://docs.google.com/document/d/1zORKEEFPsJ5AujtPbtQYQquvAopuXb3whWud1sA7nAE/edit?usp=sharing

======
peterwaller
I started go-gl (the github organisation) with the intent of things never
breaking underfoot. I'm really proud of what other people in the community
have subsequently brought to the table over the last three years.

It was not a decision taken lightly and these changes had wide agreement from
all of the maintainers of the go-gl projects old and new. Sadly this big
change causes some temporary breakage for code in the wild (you just need to
change /go-gl/ to /go-gl-legacy/ in the import path), but it's for the benefit
of all future code. Hopefully it won't be necessary again for a long while.

------
zellyn
To save you the searching and reading, glfw is a lightweight cross-platform
library for opening windows, and getting input: opengl specifies only
rendering in framebuffers, so you need something else to open the windows and
get input.

------
tree_of_item
Is there any planned interaction between go-gl and
[https://github.com/golang/mobile/](https://github.com/golang/mobile/) ? The
Go developers seem to have written some useful OpenGL related libraries,
particularly
[http://godoc.org/golang.org/x/mobile/sprite](http://godoc.org/golang.org/x/mobile/sprite)
.

~~~
shurcooL
There is ongoing work, first we want to tackle golang.org/x/mobile/f32 and
github.com/go-gl/mathgl, after that we can start thinking about GL bindings.

There is an open CL about it, but it's moving along very very slowly. :(

------
rhodysurf
I understand the change from methods to functions to match OpenGL, but the old
bindings (go-gl/gl) were easy to use and much better than writing C. I just
dont see why I'd use Go over C for this now the syntax is pretty much exactly
the same.

