[angusgr]

Yes! Also, even when you do care about performance, general performance isn't ever the same as specific performance.

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.

[igouy]

> general performance isn't ever the same as specific performance

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

[angusgr]

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.

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.