[YawningAngel]

I'll bite. I've read all the arguments the creators of golang made for not including generics. They are just as true now as they were when the language was created, and yet generics have now been added. Moreover, they have been added as part of golang 2.0, so any breaking changes that turned out to be needed could have been made now anyway. I think it's pretty reasonable to dislike a language that refuses to implement a basic feature for essentially no reason.

[geodel]

This seems rather clueless. The party line was they have not found a way to implement it in a way that satisfy their requirement. Now they have found a way to do so. So I see no contradiction. Also what breaking changes you are talking about I am not aware of any. Also there is no golang 2.0 yet.

[YawningAngel]

> The party line was they have not found a way to implement it in a way that satisfy their requirement. Now they have found a way to do so.

So far as I'm aware, every mainstream language, including golang, that's addressed this question has chosen to solve it by monomorphising generic functions. This implementation was well understood when golang was first released, and it isn't remotely plausible that the authors were not aware of it.

> Also what breaking changes you are talking about I am not aware of any. Also there is no golang 2.0 yet.

An argument given at the time was that committing to an implementation of generics would potentially put golang in an awkward position similar to Java's wherein if the implementation turned out to be bad, the language would be stuck with it anyway for backward compatibility reasons. I am simply pointing out that, since both golang 2 and generics have been discussed roughly contemporaneously (generics landing shortly, golang 2 having first been discussed in 2019 and therefore presumably to happen at some point soonish), any initial implementation of generics would not have particularly constrained what the golang team is now doing.

[uluyol]

It was a design goal that monomorphization should always be possible, but Go will not be monomorphizing generic functions to save on compile time / binary bloat (it will instead use GCShape stenciling, see below). I suspect future releases will be smarter and monomorphize some functions for performance, but that's really up to the Go team.

Initial implementation strategies considered for generics: https://github.com/golang/proposal/blob/master/design/generi... https://github.com/golang/proposal/blob/master/design/generi... https://github.com/golang/proposal/blob/master/design/generi...

[philosopher1234]

There will be no Go 2 with breaking changes, it is just a marketing term for go with generics. I'm not fully clued in on the technical challenges with generics, but frankly you don't seem to be either. I know that there has been much ink spilled on the go-nuts mailing list and the issue tracker, as well as 3+ prior attempts at implementing generics, so I don't think it's fair to dismiss the go team's concerns out of hand.

Also, even if you were right and the go team simply said one day "we wont add generics lol" that would still be a very shallow reason to dislike the language. After all, that is only one of many aspects of the language, with a specific set of tradeoffs. The rest of the language can hold great value even if it doesn't look like the Hacker News Approved Language.