I think 'race' is one way of looking at it. Another way to look at it is that there will be more than one 'winner'. Just like today, I think in the world of tomorrow people will use more than one programming language. So all of the languages that expect to be around tomorrow will need to evolve into languages for controlling concurrent systems on massively parallel architectures.
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 web languages is a non-issue, because each request is independent (or should be, if you have a proper shared-nothing architecture). You simply run multiple processes and give each process a full core. Most FastCGI/SCGI webserver modules have functionality built-in to multiplex among backend processes.
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.
Well, there is actually a latency gain to be had from parallellizing indidvidual requests, rather than just running several requests in parallel.
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.
Stackless is interesting, but I found it to be a little unwieldy when I wrote a volume visualization test. When each task needs access to the entire volume of data, Stackless gets REALLY slow. I didn't look through the Stackless internals the way I looked into Erlang, but the slowdown was undeniable.
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.
That's an excellent test algorithm because of the shared memory issues. Might be better if the rays affected the environment -- say laser beams. (For some reason I have a picture of sharks with laser beams)
Ray-tracing is a nice, simple problem domain -- enough to be complicated, but not too complicated.
Stackless is an example of the communicating sequential process model, not concurrency. You avoid all the issues around locking etc because switching between processes (tasklets) is explicit - it's cooperative multitasking not preemptive. It's a very nice language but doesn't help at all with running on multiple cores. Once you start having multiple processes running simultaneously and shared mutable state you have to start worrying about things like locks. Erlang nicely sidesteps the problem by not having mutable variables.
I don't think erlang is that great for the scenarios that started this thread - it is designed for 1000's of processes, not dozens. And by all reports its straight line performance is much much much slower then anything else out there.
There is of course functional approaches like haskell (but it will take longer to be mainstream).
Erlang is functional, but in any case, you're right about its performance - it's more or less that of a fast interpreted language, rather than a compiled language.
I never thought of it as functional - looked more like little islands of imperative programming to me (I guess I will have to check again).
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).
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.