Outside of the famous builtin process model/BEAM (plus the subsequent ‘crash first’ style design of programs which adds resiliency) the pattern matching is what makes Erlang one of the best languages and the one thing I wish every new language copied.
You kinda get it in Haskell and Rust with the maybe style pattern matching. Rust in particular makes good use of it.
But it’s one thing I miss the most not writing Erlang/Elixir for a living... so far. It makes functions and data handling into these clean trees instead of conditionals (not to start a language flamewar but boo Golangs conditional obsession which seems to be the polar opposite in many ways for error handling, or at least it used to be I haven’t tried it recently).
There’s a lot to like and learn from in Erlang. Static typing will give it wider adoption IMO. And I’m happy to see so many developers working on it.
They are not equivalent, as Erlang/Elixir uses structural typing whereas Haskell/ML uses nominal typing.
In Erlang you can define the following:
equal(X, X) -> true;
equal(_, _) -> false.
In Haskell, the following does not compile:
equal x x = True
equal _ _ = False
instead, we need to write something like
equal x y | x == y = True
| otherwise = False
A subtle difference, but in some cases the structural semantics really do make patterns a lot cleaner (shorter without sacrificing readability).
I think that this style of pattern-matching semantics is a consequence of Erlang's roots in Prolog, which works similarly (and not only checks for structural equivalence but even does unification when necessary).
Comments
Outside of the famous builtin process model/BEAM (plus the subsequent ‘crash first’ style design of programs which adds resiliency) the pattern matching is what makes Erlang one of the best languages and the one thing I wish every new language copied.
You kinda get it in Haskell and Rust with the maybe style pattern matching. Rust in particular makes good use of it.
But it’s one thing I miss the most not writing Erlang/Elixir for a living... so far. It makes functions and data handling into these clean trees instead of conditionals (not to start a language flamewar but boo Golangs conditional obsession which seems to be the polar opposite in many ways for error handling, or at least it used to be I haven’t tried it recently).
There’s a lot to like and learn from in Erlang. Static typing will give it wider adoption IMO. And I’m happy to see so many developers working on it.
What’s special about Erlang pattern matching? Haskell and ML are at least equivalent.
They are not equivalent, as Erlang/Elixir uses structural typing whereas Haskell/ML uses nominal typing.
In Erlang you can define the following:
In Haskell, the following does not compile: instead, we need to write something like A subtle difference, but in some cases the structural semantics really do make patterns a lot cleaner (shorter without sacrificing readability). I think that this style of pattern-matching semantics is a consequence of Erlang's roots in Prolog, which works similarly (and not only checks for structural equivalence but even does unification when necessary).