> One of Rust’s biggest and best features is its trait system inspired by Haskell’s type classes. It is the right abstraction for most use cases that in 1990 were implemented by OOP and inheritance. Now the basics of type classes were invented by Wadler in 1988, but certain more advanced features (type families) were only invented in 2005. You mention OCaml but that’s only a small part of Rust’s type system.

I submit that those advanced features are at most a tiny fraction of why projects like OP are seeing benefits from moving to Rust. E.g. I wouldn't be at all surprised if this Rust on Android project isn't using type families at all, or is using them only in an incidental way that could be replaced without significantly compromising the benefits.

Any Rust code longer than ~20 lines uses Rust iterators which use type families. The Iterator trait in Rust has an associated type called Item. This is the innovation here. Classic type classes can only contain functions not types. It was in 2005 that a paper was written to show how having a type inside a type class makes sense, including how it can be type checked (via entailment of type class predicates with type equality), type inferred (by changing the standard HM system to return partial type equality constraints in addition to substitutions).

Now if Rust did not have such language features maybe it would have implemented iterators very differently. Current Rust iterators are similar to Java iterators, and in Java, iterators themselves have a type parameter, rather than having an associated type inside the iterator trait.

Are associated types type families? I'm not sure. They seem more similar to functional dependencies to me. But I'm only familiar with type families from Haskell so maybe I'm missing some broader context.

Yes they are type synonym families. And yes they are quite similar to functional dependencies because it is conceived as an alternative to functional dependencies but it expresses the programmer’s intent more clearly.

> Classic type classes can only contain functions not types...

> Now if Rust did not have such language features maybe it would have implemented iterators very differently. Current Rust iterators are similar to Java iterators, and in Java, iterators themselves have a type parameter, rather than having an associated type inside the iterator trait.

True, although I'm not sure how much difference it makes in a language with first-class modules. But more importantly, how much difference does it make at the point of use? As far as I can see the overwhelming majority of Rust iterator code looks pretty much the same as one would write in OCaml, or Java.

All of the memory safety stuff is independent of the trait system, to the best of my knowledge, but the data race protection is implemented through the Send and Sync traits. I'm unsure if there is an obvious alternative approach to this same feature, but I think it may be one innovation that is still novel to Rust and would not have existed in earlier decades.