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 like Builder<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. 😃
Latest comments (8)
Thanks for your thoughts. I agree Go doesn't need generics. I suspect when it adds them, I'll be forced to find a new language to love.
My biggest fear with generics in Go isn't the feature, per se, it's that they will be abused 99% of the time, leading to less readable, less maintainable code. That price is too high for the 1% of times when it will be a benefit.
Literally everyone I've ever seen ask for them (this comes mostly from SO posts, so it is a biased source) simply doesn't know what they're talking about, and can't be bothered to think creatively for a better solution.
The only time I ever wanted something like generics in Go was also when I was new to the language. I never need them now.
Tbh you should've had a section with code examples (go & java w generics)
Maybe, but the thing is that Go does not have them. So it'd just be an example of standard Java code and standard Go code that contributes little to the discussion. Apart from showing some Go / Java code to people who might not necessarily know these languages.
But I feel like Java generics are well-known and this post does target people whom are familiar with Go. 😄
Go shouldn’t conform to the mainstream,
Go conforms Google, thats why is Blocked on certain places like Cuba, Iraq, etc.
More importantly it wont have Hardened builds,
last time I checked it wont even PIE.
It wont need generics until it needs them.
Kinda, the political issue is not something I want to get into here, because I don't feel I can adequately comment on that 😅
Brainfuck doesn't have a complex architecture or libraries (like C#). It's just hard to develop with because of the syntax. So, that's a different kind of complexity :)
Yeah that's a fair point. It'd be complex nonetheless though! :)
The challenge is that complexity exists. Where does the complexity live, in libraries? The language? The tool chain?
he-the-great.livejournal.com/49072...
It is not that Go needs x, but we don't code in MIPS and that is a very simple language.
On the specifics of generics, you utilize Java and C# as examples of languages people are just used to having generics. It took Java 10 years to add generics. And C# had a quick follow up in v2. So Go is positioned well to follow these languages.
I'm not sold on generics either. I'm sold on static typing and static meta programing.