Go with generics will continue to be useful, and it'll make it easier to build some things that were irritating to build earlier.
The design of generics went though so many rounds of iteration and discussions to make sure it wasn't a detriment to the language - indeed you can build everything that Go has already been used to build without ever knowing about or using generics.
Generics coming into a 1.x release also means that any code written under 1.x is expected to continue working perfectly, generics or not.
The process has made sure no damage will be done, and we now have a new toolkit to make solving some problems easier. I don't think anyone is trying to gaslight anyone by using generics.
And of course in addition to that, there will probably be claims that "no one claimed that generics aren't needed". I'm glad that we have the archives to show that this isn't true, and it's a good thing to keep in mind when opinions are being pushed on HN.
Please remember that this is a forum of a very big group of participants with varying points of view and resulting opinions.
Even if he was previously a person that said golang doesnt need generics, I struggle with your point of view. It seems you're of the opinion that nobody should be allowed to... change their opinion? Or at least has to be continuously told that they're dumb because they held an opinion that turned out to be incorrect? We're all people and make mistakes/have incorrect assumptions about topics, why not just accept that and move on?
You might want to refocus on what kind of person you want to be, because both of your comments come off as very hostile
Similarly, a charitable interpretation of what kubb wrote would be that they are referring to those who might have been dishonest in their defense of Go's lack of generics, which one might say kubb does indicate by using words like apologetes and zealots. The Internet is full of people who pick a team and will say dishonest things in perceived defense of it. I agree with kubb in this regard. That is the charitable interpretation of what kubb wrote, but instead you assumed kubb referred to everyone who ever voiced that opinion and suggested kubb should refocus on what kind of person they want to be.
The Internet needs more of charitable interpretations, and HN in particular. Perhaps I failed to interpret you charitably now? Nuances get lost easily in online debates... :)
Moreover, using terms like “zealot” to refer to people with whom one disagrees is very likely to inflame the thread (as indeed it already has, to a degree), whatever kubb’s intention.
It is not a "pivot" for someone to say, "X isn't necessary", and then say, "X still isn't necessary but at least it's implementation doesn't break things".
However some people, which are referred here as "apologetes and zealots", claimed that you don't need generics and that they were a bad thing, which is a very different thing and not the opinion of the Go team.
The conclusion here is that these people were wrong, just like the ones that said that it was impossible to do anything serious without generics. While those people were busy arguing with other people on the net, the Go team and community were slowly but surely refining their ideas on generics and how to make them fit into Go.
True, but not as disappointing as the attitude of the go language creators and maintainers.
I'm pretty sure none of the Go language creators or maintainers has a negative attitude towards generics.
Surely you don't mean the Go team, which has had this in the language FAQ since 2009 [1]:
Why does Go not have generic types?
Generics may well come at some point. We don't feel an urgency for them, although we understand some programmers do.
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.
[1] https://github.com/golang/go/commit/dd64f86e0874804d0ec5b713...