Notes on the Go2 Generics Draft

Kudos also to prior art, such as the ML family of languages, which Rust derived inspiration from :)

I'm glad I'm not the only one sad to see generics invading a perfectly good language.

Programmers love generics because they enable higher-order abstractions, and programmers love abstractions -- code that isn't DRY is like an itch we need to scratch. Programmers also hate special cases, because they feel restrictive and inconsistent: I recall quite a few people protesting that Go's 'range' keyword shouldn't be restricted to a handful of built-in types, but rather should support any type implementing an Iterator interface.

But Go was not designed to be perfectly consistent or to enable high-order abstractions. It just aims to be productive at scale, and that often means restricting the programmer. Go tries to be non-magical, and sadly that can take much of the whimsy out of programming. You can't chain together operators in point-free style, or add a property to every 'Object', or directly increment a string, or anything like that. In other words, it's a terrible language for code golfing. But that sort of code has no place in a production environment anyway. It's "clever" code that gives the programmer a little dopamine hit when he writes it, and his co-workers a headache three months later. Those are misaligned incentives.

So I worry about generics because they let you abstract with wild abandon. They let you inject a little magic. And I fear that programmers will be seduced by their love of magic, and I'll be the one who ends up paying the price.

In a static language, functions, classes, and types are often parametrized by other types.

For example, with a function: imagine you wrote a `sum(array)` function. In Ruby that's not a problem, because array can contain any types, as long as they support the + operator (aka duck typing). Any function can also return any type of object.

In a static language, however, an array that holds floats has a different type than an array that holds integers or an array that holds strings. The return value of the function sum() will also be different, depending on the type of the array, because if it's an array of floats, the sum will be a float.

So generics allow you to sort of implement duck-typing in static language:

T sum(array) // Pseudocode

Now the sum function will take an array of any type T, and return a result of the same type T.

Similar idea for classes and other types. The classic example is a container. A linked-list in Ruby can contain any type or mixture a types, since the language is fully dynamic. However, in a static language, a linked-list of strings has a different type than a linked-list of ints. So you write something like (pseudocode):

class List { T head_val() { return head.val; } }

Now you write the List class once, and use it for any type T, so it's DRY when you may have any number of types T that your program stores in a list.

Consider this function signature:

func SomeAdditionFunction(arg1 int, arg2 int) { fmt.Println("Sum:", arg1 + arg2) }

This function will only accept a pair of integers. In order to perform addition on floats or int64s or any other number type, you would need a separate function.

Go has the concept of an empty interface (interface{}) which can accept any type. But this is not really a generic because you have to assert that it is a specific type in order to be sure what it actually is at runtime. This function for example, will not compile:

func SomeAdditionFunction(arg1 interface{}, arg2 interface{}) { fmt.Println("Sum:", arg1 + arg2) }

But this will:

func SomeAdditionFunction(arg1 interface{}, arg2 interface{}) { fmt.Println("Sum:", arg1.(int)+arg2.(int)) }

In a language like Java, I could write this function to accept any type for which the + operator is valid, and it would still be type safe at compile time. I would not need to assert the types like I did above.

It's impossible to defend the lack of generics in golang in the face of the fact that two of the larger open source projects both invented their own generics implementations.

https://medium.com/@arschles/go-experience-report-generics-i...

https://github.com/google/gvisor/blob/master/tools/go_generi...