[erlang-questions] Erlang vs. Haskell

[Matthew Sackman]

On Mon, Jul 02, 2007 at 04:08:11PM -0500, David Mercer wrote:
> However, I was taken aback by the benchmark comparison
> (http://shootout.alioth.debian.org/gp4/benchmark.php?test=all
> <http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=ghc&lang2
> =hipe> &lang=ghc&lang2=hipe), which shows Haskell to perform every bit as
> well as Erlang.  Since Erlang and Haskell seem to have a lot in common, I am
> now wondering if I should instead teach myself Haskell.  Now, granted, this
> will be a biased group to ask, but I am curious as to what the Erlang
> community's take on Haskell's apparent performance superiority is.  It seems
> to me that Erlang as a language seems to fit very nicely into my needs, but
> given Haskell's similarity and superior performance, does anyone have any
> experience with both who could help me in my decision?

I have written a decent amount of high performance code in both Erlang
and Haskell. The main issue in Haskell is that the laziness hurts
performance and so in order to make it go really fast, you tend to end
up adding lots of "strictness" annotations (!) which controllably
destroy laziness. There are then further tricks that can be employed,
and a whole host of flags to pass to ghc and through to gcc in order to
make it go really fast.

Whilst this can mean you can out-perform C in some cases, it always
tends to result in very unidiomatic code. Until ghc 6.8 comes out with
its generalised loop fusion framework, high speed Haskell tends to mean
"do recursion directly" rather than map/fold as it will be detected and
optimised better.

Performance issues in Erlang seem to be utterly different. There seems
to be less of a concerted effort to use higher-order functions all over
the place, and you can get away with murder due to the lack of a static
type system. lists:flatten/1 for example, can not be expressed in
Haskell and so you end up having to think quite differently about any
given problem.

I'm sure others can offer other evidence, but to me, most opitisation
work in Erlang seems to be focussed around communication between
processes, ensuring bottlenecks don't occur and minimising queue lengths.
I'm comfortable in both, and would use both for different means. I would
say that Haskell probably is far more of an academic's playground than
Erlang is and has one of the finest type systems ever constructed by
man, but then again, I like static code analysis, and not everyone does.
I would suggest that you should learn both, and learn when to use each
one. Concurrency in Haskell is definitely more challenging than in
Erlang (regardless of whether you use Chan, MVar or TVar/STM to do
shared state), but purely algorithmic code and number crunching will
almost always be faster in Haskell. They're different tools, shaped for
different nails.

Matthew
-- 
Matthew Sackman
http://www.wellquite.org/