Eh, you can achieve the same in Rust using rayon, this isn't exclusive to Haskell or FP. Do you have an example in Haskell, where you get an effortless speedup which wouldn't be easy in another language?
> let colors = fmap computeColor coordinates
to
> let colors = fmap computeColor coordinates `using` parListChunk 32 rseq
So half a line added to parallelize the mapping a pure computation including using a sensible threadpool implementation. How impressive you find this depends on how you define "easy in another language". Rayon comes pretty close but you can encode some properties about your computation in the Haskell type system that Rust does not yet support and so the safety of some computations can be statically proven in Haskell but not in Rust.
var colours = coordinates.stream().map(this::computeColour).collect(toList());
var colours = coordinates.stream().parallel().map(this::computeColour).collect(toList());
I also think that explicit threadpool isn't the same thing as implicit one. But that's very minor issue here easily solvable by different api for parallel method
However, the things mentioned: algebraic data types, type inference, pattern matching could also easily be seen as influences from Haskell or FP languages in general.
At the end of the day though, it's not like this matters. I'm just happy that such flow of ideas happens, irrespective of where exactly each particular concept comes from.
How could you have not mentioned OCaml? The original Rust compiler was implemented in it. By this, Rust has a very clear (OCa)ML heritage.
It's meaningless to argue, whether Rust got ADTs from Haskell or OCaml, because the author (Graydon Hoare) had been clearly familiar with both and both got ADTs from ML, which is much older than either of them.
On the other hand, traits are a different story, those just Type classes with a different name, and that is a Haskell thing.
And to wit the only mentions I read about Haskell as an influence were a) the trait system, and b) to criticize and explicitly refute the Haskell approach to a given problem. There was a reason Graydon wrote the compiler on OCaml and not Haskell. He was very critical of a lot of the ideas that Haskell brought. In particular, he hated how Haskell took mutability from "not the default" to "practically impossible". He hated the effect system and how overly intrusive it was (although he was open to the idea of a fine grained effect system that was not tied to some all powerful Monad typeclass). He hated lazy evaluation. He hated the syntax...even the convention toward snake-case vs camel-case is an homage to OCaml. He didn't even care much for typeclasses, preferring the more strict encapsulation of modules, and only bringing them in after a lot of contributors pushed for them.
Basically, apart from typeclasses (which werent really unique to Haskell, as they had been known as interfaces within OOP for a few years), Graydon viewed Haskell quite a bit like an old atheistic refrain about religion: that which is good about it is not unique, and that which is unique about it is not good.
BTW, Rust's ADTs as well as Haskell's ADT's came from ML. They've been around since 1973, 13 year before Miranda, and 17 years before Haskell's first release. You don't get to claim that Rust got it's ADTs from Haskell any more than you get to say that Java got it's Optionals from Scala.
EDIT: see this comment from Graydon himself, made about a year ago on the rust subreddit:
> That said: back then Rust was much more OCaml-y. We did not start with traits / typeclasses; we started with modules (for a while: first-class, though quite badly broken due to my lack of knowhow). I was and am unapologetically more of an OCaml fan than a Haskell fan. This opinion is not made from a lack of information about either, and I am not especially interested in having a Haskell-vs-OCaml argument here. I don't even think of them as being especially different languages from a family-lineage perspective. But insofar as I think eager is a better default evaluation strategy than lazy, and modules are a better abstraction mechanism than typeclasses, I am more in the OCaml camp. Other folks later in Rust's development argued for (and eventually won) the typeclasses / traits thing, against my earlier preferences.
1. Do you know what were the main arguments for and against using typeclasses vs modules for abstraction? It's interesting to read that traits wound up in the language against Graydon's preferences.
2. There's another commenter on this thread suggesting that 'Typeclasses are just OOP interfaces' who has gotten a bit downvoted. To me they seem kind of the same thing, yet at the same time there's this feeling that I'm overlooking something and typeclasses are likely 'so much more powerful'. I just can't figure out what that may be. So, are there any major differences between what interfaces are in OOP and what typeclasses/traits are?
The power of Haskell's type classes comes from two things:
* Implicit composition of instances: you can write `show [True, False]`, which will automatically/implicitly compose the `Show` instances of lists and booleans. With modules or interfaces, you'd have to build and use a "BoolListShow" manually.
* Higher-kinded types, to abstract over type constructors. This enables the use of abstractions like monads.
Rust only has the first of these two.
Scala uses OOP interfaces instead, but by augmenting them with both capabilities (implicit composition and higher-kinded types), it achieves the same expressiveness as Haskell.
Also, succinct expression of parallel algorithms isn't a particularly unique feature. Like half of the named algorithms in the C++ standard library can be parallelized by adding a single parameter.