polymorphism is very good, but not handcuffed to OOP.
Clojure protocols, Haskell typeclasses (and many other examples I'm sure) provide the same functionality "a la carte" without the rest of OOP's features coming along for the ride (to paraphrase Rich Hickey and Stuart Halloway). More eloquently explained details in this talk at around the 21 min mark [0].
One big missing feature in typeclasses is overriding. You can't "call into super."
A concrete example: you make a new type in Haskell, and you derive Show so it can be printed. But the default output isn't quite right - you want to add something to it. In an OO language you might "call into super" and append to the string. But in Haskell this isn't possible: you either get the default implementation, or you do it all from scratch.
More generally, typeclass default implementations are a lame replacement for overriding, and existentials are anemic compared to dynamic binding. This pushes Haskell interfaces towards rigid, static designs. That's fine if that's what you want, but let's not pretend it's equivalent in power to OO polymorphism.
that sounds a lot like sharing code by inheritance as opposed to composition. which is unrelated to dispatching by the type of the first (or implicit) argument.
i personally would prefer to code to interfaces and keep hierarchy separate from behaviour
Clojure protocols, Haskell typeclasses (and many other examples I'm sure) provide the same functionality "a la carte" without the rest of OOP's features coming along for the ride (to paraphrase Rich Hickey and Stuart Halloway). More eloquently explained details in this talk at around the 21 min mark [0].
[0] https://www.youtube.com/watch?v=cidchWg74Y4