This is true, its not a processing powerhouse but for concurrent applications, Erlang is a clear choice. You don't have to do anything special to gain multiple core support.
Even with cpu-intensive number crunching, I would rather write an erlang linked-in driver in C and use Erlang's concurrency model to run the code rather than write multi-core enabled map/reduce type things in C. (ewwww)
> for concurrent applications, Erlang is a clear choice.
No it's not. Not necessarily.
Concurrency is a means to an end, not a goal. Erlang is great for problems which lend themselves well to modeling with a large number of communicating processes. A parallelizable number-crunching task is not such a problem.
By the way, just to be clear, by "number crunching" I mean something like rendering CGI.
> Even with cpu-intensive number crunching, I would rather write an erlang linked-in driver in C and use Erlang's concurrency model to run the code rather than write multi-core enabled map/reduce type things in C. (ewwww)
Concurrency in the Erlang VM will not magically translate into concurrency in your driver. By default only one emulator thread at a time is allowed to execute code in the driver.
You can override that, and then probably have to deal with a lot of synchronization and locking issues in the driver. Why bother?
Most number-crunching software out there is written in C, C++ or Fortran -- probably for a good reason (I have no experience in this area). There are many libraries, frameworks and tools to help you with parallelizing things (e.g. OpenMP). Erlang is simply not a good choice for this sort of software.
Too many people focus on how Erlang is well-suited for multicore systems. Forget multicore. It's neat, but the real awesomeness of Erlang is in distribution and fault-tolerance, not parallelization.
Even with cpu-intensive number crunching, I would rather write an erlang linked-in driver in C and use Erlang's concurrency model to run the code rather than write multi-core enabled map/reduce type things in C. (ewwww)