Hmmm... and another thing. I guess it is fairly obvious that the future lies in more CPU cores and more distributed processing.
This means that the whole concurrency thing has to be adressed by Python sometime, although that will be evolutionary I guess. It looks like the Erlang model is pretty cool. If my understanding is correct (which is unlikely), Erlang runs effectively as a 'process server' with lots of these inter-communicating 'processes'. Does the server run as a single OS process ? (So if you core dump everything dies, such is life.)
Yep, an Erlang "process" is internal to the Erlang runtime, or "Node", which runs as a single OS process. You can run as many Nodes as you like though on the same machine or on different machines and then have them talk to each other. At that point, the message passing between Erlang processes is transparent. If you send a message to another process, you don't need to know what Node the process is running on; the runtime takes care of all that. So you typically achieve fault-tolerance by running multiple Nodes on multiple physically seperate machines and use some of Erlang's supervision and monitoring functionality to recover gracefully if a Node manages to crash. An Erlang Node crashing would probably happen more from hardware failure than a core dump though since it's been pretty thoroughly battle-tested and Erlang doesn't really let you do stupid things like pointer manipulation.