[erlang-questions] suitability of erlang

[Ulf Wiger]

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 [1], 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. ;-)

BR,
Ulf W

[1] http://hackage.haskell.org/package/distributed-process

On 10 Oct 2012, at 18:06, Rustom Mody wrote:

> On Wed, Oct 10, 2012 at 3:45 PM, Matthias Lang <matthias@REDACTED> 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".
> 
> Matt
> 
> 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.
> http://ghcmutterings.wordpress.com/2009/10/06/parallelism-concurrency/
> is a haskell implementers view of the terminology
> I wonder where erlang fits in on this
> 
> Rusi
> 
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions

Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.
http://feuerlabs.com



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20121010/511fb801/attachment.htm>