„go can’t be taken seriously because it doesn’t have generics” has been a mantra for years before they finally arrived. there must have been a ton of them.
That does not mean that generics were somehow forced in against the wishes of the Go Team. Their position has always been that they just need to find a good design.
And everybody else laughed at the notion that there's a lack of good design for generics, given that all other mainstream languages have had them for literally decades, with many different takes to choose from.
Given that Go eventually ended up with a very mundane take on generics, in retrospect, it is not at all clear what precluded this same design from being adopted from the get go rather than dragging their feet on it.
> And everybody else laughed at the notion that there's a lack of good design for generics, given that all other mainstream languages have had them for literally decades, with many different takes to choose from.
Yes, but they weren't good; half of the Java spec and implementations has to deal with its implementation of generics, and the author of Java's generics (Martin Odersky) then moved on to create the even more complicated Scala language. I have this comment [0] and its linked "Java generics FAQ" [1] that is exemplary of its complexity bookmarked for this very occasion.
They ended up with a mundane take on generics because they dragged their feet on it. It's like that quote, "I would have written a shorter letter, but did not have the time." If generics were added without waiting for enough demand, use cases and consideration, it would have ended up weighing them (spec, language, compiler, runtime, etc) down for decades to come. Remember that Go is in it for the long haul.
Java is one example out of many, and even in that case the limitations of their generics are largely caused by the desire for backwards compatibility, and it's a well-understood tradeoff.
Go ended up with a mundane take on generics because that is consistent with the design philosophy of the language as a whole. My point is that their mundane take on generics was already well-known and well-understood long before Go itself was even a thing, never mind all the rhetoric about "we don't have generics because we don't know how to do them well". If they ended up with some kind of novel arrangement that avoided complexity issues etc present in other generic type system, I would buy that argument. But when they ended up with the design that was there all along, it doesn't really add up.
