alt Hacker NewsAfter my adventures with different languages I'm on the hill that Rust traits, Haskells typeclasses, (sic!) Go's interfaces, etc. are state-of-art features in modern programming languages.
It's not like they're without the footguns - they have plenty. But even with those footguns typeclasses (as I'd rather call them) are complexity escape hatches.
E.g. at some point your type can have dozen of different implementations and you can decide to ignore that fact completely while proceeding to work on your (very narrow) piece of pie ignoring vastness of universe[^0] you found yourself in.
That being said multiple inheritance fits the same category and with minimal squinting same features can be found in languages such as Clojure or Elixir.
As other commenters mentione this is not a secret by any means, as composition over inheritance advice is decades old, but IMO still worth repeating because there might be someone who doesn't know it yet :)
[^0]: By universe I mean code implementional universe, not The Universe
Replies
I don't see what go's interfaces have to do with the first two. It's just structural typing, isn't it?
I really miss explicit support for type classes in languages that I use regularly like Python.
Yes I agree with you. The pattern is "composition" vs "inheritance". Defining a "thing" as "what it can do" instead of "what it is". Instead of saying that "a duck is a Bird which in turn is an Animal which in turn is a LivingThing" (Duck -> Bird -> Animal -> LivingThing) you focus on what a duck can do: a duck "quacks, swims, etc":
I think there's still a place for "inheritance" based approach for APIs that need to be very strict about subtyping: would be hard to express covariance/invariance/contravariance without it.