You have to optimise to your use case, not some arbitrary general use case like "render a Mandelbrot set" or "calculate pi". If I have a slow On^2 Erlang algorithm, then I'm a lot better off looking at ways to rewrite it as Olog(n) instead of scrapping Erlang and moving to Java because it had a better score on the programming language shootout.

http://shootout.alioth.debian.org/dont-jump-to-conclusions.p...

> scrapping Erlang and moving to Java

"Most (all?) large systems developed using Erlang make heavy use of C for low-level code, leaving Erlang to manage the parts which tend to be complex in other languages, like controlling systems spread across several machines and implementing complex protocol logic."

http://www.erlang.org/faq/introduction.html#id49850

I know, when programming in Erlang I have unsurprisingly done exactly this. If I had an On^2 solution in Erlang that I knew I couldn't rewrite in Erlang to be faster, then that's my last resort - I'd write a C port to perform my particular inner loop performance-limited code, and leave the rest in Erlang.

However, I wouldn't either (a) go directly to C without trying to optimise the solution in Erlang first, or (b) look at a list of other languages and wonder which one I could move my entire program to.