You are correct in saying that some languages are simply given as winners.
Erlang is a VERY impressive language from a performance standpoint. That said, it really needs to be used in conjunction with some front end UI language to present the results of all of its processing. Make no mistake about it, if one has so much data that one will need say 32 cores to process it, then a clever presentation layer is a must. Another drawback here is that, for those Erlang programmers who are something other than elite, Erlang will handle all of the locking and synchronization on its own. I think experienced senior programmers see where that one is going. That said, the way Erlang implements concurrency is cool. I like simple!
In my opinion, Java is another clear winner here. From Wall Street systems with US$900,000,000,000 a day in transactions flying through them, to medical imaging systems rooting out cancerous pathologies, to petroleum exploration systems trying to find the precise limits to all of that new Cuban oil, Java is at the center. When it comes to handling massive datasets in a maintainable fashion, Java is second only to the C,C++ languages. Some would even say that C or C++ code is less maintainable than Java. I would say they should hire new C programmers.
Lastly, C, C++ and Assembly will always be around because there will always be someone,(Carmack) who wants to outshine everyone else. And we can all agree that nothing flies like an assembly routine. As a bonus, we can get exacting control over concurrency, synchronization and locking. It may be difficult to believe, but this option is attractive to a certain class of hacker.
Concurrency in todays web darlings, Ruby, PHP, and Python will be challenging. I think someone out there will simply come up with a new language. Or the web guys will switch to Erlang over time. They will run into a data size problem though due to the way Erlang implements concurrency at a low level. It will be interesting to watch them problem solve that.
On the front end, it's easy . . . Microsoft wins. Anyone who understands concurrency in an intimate fashion knows the challenges of getting a scripting language like JavaScript to support it in a satisfactory fashion. Do you lock and synchronize for the developer? Do you let him/her? Do you copy the heap and send messages? What about client side memory in a tabbed browser? The questions go on and on. Java may have somewhat of a chance here, depending how things go, but basically Microsoft will continue to have the majority lock.
Concurrency in the database is more interesting, particularly since that's where the bottleneck is in many web apps. But that's a C/C++ problem, and many DBMS vendors have already invested a large amount of effort into solving it.
Think about this example: You have 10 printers each capable of printing 10 pages per minute. Then 10 jobs are submitted each with 10 pages. If you run those jobs in parallel, all of them will finish after 60 seconds. If you parallelize each job and print page 1 on printer 1, page 2 on printer 2 etc., then the first job will finish in 6 seconds, the second in 12, and the last one in 60 seconds. The average latency is then (6 s + 12 s + ... + 60 s) / 10 = 33 s.
Your throughput will be the same, except for a bit of parallelization overhead.
Heard of stackless python? [http://www.stackless.com/]. Eve Online is the highest profile app using it I know of.
Introduction to Concurrent Programming with Stackless Python [http://members.verizon.net/olsongt/stackless/why_stackless.h...]
Again, for massive datasets, accessed by many cores over a massive number of threads, it needs a little more development.
TEST ALGORITHM:
Standard Volume ray casting. Each pixel processed separately. Ray casted through volume with alpha based early ray termination.
Ray-tracing is a nice, simple problem domain -- enough to be complicated, but not too complicated.
Or is that not the case?
There is of course functional approaches like haskell (but it will take longer to be mainstream).
I think fast interpreted is probably even overstating it, it makes all sorts of compromises. Erlang was also designed for very high availability - so that must cost something as well.
I guess we will see what happens, but I am very skeptical about erlang (not sure why, just a gut feel).
In terms of speed, this is something to look at:
http://shootout.alioth.debian.org/debian/benchmark.php?test=...
It's pretty fast for most things if you use HiPE.
Your skepticism about Erlang is justified in terms of "next big language":
http://journal.dedasys.com/articles/2007/10/09/languages-wor...
However, if you use it for what it was created for, it is very nice - it's the best thing out there.
In one corner are languages like Erlang that have been designed for concurrency.
In another corner are languages with massive user bases, that don't do concurrency very well (Java for example), that will have to undergo modifications to work better.
In another corner, perhaps, are languages that are just now being created. They're the outsiders, but have more agility in their design because they don't have huge user bases.