Imagine if the Go team listened all those that want Generics in Go. It would be more consistent and closer to perfect language.
As it is, it's a PITA 20% of the time.
(Sure, some say they use it and don't feel a need of generics. Most do however, and it's a constant in every review, even by people using it for core infrastructure).
Data structures usually,
If you want to write a linkedhashmap or a dictionary where the keys are autogenerated from the values or any kind of structure not built into the language you are forced to either roll a new structure for each set of types or cast everything to and from (empty)interfaces.
While it's still possible with the casting, it doesn't feel as nice as the rest of the language does.
The other case seems to be any kind of generic pattern with channels, it's possible to build a channel-pair which acts as a single channel with a buffer only bounded by memory, but you can only do it for a single type.
All of these are avoidable or maybe even inadvisable, but it still feels like a hole in the language when you go to do something which is common, useful and trivial in C++/java/C# and you have to use ugly hacks or deal with heavily reduced functionality, especially when the rest of the language is so nice.
A log scanner that does some analytics, a intra-company web service, ported a few Python programs to evaluate the performance, etc.
Copy pasting data structure code to fix for different types feels (and is) bad. Anything involving non DRY code I consider a failure. (Oh, and working with numeric types).
Yes, because nobody both uses a language AND has a legitimate complain against it.
Well, I for one have both. As lots of people. And in fact, it's quite common. Anyone that used a language should be able to tell you several pain points about it. Except if he is in his idiotic "oh, this is so much better than the blub that I used to use, it's perfect" stage.
Have you even read TFA? The guy evaluated the language, done a project with it, and still wants generics.
Generics are convenient but they come at a cost in complexity in the type system and run-time. We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it. Meanwhile, Go's built-in maps and slices, plus the ability to use the empty interface to construct containers (with explicit unboxing) mean in many cases it is possible to write code that does what generics would enable, if less smoothly.
So instead of some--very limited, as languages like ML show--complexity in the type system, go punts these difficulties to the poor programmer who is then forced to constantly dynamically cast values, simultaneously adding clearly superfluous noise to the code and subverting any compile-time safety the type system offers.
Wow, they still mention that non-sense in the FAQ?
Let me guess, they also still link to that “OMG Generics are so hard” article where they conveniently manage to ignore the comments which point out the elephant in the room?
As it is, it's a PITA 20% of the time.
(Sure, some say they use it and don't feel a need of generics. Most do however, and it's a constant in every review, even by people using it for core infrastructure).