Because if the language uses threads instead of processes the compiler can perform all sorts of neat optimizations on message passing. As a trivial example (an

Because if the language uses threads instead of processes the compiler can perform all sorts of neat optimizations on message passing. As a trivial example (an example I included in the post above yours), consider 'copy-on-write' optimizations. Thread A can pass a message containing Object O (which is 50MB) to Thread B. Naively, this would be pretty expensive - however the compiler can set things up so that a copy of O isn't made until either B or A tries to write to O (in which case in can even try to just copy the part that was mutated). This provides a healthy balance between the raw performance of fork-style threads and the safety of multiple processes. This sort of optimization wouldn't be possible just using processes since, obviously, Process B couldn't (or at least shouldn't ;-)) directly look into Process A's memory space. I never said don't share state - I just said don't transparently share state. Make it explicit and/or make it safe. As I said, it's never going to be quite as fast as raw fork-style threading but, with a sufficiently smart compiler, it can come close - and be a lot easier.