His claim as I understood it is that the fundamental building blocks should not be types (what something is), but functional capabilities (what something can do). Type abstractions are fundamentally hierarchical (from an abstraction to multiple concrete versions), whereas capabilities are fundamentally about composition (I can do A, B and C).
I don't think anyone is going to say that Haskell's type classes in any way fit the traditional notion of a type. It's more the exception that proves the rule in this case.
It is a very old saying from when "prove" meant what "test" means now. Exception is meant in the sense of exceptional, unusual. "The unusual event tests the heuristic."
It's actually a really simple thing that most people misunderstand (such as the parent). It means that if you only provide an exception, it implies a rule. For example, if you say:
Parking allowed 3pm-5pm
that implies that parking is not allowed at other times.
Pointing out how flexible Haskell's type system is just proves how inflexible type systems generally are. It doesn't really demonstrate that most type systems are useful.
If that's the case, he's doing it wrong. It's like the pot calling the kettle black.
He essentially argues that types are constraining on other languages based on types, where it is actually in Go that types CONSTRAIN your use of things.
Because obviously different things CAN be held in a container, and a container can hold different things -- but Go doesn't let you do that (except for the officially "blessed" containers).
It is Go that's concerned more about "what something is", in letting you work with it, than, say, Haskell.
