Eight Myths of Erlang Performance

I'm no expert but obviously you could code some specific program to perform superwell given unlimited amounts of time.

So the question is, given X amount of time to create a program, which runs faster? Not, given unlimited amounts of time, which is faster?

So tests like this don't necessarily reflect the real world.

That said, I don't really know which way it is, JAVA or Erlang, just sayin... :)

Sure. So it's easier to make programs that scale well. However, given sufficiently low-level primitives, you can completely emulate the Erlang model, with problem-specific extra hacks to help performance.

No, it's not as easy. It's possible to make it perform much better, though, through micro-optimization of the specific operations needed.

It's similar to doing a problem in assembly. On the macro level, it takes far less effort to make a performant system in a high level language, however for simple algorithms that are commonly used, you can typically get a threefold speed improvement by doing them in assembly, for a significant increase in implementation effort.

Wow, I never thought I'd compare Java to assembly.

No!

The Erlang pitch is "Distributed, reliable, soft real-time concurrent systems".

Distributed supervised processes are a mechanism to achieve error containment and fault tolerance.

"making reliable systems in the presence of software errors" (pdf) http://www.sics.se/~joe/thesis/armstrong_thesis_2003.pdf

Chapter 20, "Programming Multicore CPUs", in Joe Armstrong's book, he says "If you want your application to run faster on a multicore CPU, you'll have to make sure that it has lots of processes, that the processes don't interfere with each other, and that you have no sequential bottlenecks in you program."