Disclaimer

Please note that I have zero experience in Haskell, so these statements are all assumptions based on an afternoon of study. I will probably prove myself wrong pretty soon.

#Intro

This is a series of tweets that I consider interesting for future reference, so I decided to put them in a blog post:

@ToJans @ptomasroos And the 140-character summary is..?

— Graeme Foster (@GraemeF) September 5, 2013

Answer

Remark: I initially included the original tweets, but this was unreadable, so I now just show the lines; they are clickable to get the original tweet:

• Haskell sparks share state and are cheaper and more fine-grained then erlang processes who share nothing.
• Strong typing in Haskell allows the compiler to parallelize code, while Erlang is concurrent & soft-realtime.
• In Erlang, a process is "an atom", while in Haskell, a function call is…

Clarification: by “Atom”, I mean the smallest possible part that can be split on a single thread; in Erlang these are processes, in Haskell these are sparks (i.e. function calls.)

• So if you talk about a few processors, Erlang will be fast, but if you talk about 100s of processors, Haskell wins!
• OTOH Erlang has OTP with a huge amount of manyears in it, while the thing in Haskell is nowhere near as mature.
• The guess is that Erlang will win on the short term, but Haskell might actually win as proc count rises ^ in the future
• Erlang allows concurrency, but not parallelism on the function call level, only on the process level
• While this makes no difference with the current amount of cores, it might make a big difference with > n^2 cores!
• So Erlang allows you to run programs concurrently, but currently only Haskell can give you true parallelism
• The idea is retrofitting a type system - that probably would be required for implementing parallelism - is too hard.

Summary

In Erlang, the smallest parallelizable unit is a process, while in Haskell, a function call (aka spark) can be, because function calls can share immutable state over several processes, so it has the best of both worlds.

A big plus on the Erlang side of things however, is the “Let it crash approach”, and while the probability for bugs might be way lower due the type system, a bug might still occur, and that is actually one of the strengths of the Erlang/OTP system: it requires no defensive programming at all.

First consideration when writing an app: "How do I want this to crash?" - @duomark

— Tom Janssens (@ToJans) September 5, 2013

The educated guess is that, as the numbers of processors goes up, the requirement for having a language that offers true parallelism (like Haskell) might actually win…

So we still think that at this moment Erlang is the best choice, but in the future our bets would be on Haskell or similar tools.

Update

Looks like I have some more reading to do:

@ToJans @ErlangInfo @GraemeF @ptomasroos Haskell has so much more than sparks. Check out https://t.co/6cyqsLK7tb

— Bob Ippolito (@etrepum) September 5, 2013