I think the "we're working on it, but it's going to take a lot of time before we get something good enough" current position is the perfect middleground.
My understanding not just from the FAQ but also from reading conversation in the forums, was that they thought the feature itself had such a high potential of being misused as a crutch for bad designs that they thought not having generics was actually a feature.
And to be honest i almost agree 100% with that perception. The problem is that it leads to archaism and copy pasting that make a few lines of codes here and there look just gross (although perfectly understandable).
Plus, history has taught us that retrofitting generics to existing languages with their ecosystems can be difficult and painful (see Java and to some extend C++).
But out of curiosity what's difficult/painful about C++'s "retrofitted" generics (templates)? There's a lot to not like about templates, but as far as I know they've remained relatively unchanged and have always been just as difficult and painful (and powerful) as they are now. Are you referring to the decision to make SFINAE a de-facto way to constrain parameters?
I believe that C# also had retrofitted generics, but the reputation there doesn't seem nearly as bad. But I believe the generic containers there were intentionally not compatible with the original non-generic version.
Having used both I would take the CLR implementation any day.
https://mattwarren.org/2018/03/02/How-generics-were-added-to...
i usually see monsters when you combine generics with objects and inheritence, but you're right that since go also doesn't provide those...
i think when talking about generics in go we also mean struct accepting generic components. Not just functions
It would be very tempting with proper generic support to try to have every function work with the topmost types, just because we assume it provides more type safety. I could imagine a struct representing a "User" byte array, or other atrocities.
For the longest time the answer about generics was "There are no plans for generics. I said we're going to leave the language; we're done"
And the people who have been advocating for generics understand that have downsides. That trade of different forms and placement of complexity (the lack of generics creates complex code in duplicate code for write arounds).
It's just that they've been convinced that generics are justified. And they have concrete proposed solutions under evaluation.
[1] https://github.com/golang/proposal/blob/master/go2-language-...
I wonder if anybody’s actually changed their mind on this, or whether the opinion of the Go team has shifted simply because it’s made up of different people now.
"Generics may well be added at some point. We don't feel an urgency for them [...] we continue to think about it. [...] The topic remains open."
These sentences have been in the FAQ since Go 1.0. Maybe people should start to believe them.
They have gathered experience with the current language, their generics design drafts have improved over the years, and now they feel like they have something that might fit.
From this blog post[1] from last year from the core Go team:
We’ve been thinking about generics since work on Go began, and we wrote and rejected our first concrete design in 2010. We wrote and rejected three more designs by the end of 2013. Four abandoned experiments, but not failed experiments, We learned from them, like we learned from check and try. Each time, we learned that the path to Go 2 is not in that exact direction, and we noticed other directions that might be interesting to explore. But by 2013 we had decided that we needed to focus on other concerns, so we put the entire topic aside for a few years.
Last year we started exploring and experimenting again, and we presented a new design, based on the idea of a contract, at Gophercon last summer. We’ve continued to experiment and simplify, and we’ve been working with programming language theory experts to understand the design better.
Overall, I am hopeful that we’re headed in a good direction