I’d love to see comparison between Rust and Haskell/ML WRT polymorphism. I wonder if “gets right” would appear there and on what side.
Trait objects are basically existential types, with a few more restrictions on them. But in essence polymorphism in Haskell and Rust are very similar.
The big thing Rust is missing is higher kinded polymorphism, ie the ability to abstract over type constructors. This makes it easy, for example, to abstract over a container type while putting different things in that container.
This has get approved in the Associated Type Constructors RFC, but it's still in the works for actually landing.
Whilst this is obviously useful, it makes it impossible to perform parametricity type-based reasonbig.
Also, I'm not sure why you would ever want a "partial instance," as it would mean that your program could be unsafe but still typecheck (I haven't checked out Rust's implementation or motivation). Just use more specific classes, and you can even use a "generic" "instances of the components imply an instance of the whole" class and instance.
Newtypes also exist in Rust but this is an alternative that is not the same as the overlapping instances extension.
You can either have overloading classes or you can have your classes declaration independent of the type declarations. You can not have both.
http://science.raphael.poss.name/rust-for-functional-program...
Although Rust heavily borrows from the ML family, the fact it has mutability and imperative reasoning makes it hard to compare them.
But if you want a short one:
- Sum Types EDIT: AND Product Types (silly me)
- function-objects & closures
- typeclasses (as far as I can tell), but no higher kinded types
- no monads, functors nor monoids built-in
- trait objects (eg. runtime polymorphism, think "abstract classes")
Maybe I'm missing something, but aren't tuples and structs/records examples of product types? Which both rust and haskell have?
Rust most certainly has them, as does Haskell. Records/structs of course are just the same thing with names for the components.
Thus, even Java has product types.
Even C has product types. Which is why I'm always bothered when people claim language X lacks algebraic data types.
They probably lack sum types, but are very unlikely to lack product types.
That makes no sense. Algebraic data types are not expressed, they're a concrete thing, a classification of composite types (by multiplication (hence product types) or addition (hence sum types)).
Some shitty languages don't have a concise way for you to express particular things (like sum types), so you have to rely on idioms or "patterns".
{ 1 = "hi", 2 = "howdy" };
val it = ("hi","howdy") : string * stringI don't think Rust is that much different from other functional languages. The main critical difference is the manual memory management feature - the way it's acknowledged and used throughout the language and the ecosystem means that the functional patterns commonly used in garbage collected languages don't look nearly as natural in Rust.