> Early in the rollout of Go I was told by someone that he could not imagine working in a language without generic types. As I have reported elsewhere, I found that an odd remark.
> ...[rant about 'inheritance' and 'subclassing' and 'hierarchies']...
> If C++ and Java are about type hierarchies and the taxonomy of types, Go is about composition.
How do you get all the way through designing a programming language without realizing how incredibly wrong-headed this is? "Inheritance hierarchies are bad", so... you exclude generics (which are compositional, and have nothing to do with inheritance), and only support subtyping polymorphism via 'interfaces' (ie. inheritance)? That is the exact opposite of his claimed principles!
(And then as a minor concession to programming usability, he adds generics anyway, but only for built in types (maps and arrays), so advanced data structures are still an exercise in void* wrangling.)
I was thinking exactly the same thing. I don't understand how you segue from generics to "too many types are bad" to "inheritance is bad". I totally agree with the last idea. Inheritance is not a great model for code and it quickly becomes unwieldy.
But that has nothing to do with having an expressive type system and generics.
We can look at Rust for an example. It's "OO model", such as it is, is fairly similar to Go's. You can define a thing that combines data and behavior. You can define traits/interfaces that objects can implement. You can use those trait/interface types in place of concrete types. But Rust also gives you generics, sum types, and pattern matching. IMO, that makes for much cleaner code than doing the equivalent in Go.
He acknowledges that parametric polymorphism is a good thing that Go is gonna get, but then repeats his ignorant view on types by conflating type theory with shitty OOP inheritance and class hierarchies.
because generics generally are unncessary. there is a very small subset of programs where they are useful if you have arrays and maps already available.
there was no need to rush an implementation of generics.
> ...[rant about 'inheritance' and 'subclassing' and 'hierarchies']...
> If C++ and Java are about type hierarchies and the taxonomy of types, Go is about composition.
How do you get all the way through designing a programming language without realizing how incredibly wrong-headed this is? "Inheritance hierarchies are bad", so... you exclude generics (which are compositional, and have nothing to do with inheritance), and only support subtyping polymorphism via 'interfaces' (ie. inheritance)? That is the exact opposite of his claimed principles!
(And then as a minor concession to programming usability, he adds generics anyway, but only for built in types (maps and arrays), so advanced data structures are still an exercise in void* wrangling.)