As I said elsewhere, the main contribution of Haskell is the science of programming languages. Without Haskell, we would be stuck with "practical" or "pragmatic" languages like C or Java that do not care much about soundness. Haskell is the science to Rust's engineering, IMO.
I think part of it is that there aren't many functional programming languages with a standard specification, multiple implementations, lots of users, an active research community, and where results of research feed into the implementations and the standard.
Haskell ticks all these boxes.
SML has most of those things, except the last: it was effectively frozen in 2001. This is discussed in section 9.3 of the HOPL IV History of Standard ML https://dl.acm.org/doi/10.1145/3386336
OCaml lacks a standard and multiple implementations, and seems to me to be doing better than SML in the other areas.
Isn't GHC the only full implementation of Haskell 2010? I am not sure how much the multiple implementations matter when there is only one full implementation of the last specification, which itself lags 10 year behind the only implementation massively used.
Haskell certainly is not the pinnacle in language design.
IMHO it is the first successfully implemented research language, though. I think that Haskell is the first language that, at the same time, had substantial commercial and research applications[1]. As such, it showed that the CS of PL is indeed of practical relevance.
Rust on the other hand, mostly applies this scientific research. And successfully so. Hence I call it the "engineering" part.
[1] To a certain degree this is also true for Lisp and SML, of course. But I think SML fell out of fashion quite quickly both in academia and industry. Lisp is, well, lisp. People that start using it seldom search for another language afterwards.
If you were a Java/C/C# programmer in the 2000s, you missed out on:
* lambda abstractions
* Generics (prior to 2004)
* Higher-kinded Generics
* Primitives in Generic collections
* no nulls
* do-notation
* ML type system
* global, decidable type inference
* Pattern matching
* Functions as first-class objects
* Currying
* And most importantly *side-effect-free* functions
As a someone who picked up Haskell around 2010 as my first functional language, I liked what I saw, and I assumed that other functional languages were probably similar. My inner evangelist was all "You should use FP instead of Java, because lambdas are ergonomic", "You should use FP because nulls are bad", "You should use FP because functions are easier to test than methods".
Over the last decade I've realised that those statements aren't really truthful. Many functional languages allow null. Many functional languages won't enforce side-effect-free functions for you. So it was never really about FP, it was about Haskell. Anyway, that's how they got conflated in my mind.
SML has many of those features. Sure, Haskell popularized them, but it doesn't mean that computer scientists began studying these concepts only after Haskell became a thing
>> it feels really weird that now is fashionable to assert that Haskell === FP
When Googling "functional programming", you get back pages of definitions emphasising "pure functions", "no side-effects", "mathematical functions", "avoiding shared state", "referential transparency". So what Haskell provides is what the blogosphere has been labeling as "functional programming" for a decade. Those definitions could be wrong, but they're the definitions that are floating around out there.
Algebraic Data Types (sealed classes/sum types + records/product types), pattern matching, local type inference. Moreover, Substrate VM (part of Graal) will help you achieve faster startup time and lower runtime memory overhead since it will be AOT compiled to a standalone executable, something that OCaml does right now.
While I know you are correct chronologically, it is 2020 now I think ‘network effects’ have come to dominate this perception (that Haskell is the language that gives the basis for breaking away from “practical languages). I think Haskell’s presence in the group consciousness of CS-minded developers is, at this point, due to the comparatively large web presence and semi-PR done on its behalf. Simon Peyton Jones almost single handedly pumps Haskell (and I love him for it) more than anyone pushes ADA, SML, and Modula put together.
> Haskell is the science to Rust's engineering, IMO.
Wut? Rust doesn't have the purity and the capability to isolate side-effects that Haskell has. Rust is popular because of its ownership model that got into the mainstream. We still don't know what are the costs of it.
The only similarity between them is that both are statically typed, expression based languages (ex. Scala, Ruby, Wolfram, LISP) and moved the task of proving stuff from analysis tools to the programmer. But that doesn't mean that Haskell "is the science" behind anything. For what it's worth, Rust is closer to the ML (OCaml) family than Haskell, focusing on performance rather than purity. Though that is also debatable since it doesn't feature a GC and comes with zero-cost abstractions.
Rust has its very own merits. I'm eager to see how it will evolve and what hidden costs will be uncovered.
For me the biggest merit Rust brings into the table is that affine types got out of the research lab, and now everyone is looking at ways to balance GC with affine types in most mainstream languages.
You can express particular monads, but to have a Monad class/trait for all monads you need first class type constructors (also known as higher-kinded types), and that is not common even today.
SML has always let you abstract over type-constructors using modules, and it was always routine to do so. You can express monads abstractly in this way, and some people have (Ocaml, but the SML is the same modulo syntax):
But the sort of code you would write in Haskell gets very noisy without typeclasses, and it's just not an obviously good way to program in a language that's intended to be impure and strict.
