5 ms·

Implementing a 3D vector or quaternion library in Go feels like a really bad fit, mainly due to the lack of operator overloading (which can easily be abused, li

Implementing a 3D vector or quaternion library in Go feels like a really bad fit, mainly due to the lack of operator overloading (which can easily be abused, like >> in C++). But it is an example of a field where Go allows programmer to express their ideas in a less direct way. 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.

fixermark 8y ago
That exists, so we can look at at least one concrete attempt to evaluate the question. [https://github.com/go-gl/mathgl https://github.com/go-gl/mathgl]. 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.
- jeremejevs 8y ago
  mgl64 is generated from mgl32 though [0], so no big deal, no? Who's hurt by this? [0] https://github.com/go-gl/mathgl#contributing https://github.com/go-gl/mathgl#contributing
  - fixermark 8y ago
    Well, let me just do a quick text-based search for the Vec3 implementation and... ... 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.

fixermark 8y ago

That exists, so we can look at at least one concrete attempt to evaluate the question. [https://github.com/go-gl/mathgl https://github.com/go-gl/mathgl]. 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.

jeremejevs 8y ago
mgl64 is generated from mgl32 though [0], so no big deal, no? Who's hurt by this? [0] https://github.com/go-gl/mathgl#contributing https://github.com/go-gl/mathgl#contributing
- fixermark 8y ago
  Well, let me just do a quick text-based search for the Vec3 implementation and... ... 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.