There are threads and then there are threads. I sometimes see people from a C/C++ background assuming that threads means shared memory concurrency, with all the

There are threads and then there are threads. I sometimes see people from a C/C++ background assuming that threads means shared memory concurrency, with all the synchronisation problems this entails. If you have a message passing/actor abstraction, so that threads only communicate by sending and receiving messages, writing high performance threaded code is pretty easy. I've done it, as have many others (case in point: any system written in Erlang). Like you say, a decent language can make event-driven code seem like straight-line code. The Akka framework (http://akka.io/ http://akka.io/) even makes event-driven code look like message passing. There are two substantive points to be made, I believe: - If your language's runtime doesn't allow you to use all available CPUs it's a bit lame -- or at least limited in its application. (Hi Node.js.) - Given one concurrency abstraction you can, most of the time, build other concurrency abstractions. We've seen this above with Akka. To make this feasible your language better provide some lightweight concurrency mechanism -- either lightweight threads or events.