[yariv]

"People tend to think of Common Lisp style hotpatching where you can dynamically build up your application from scratch without restarting the CL environment. Erlang doesn't really support that, but you can hack it to give you somewhat of the same."

I (almost) never restart my Erlang server, and that lets me develop just as you described. Why do you say it's not supported?

(Btw, it really sucks to go back and use languages that don't have hot code swapping. Developing in them feels terribly slow.)

Fast: if you put is_float() guards on your function definitions, Erlang will optimize their computation. If you worry about memory consumption of strings, use binaries.

"Note that the language was originally built for concurrency rather than parallel computation." I don't follow this argument. Isn't the point of concurrency to implement parallelism?

[jlouis]

I am not too sure that an is_float() guard will yield a performance increase in the BEAM interpreter. It will give an increase with HiPE though I am sure. As per strings and memory consumption: Yes, you can use binaries or even better: iolists, but I think, then, that the string type has to go. A good (immutable) string library based upon binaries in OTP would be nice.

Concurrency and parallelism: No, they are not the same. A concurrent problem is one where you want to cope with concurrent activities: web servers, phone switch exchanges, routers, etc. A parallel problem is one where you worry about how to split the problem across multiple CPUs/Nodes so that you utilize as many resources as possible while achieving the best speedup possible.

The latter is usually number crunching on big clusters of several hundred machines -- or number crunching on a grid of computers loosely spread all over the world. The first is about coming up with a nice model for computation that makes you model the problem in a logical and straightforward way.

Erlang has a very nice concurrency-model. Together with the rock-solid and stable VM you have a very good outset for solving concurrent problems. But -- you can implement concurrency well on a single CPU, the key point is that you have a nice model in which to work when trying to explain the problem to the computer.

In a parallel problem, it is crucial how you split the problem up. Some problems have subproblems independent of each other. These are called 'embarrassingly parallel' problems. All of these are map-reducible. But how about a problem which is not? Numerical solving of differential equations via successive over-relaxation is a classical problem because each subpart needs to communicate its findings to neighboring subparts. You are worrying about the speedup when adding more CPUs or by Gustafsson: keeping the time-frame constant and adding more CPUs - how much bigger a problem you can solve.

Erlang, being about 30 times slower than C on numerical computation, needs at least 30 times the speedup to compete. Depending on the problem, that can be achieved with, say 32 CPUs, or perhaps not at all (if the problem has no inherent parallelism), where the C program only uses a single CPU. That is the gap Erlang is currently competing with. If you take the de-facto standard, MPI, and use that on C, you pay a lot of development time for a message passing interface which even allow for asynchronous messaging (crucial for hiding the latency of computation).

I hope this makes the difference clear.