Why do you feel that? From the Go FAQ, which now I feel obliged to at least read in its entirety because of how much heat this post has stirred:
"Why does Go not have generic types?
Generics may well be added at some point. We don't feel an urgency for them, although we understand some programmers do.
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 [functionality] mean in many cases it is possible to write code that does what generics would enable, if less smoothly.
This remains an open issue."
Clearly the designers of Go consider generics a topic worthy of debate.
But apparently you consider "no generics" a deal-breaker without seeing why generics haven't been added yet, and why it isn't an issue for the many developers writing real-world production Go code.
I'm confused. I never called it a deal-breaker, just a surprise. The language designers, in their FAQ, acknowledge it as an opinionated gap where their own opinion hasn't been fixed, so I'm not imagining it as a gap either.
Your comment about "real-world" code is even more puzzling, as if all "real-world" code is somehow equivalent in abstraction needs. There are guys who've written serious code running in billions of cellphones where generics would be unimportant. Same thing for scientific or massive data crunching applications, e.g. Google's infrastructure.
In the space I work in - enterprise applications integrating large, disparate systems where you have zero control over interfaces and data formats but somehow need to get everything talking together nicely, generics are invaluable in structuring your code and making it reusable.
To be fair, I happen to be building a little search engine of my own and Go may turn out to be great for building the crawler components (the processing is site-specific), and I may end up using it for that purpose if I have the time to explore it or see value in it (if I find memory pressure to be an issue then saving 1/3 RAM on my EC2 instances over C# is a definite win, but since most of the work is I/O constrained I may never run into an issue at all).
> In the space I work in - enterprise applications integrating large, disparate systems where you have zero control over interfaces and data formats but somehow need to get everything talking together nicely, generics are invaluable in structuring your code and making it reusable.
Luckily for you, Go already solves these problems incredibly naturally! Unfortunately, you haven't looked into how Go solves those problems, primarily through its interfaces and type embedding, plus its slices and so on are already generic.
It's true they aren't sure if they need it or not, but you clearly haven't looked into many feel they are unnecessary and that the present language is more than sufficient for solving many needs. In fact, Go is almost explicitly designed to handle the production cases you tackle. But it seems you've said in other threads that learning new approaches isn't really worth it for you, in which case, it's unsurprising that new languages aren't offering you much.
I'm not sure interfaces are really the "incredibly natural" solution. Why, for example, should a container care about what interface its contained element implements? A list is really agnostic of such things and forcing an interface on the item is silly, just to contain it.
