Go doesn’t need generics
I’m aware that this post could be somewhat controversial and should probably come with a pretty big disclaimer. So let me start by saying that if you don’t agree with me, that’s fine. Actually, I’d love to hear your arguments in the comments!
I’d also like to say that there are valid arguments being made by both sides — those who want Go to introduce generics — and those who don’t. This is my view on the topic, but I’m happy to be proven wrong.
Essentially I want to point people to this blog when discussing generics. I also realize there’s some irony in me taking this stance, as I maintain a library that pretty much adds generics to Go. But that’s a story for another post.
Experienced gophers don’t miss Generics
I mean.. there are experienced gophers whom also miss generics. The subheading feels a bit like a blanket statement… but it sounds better.. sorry! 🙊
From my experience, the ones who seem to miss generics the most are people whom are just learning Go. Especially the ones coming from a language like Java or C#. I know, as I was one of those. When I first started learning Go, at some point I wanted to create a Stack-like data structure, so my initial reaction was to try to create a ‘generic’ solution. Because I envisioned my ‘stack’ ’being used in a variety of cases (in reality, this did not happen).
After using Go for a couple of weeks I stopped missing generics though — and nowadays I rarely feel like I need them, even though I’m building rather large systems. This is a feeling that resonates with a lot of gophers I talk to at conferences, meetups or virtually. People start to see that Generics are not the “Go-way” of doing things and stop missing them.
Hence Go shouldn’t add something just to please the newcomers, not because their experience isn’t important, but because they change their opinion over time. Go should not just implement each feature they miss from Java or C#, or Go will just become another Java, and will lose its advantage of being different.
They add complexity
Go is a simple language. It’s intentionally simple. When you add generics to a language, it creates complexity for the compiler and for the user. Having worked in an environment where people went a bit crazy with generics (me included), I’ve seen the downside of generics. Things likeBuilder<A extends ObjectBuilder<B>> can become a nightmare to understand and maintain.
One comment I hear when mentioning this is that Go is mostly for ‘DevOps’ and not ‘Software Engineers’, and thus the programs are simpler and the developers less experienced engineers. This is silly, a lot of Go software engineers are writing large systems in Go and they’re not “bad engineers” or anything of the kind, just look at kubernetes or google themselves. Seeing value in simplicity does not make you a bad engineer. (Actually, if you believe complexity makes you a good engineer, try writing a webserver in brainf*ck).
Go shouldn’t conform to the mainstream
Go is not a mainstream language. I hope that one day it’ll be popular and widely used, but not if that means Go will just copy every feature mainstream languages use. Go should be differentiating itself, and not just implement something because others are doing so. In fact, we should remember why people switch away from these languages. And one factor is exactly the complexity they add to a project.
There could be valid reasons for stealing features or coming up with new ones, I’m not saying Go should be stubborn. But ‘Language X does it’ is not a valid reason in my opinion. Just look at Haskell, they don’t try to please the mainstream. Haskell is functional, lazy, and does things in its own way. It doesn’t resemble Java and doesn’t try to be more ‘Java-like’ to appeal to more people.
Similarly, Go should not try to ‘appeal’ to people coming from other languages just for the sake of it. Especially if these would turn out to be a vocal minority. Just give them a chance to learn Go the right way. And provide them with the necessary tools and material to do this.
You can’t take it back
Once you’ve implemented generics, there’s no way back. You’ll stick with it forever. You could risk the community having two versions of Go, one with and one without generics, by having forks. But in general, once it’s implemented, it’s there to stay.
As is often mentioned, the Go developers don’t think there’s a good way of doing generics at the moment. So at best you’ll end up with workable generics that are no worse than Java. Worst case, you end up with generics that people still dislike because they’re different than what they’re used. Which would be a lose-lose situation.
Anyway, these are my thoughts on the topic. But who knows, maybe Go will implement a great version of Generics with the ‘Contracts’ proposal. 😃
