It sounds like two types of concurrency are being confused. The one type,
which was promoted by Backus as one of the great benefits of functional
programming, is when the compiler or run-time system determines which
aspects of a program are parallel and handles them as such, presumably
handing each one to a separater processor. If you don't have side effects,
then this isn't terribly difficult to do. Maybe not worth it, but still
In Erlang, though, the concurrency is more like what you see in a
multithreaded OS. If you want to run an application, you spawn a task. If
you want to run fifty of the same applications, you spawn fifty tasks. But
all fifty of those tasks need to interact with common resources at various
points, so you need a way to deal with it. Most OSes use some form of
resource locking, whereas Erlang uses a message passing scheme.
It is tempting to convince oneself that everything in programming is messy
and should be handled at a higher level, but that's not so easy to do in
Allow me to introduce myself. My name is Chris Pressey and I'm one of
the active members of the so-called 'esoteric programming' community,
which experiments with computer languages in a non-industrial,
non-academic setting. See http://www.catseye.mb.ca/ for more
I'm somewhat new to Erlang (only written a couple of programs), and new
to this list, but I thought I might chip in my two cents from a
'language design' perspective...
James Hague wrote:
> It sounds like two types of concurrency are being confused. [...]
It's not really concurrency that's the issue - Perl, Erlang, and Haskell
are all concurrent. It's the amount of abstraction between the
programmer and the concurrency.
In Perl, concurrency comes with a very low level of abstraction. The
programmer must explicitly choose to 'fork', or whatever else is
appropriate for whatever system the program happens to be runnning on.
The programmer has total control & responsibility. This might be
convenient for hacking, but it's awkward for writing portable, stable
In Haskell (as I understand it,) concurrency comes with an extremely
high level of abstraction. The programmer has little control or
reponsibility over when and how it happens. This might be convenient
for mathematicians and logicians who have "more important" things to
worry about, but it just gets in the way when writing production code
which must meet certain demands.
I've been attracted to Erlang recently because it's like the bowl of
porridge that is "just right" in that story about that blonde girl and
the three bears. Concurrency is neither intractably concrete like in
Perl, nor intractably abstract like Haskell. It is instead at a very
comfortable abstraction level, with a nice thin interface (essentially
just spawn/send/receive) which makes it easy to be productive while
writing concurrent code.
Also it's probably important to remember that while the main drive to
add concurrency to most programming languages is to allow more efficient
algorithms to be written in them... the concurrency model in Erlang is
actually for simulating real-world concurrency in a natural way. This
difference in philosophy is probably what helps make the abstraction
level for concurrency in Erlang so comfortable.