I’m surprised the fact that they manage to keep the language small and minimal isn’t mentionned as a huge success. To me that is the number one reason to use this language : it forces you to not be distracted by language constructs (there aren’t enough for that), and focus on what is it exactly you’re trying to build. Even as an educationnal tool, this is excellent. Maybe they don’t realize it because they come from C, but when you come from more recent languages that include everything and the kitchen sin, this is a godsend.
It’s now to the point that whenever i develop a feature in a language, i ask myself « how would i do that in go » to ensure i don’t go fancy with the type system for no good reasons.
in my personal experience, go language "limitations" have always forced me to clarify and simplify my design. In the end, my code is way better than in my original intent.
I had to write seven or eight identical functions transforming some data because Go didn't have generics. Hardly a "better code".
They've now released generics, thankfully, but there are many places where there's unnecessary repetition and clunkiness because the authors "know better".
you couldn't make those data conform to an interface and have the algorithm work on the interface ?
in those scenarios i usually either work with interfaces, or composition (struct embedding), or as a final resort to codegen for things like generating bindings to database tables. the codegen is usually quite a good solution and makes debugging the generated code very straightforward, since it's all there, in the _generated folder, instead of in a temporary file generated by the compiler. it also makes the generator code a separate project, which IMHO is a better solution than using all kinds of macro and complex meta programmation directly in the final project.
It’s now to the point that whenever i develop a feature in a language, i ask myself « how would i do that in go » to ensure i don’t go fancy with the type system for no good reasons.