|Go Adopts Generics|
|Written by Mike James|
|Wednesday, 17 February 2021|
The most attractive thing about the youthful Go was that it was lean and left out all of the confusing things that other languages had. It has taken a long time, but finally Gophers have decided that generics are now part of the language.
Hard on the heels of the news that Python has adopted sophistication in the form of pattern matching, we now have the news that Go has finally settled on a way to incorporate generics. Right from the word go, pun intended and will be repeated, the major criticism of Go was that it lacked generics. Of course, many Go programmers didn't miss it and actively worked to make sure that it remained outside of the language. This was never going to happen as generics are so mainstream as to be part of the official dogma of modern languages.
It should be clear that in fact generics have nothing to do with the object idea. Generics are necessary only when you enforce strong typing and while strong typing may be part of most of the major languages, it isn't essential. When combined with objects and the type hierarchies that object are usually taken to impose, things get complicated and you can easily lose sight of what is going on. Go on the other hand isn't particularly object-oriented and doesn't impose a type hierarchy, but it is strongly typed. What this means is that it is difficult to write an algorithm that works with a range of types.
When you write an algorithm in a typed language you have to say what types it works with and some algorithms are so general that they work with any type. So, to make it possible to write these general algorithms, you have to find a way of defeating the strong typing - either that you you have to write a program for each type even though the programs are largely the same.
There are a few things to say about generics that don't often get said, and if they do they cause trouble since strong typing and generics are deep beliefs. The first is that there aren't very many truly generic algorithms because most algorithms assume some properties and methods. For example, the most obvious generic algorithm is sorting and even here you have to assume that there is some function that can be used to compare entities.
The simplest solution to generics is to not enforce strong typing and simply rely on tools to check that the entities do have the properties needed for the algorithm - not a popular solution. The second best is to simply use the top of the object hierarchy - assuming that the language has an object hierarchy - and rely on the substitution principle to allow the algorithm to work with all other derived types. This often fails because few languages have a completely consistent object hierarchy - they usually have primitive types that exist outside.
If you don't want to use either of these approaches then generics is your only option - allow the programmer to specify the types used in an algorithm as parameters. That is, just as you use parameters to make a function or a method work with different variables of a specified type, you can use type parameters to specify the variables and their types.
It sounds easy, but there are all sorts of problems. This is where things can become really complicated: how do you restrict the types that a generic routine can use? What about composite objects such as containers? Should the type parameters be compiler-time or run-time entities and so on...
These and similar reasons are why it has taken so long to reach consensus - that and the fact that that a significant minority of Gophers didn't want the language expanded at all...
So what type of generics have they settled on? The simplest way of explaining this is to quote the summary in the announcment:
I predict that any will be the most used type...
or email your comment to: email@example.com
|Last Updated ( Wednesday, 17 February 2021 )|