Last week I had a discussion in the local perl mongers mailing list about threads in Ruby vs Perl, and parallelism in general.
My view is that it's the programmer responsibility to start using all those core coming our way, and that the Java/Ruby-style of threads, with a share-everything model, are the wrong way of doing it.
I a very big fan of shared-nothing by default when it comes to threads. From all the things that are wrong about Perl (and believe me there are many), that is the one they got right, and I can only hope that Perl6 takes the same approach.
The language that comes closer to what I think is the nirvana of the parallelism models is Erlang. With it you get three concepts:
- shared nothing approach with lightweight threads (processes in Erlang lingo): your program is modeled as a set of cooperating processes, each one performing some specific task;
- fast message passing interface: processes communicate by passing messages between them;
- location independence: each process has a PID, and you can send messages to it. But you don't need to know where the process is, he can be in a server across the ocean.
This set of concepts allows you to build reliable applications, where memory corruption and simultaneous access to data is limited, therefore causing less bugs.
The problem is that programming in Erlang, for someone like me who has been programming in Basic, Assembler, Pascal, C, Perl, and others of the same type, for 25 years now, it requires a big change in mentality, it requires a different brain.
I'l be attending a Erlang course in the next couple of months, courtesy of SAPO, and I hope to change that.
In the meantime, check out Tim Bray post about multiple cores, concurrency and Erlang where I stole the title for this one.