And right off the bat, the first thing a person notices is that there are two identical sub-libraries, mgl32 and mgl64, to work around the language's constraint that the core numeric type in the library cannot be parameterized at the language level without performance-losing reflection.
... oh. There's three. The one in mgl64, the one in mgl32, and the canonical one that a developer should edit to make changes. And they only all stay synchronized if the developer remembers to follow the contributor practice and run that gen script, which is not enforced by anything.
On a small project like this, not a big deal. But it's indicative of the over-arching problem of the approach go is necessitating here. There's noise here that a developer has to think around, and as a project scales up, that noise is going to become louder and trend towards intractable complexity.
I think Go is great, but I don't think describing parts of it as less expressive than some other languages is banal.
Expressiveness has a sweet spot, though. Too many keywords and constructs makes a language harder to learn, and makes it too easy for developers to build their own little weird worlds that discourages team work and lowers readability.