You could replace the original language with most other scripting languages (Python, Ruby, etc); but here is an example of sub-par concurrency control causing the language to be dropped for Go in a fairly high-profile way.
http://blogs.perl.org/users/philip_durbin/2011/10/perl-dropped-and-go-adopted-due-to-concurrency-issues-in-baconbird.html Original post: http://synflood.at/blog/index.php?/archives/791-Rebooting-the-baconbird-project.html When I presented Qore at the September PM meeting, it was to say - "look a Perlish language that supports real threading/Wouldn't it be great if Perl did this, too?" To be fair, Go is a different beast. It's a 3rd generation distributed language built with lessons learned after (C), Aleph, and Limbo (hello Plan 9, again). Go's recently been ported to Plan 9 on the BlueGene architecture (https://twitter.com/#!/ibm_ericvh/status/103547803837534209). BlueGene's a hybrid architecture that has different runmodes base on if you're running a serial, MPI-ish, or SMP type job. It also has several communication networks for message passing (i.e., scatter/gather, point-to-point) and I/O. Using this sort of environment efficiently is the type of problem Plan 9 has been looking to solve since it's inception - and Go is the latest piece of that puzzle. However, Go is not the first one to play in this space; it still has to compete with the tradition (OpenMP, MPI) and the emerging HPCS winner, Cray's Chapel. I digress. Go is also playing a role Google, and by that fact alone will continue to attract a fanbase - hopefully stealing from Python and Ruby (and not Perl :). None of the above are Perl, and it will continue to weather the storm. However, back to my original point. It occurs to me that people are much more ready to make excuses for Perl's lack of threading than to simply admit that something needs to be done. My hope is to make some people be able to face this truth and realize that when people talk of threads and concurrency, the are talking about wanting to build interesting things using efficient threading - forking or event-drive asynchrony simply will not do for these people (myself included). In my talk, I claimed that any scripting language that doesn't properly support threading and concurrency will find itself not very popular on many-core machines. It'll instead exist as a sysadmin's tool where threading isn't that important because heavy forking is acceptable (i.e., the famous retort, "Why is forking is not an option?"; these languages will also have a place in one of many single-cpu virtual machines that most people seem to be using many-core machines for anyway. Real applications can fill up such a machine, but they have to be threaded. And if people don't start demanding that Perl's concurrency offerings get with the times, then Perl will no longer be used to develop so many interesting applications on real (not virtual) many-core machines. Please share your thoughts; I don't want to be this a single minded rant driven by my love for Perl and my inability to marry it to my interest in shared memory programming :) Thank you, Brett -- B. Estrade <[email protected]> _______________________________________________ Houston mailing list [email protected] http://mail.pm.org/mailman/listinfo/houston Website: http://houston.pm.org/
