nomadsoftware |
|
Generics in Go v2.0 It’s a no-brainer!
Recently there has been a lot of talk about adding Generics to the popular programming language Go. Not only do I think this is a good idea, I actually think it’s a complete no-brainer! Go has been maturing at a rapid rate over the last few years and the Go team have recently started asking for user experiences to influence Go’s future. In my humble opinion, they only need to focus on one thing. Can you guess what it is?
Go’s hype is real
I’ve written before about Go and how I was initially pretty unimpressed with the over simplicity and parenting that is forced upon you. However, over time I’ve come to enjoy using Go to the point that every new project I tackle, Go is the first language I consider. In my opinion, it’s unsurpassed for cross-platform support, tooling and libraries. The language itself is simple and straightforward and the concurrency support is second to none. It really is an absolute joy to create concurrent programs in such a simple, robust way. I, like many people, just enjoy using Go. So what’s the problem?
Its problem is a lack of reusability
This is the elephant in the room, or as some have described it, the ‘N’ word of Go. Generics are a feature that solves real world problems which Go literally can’t cope with. These problems that are nigh on impossible to solve without resorting to bypassing type system or using reflection hacks, both of which are highly discouraged.
These are currently impossible to do with Go in any sane way
- Create reusable abstract data types
- Create reusable algorithms (for comparison, iteration, mutation, searching and sorting)
- Implement reusable interfaces (for ranges or iterators)
- Create any non-trivial abstraction
The list goes on but the startling common thread running through this list is reusability. Why is Go so adverse to reusability or to writing libraries? I know Rob Pike likes to espouse “A little copying is better than a little dependency.” but the copying is getting out of control and whats more, this is a solved problem.
Even the Go team has suffered from the lack of reusability making difficult decisions to add new built-in functions to the language because of the lack of library friendly generics.
I’m not really opposed to a builtin append function but I want to make the obvious comment that, like copy, this is a function we are only considering because we don’t have generics. – Ian Lance Taylor 1
Generics will solve this
You don’t need user experience reports to clearly see the problems people are facing using Go. You just have to open any Go discussion on the internet. This is a bigger problem than experience reports will show because people simply use another language if they have to implement the above list. Generics are the missing part of the puzzle to make Go a world class, leading language. Adding this for Go v2.0 is the right thing to do.