I really struggle with this too. I know a language can be great at what it does without generics, but it doesn't seem like Go is geared towards being that kind of language.
I appreciate how easy it is to write and how incredible the performance is, but I get tired of the style of code it forces you to write. I write a lot of code to reduce the amount of code I need to write. In Go, that's not really easy to go or necessarily a good idea because of the lack of generalization.
The problem with generics is that every programmer generalizes differently and thus there is a massive barrier/“learning curve” for anyone new picking up an arcane codebase that some clever developer cooked up.
Not saying someone can’t screw up codebases in go, but it’s just much harder to do and you usually see it right away by noticing abuse of interface{}.
I agree completely. I use very dumb generalizations in hopes of keeping them easy to follow. I’ve burned myself and team members with cleverness many times with good intentions. These days I’ve calmed down a little but still find generalizations handy on a regular basis. You’re absolutely right though and I see why they were left out. For a lot of people (including myself at a times) it’s probably best to prevent cleverness.
> I write a lot of code to reduce the amount of code I need to write. In Go, that's not really easy to go or necessarily a good idea because of the lack of generalization.
This is where one of those sayings come in; "Duplication is better than the wrong abstraction"
Generics is still a difficult one for me; I don't really miss it myself, but I can see some use cases for it. On the other hand, it makes the language + tooling a LOT more complicated.
But on the other other hand, it opens up possibilities to tackle other criticisms of the language - error handling and nil, which can be solved with Either and Option types found in other languages.
I appreciate how easy it is to write and how incredible the performance is, but I get tired of the style of code it forces you to write. I write a lot of code to reduce the amount of code I need to write. In Go, that's not really easy to go or necessarily a good idea because of the lack of generalization.