Why Generics in Go?
Ian Lance Taylor (via Hacker News):
If we can write generic types, we can define new data structures, like these, that have the same type-checking advantages as [the built-in] slices and maps: the compiler can statically type-check the types of the values that they hold, and the values can be stored as themselves, not as interface types.
It should also be possible to take algorithms like the ones mentioned earlier and apply them to generic data structures.
[…]
Most importantly, Go today is a simple language. Go programs are usually clear and easy to understand. A major part of our long process of exploring this space has been trying to understand how to add generics while preserving that clarity and simplicity. We need to find mechanisms that fit well into the existing language, without turning it into something quite different.
[…]
We are working on actual implementations to allow us to experiment with this design. It’s important to be able to try out the design in practice, to make sure that we can write the kinds of programs we want to write.
1 Comment RSS · Twitter
I've been saddened for a very long time that, although many members of the Go team are aware that theory people often have a lot of things to say to engineers, Go's creators are almost willfully ignoring what the PL theory people have to say. By contrast, Rust was created by engineers who really spent a lot of time listening to PL theorists, and the result is that the language is really, really good.
Go's major advantage is that it's not as terrible as many competitors like Java, but this is not the same as saying it is actually good.
What the Go folks call "generics" are what PL people call "polymorphism". A version of Go that handled ad hoc and parametric polymorphism (which are quite distinct), and handled it with a conscious attention to the stuff the type theory people know, would be a better language, but instead they keep looking at reinventing the square wheel.
