I still remember when lack of generics and other common stuff was one of their main selling points in the beginning.
I'm psyched to see generics arrive, but (I say this a lot) I write about as much Rust as I do Go these days, and there is definitely a cost to pervasive generics. I hope Go retains most of its original spirit, while at the same time making it easy for some people to write red-black trees or whatever.
I've had a similar experience with TypeScript, whose type system is so breezy and flexible that it encourages levels of genericism I've not seen anywhere else, for better or worse. I think as type systems stop being a limiting factor, it's important we learn to moderate our own tendency to abstract. Go's ethos so far has been to enforce moderation of complexity at a language level, so it will be interesting to see what happens when generics open part of that up.
I agree with this a lot. Relatedly, Go has this nice property that code tends to be pretty 'standard' regardless of who wrote it (facilitates reading and writing). I hope the additional expressiveness that comes with generics doesn't harm this 'standardization' property of the ecosystem.
> I've had a similar experience with TypeScript, whose type system is so breezy and flexible that it encourages levels of genericism I've not seen anywhere else, for better or worse
I wonder if this is a consequence of TypeScript's breezy generics or if it's because people are now adding types to the egregiously abstract things they were already doing in JS.
The lack of generics leads to occasional excesses in code generation (-cough- k8s/client-go -cough-) which can be even worse. I suspect that observing this in practice lead the Go core team to be more receptive to generics proposals.
I mostly write Go these days and haven't found many use cases where generics are needed but there are definitely cases where they would make the code nicer.
I'm not so certain that that's the case, but it is an interesting position nonetheless.
Pre-generic and post-generic codebases will likely play awkwardly together, with lots of boxing between generics and interface{}. Folks who prefer generics will start to wrap or recreate popular existing libraries in the generic style.
It'll be a constant drag on everything.
Of course I may be wrong and the community might embrace the proposal whole-heartedly. But I won't hold my breath. Dismissing generics has been a gopher shibboleth for years and years.
> Why does Go not have generic types?
> Generics may well be added 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.
> This remains an open issue.
https://web.archive.org/web/20091115211116/http://golang.org...