[erlang-questions] suitability of erlang
Wed Oct 10 18:47:54 CEST 2012
Simon Marlow is a very smart guy, and knows what he's talking about.
Erlang doesn't really target the domain of parallelism, but to some
extent, you can roll your own. Your mileage will depend in part
on how heavy your jobs are, and there are some other interesting
differences between the Haskell approach and Erlang's approach.
- While you can do something similar to Erlang-style concurrency
in Haskell, to a certain extent this has been a research area.
Nowadays, you can play with Cloud Haskell , which closely
mimicks Erlang's semantics (well, actually a proposed semantics
for 'future Erlang'). Not least exception handling has long been
a tricky issue to figure out, due to Haskell's strict type system.
- Haskell's main focus so far (I believe) has been what Simon calls
deterministic parallelism. There is quite some promise that
Haskell's type system will keep you sane when trying this style
of programming, whereas in Erlang, you tend to end up treating
it as an explicit coordination problem - quite doable, and better
than in most other languages, but more error-prone than it
could be in Haskell.
- Erlang's origin is telecoms, where systems are supposed to
serve and evolve for many years in the field. This makes it
important to support code evolution - given telecom uptime
requirements, notably code evolution in a _running system_.
Erlang's support for in-service code change is difficult to
reconcile with a strict static type system, and I believe this
feature is also absent from Cloud Haskell (at least I don't
see it mentioned). If you're building server systems, this is
a feature to die for.
- Haskell is a superb research language, and it has seen some
success in commercial settings, but primarily in areas where it
has been possible to maintain a very high skill level across the
board in the design teams (I'm speculating here; I haven't
actually verified it). Erlang, in contrast, has been picked up by
companies across the globe and used in commercial products
pretty much after self-study and experimentation. You might
say (although (the) Simon(s) might flog me for this), that Erlang
is quite easy to get into, whereas Haskell becomes easy once
you've finished your PhD in Functional Programming. :)
- So basically, some of the smartest programmers in the world
choose Haskell as their weapon, and much of the cutting-edge
programming language research today is done in Haskell.
Erlang is a great craftsman's tool for building robust distributed
systems, with many of the niceties of Haskell, but much less of
the academic rigour. When deep in the trenches, this is not
always a bad thing. ;-)
On 10 Oct 2012, at 18:06, Rustom Mody wrote:
> On Wed, Oct 10, 2012 at 3:45 PM, Matthias Lang <> wrote:
> On Wednesday, October 10, Rustom Mody wrote:
> Another thing: you write "under severe time-crunch", but that could
> mean "we need to ship a product in a very short time" or it could mean
> "the data has to be processed in a very short time".
> Well mainly the latter
> But the former is also true. (When is it ever not :-))
> My concern is that there is some desire to try out erlang which may be fine... However I am wondering whether the difference between concurrency and parallelism has not been appreciated.
> is a haskell implementers view of the terminology
> I wonder where erlang fits in on this
> erlang-questions mailing list
Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions