Great talk. I work a lot with type classes in scala when using spire, and getting different typeclass instances for the same type is giving me nightmares.
1:35:12 Another reason why Ord really benefits from being a type class is when you want to use the data with a Map. It is necessary for the correctness that every operation on a map uses the same ordering. Now, we could put the ordering function inside the Map, but now every Map will carry around an extra function and we are still not safe, since the union operation requires that the ordering operation is the same for both Maps, which is impossible to verify, since we can't compare functions for equality I'm not entirely sure how ML modules and the other options in the design space solves this problem. For the proof assistants, you could require an equality proof to use those functions, but that also feels very unsatisfactory.
My favorite video on type classes. Also, for some reason the ConstraintKinds extension had never clicked for me, before watching this video. Kmett is awesome.
Thanks for explaining your idea of “true” type classes. I had seen the occasional post from you where you mentioned it, and I had no idea why you had that opinion (other than “maybe it's something about category theory” ;-) ).
Rust's coherence rules are actually stricter than Haskell's. They don't even allow orphan instances in places they might be reasonable non library code. Traits can be passed at runtime, like a v table, but each type can only ever have one instance of a trait. As far as I can tell Rust's traits meet the criteria for type classes. In the future specialization may become a thing, but even then there can only be one canonical instance for a fully applied type.
