Generics, I would certainly be ecstatic for if it was done in a way that is novel and feels Go-like, so not Java or C# or C++'s implementations. This has certainly been the stance of the Go team since the beginning of time. It has never been "anti-generics" it's always been "we've studied all the generics implementations out there, and didn't feel like any one of them were good enough, so rather than shoehorn them in, we are being patient." This approach needs to be celebrated more.Exceptions, OTOH, I hope never see the light of day in Go. Curse them.
jjice|5 years ago
alharith|5 years ago
From the Golang FAQ:
> 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
Quote from Russ Cox:
> The generic dilemma is this: do you want slow programmers, slow compilers and bloated binaries, or slow execution times?
Finally, one of the reasons the C++ or Java approach has never been palatable to Go core devs is summarized from this Rob Pike quote from his famous "Less is Exponentially More" blog post:
> If C++ and Java are about type hierarchies and the taxonomy of types, Go is about composition
So therefore it really is also a matter of finding a generics approach that lives up to that spirit as well. Contracts I think are approaching that.
All that said, user defined generics (since technically speaking, Go has many generic capabilities today already) are coming to Go, they just aren't being rushed. I think we will be happy with the generics implementation in Go within the next year.