[pm-h] dynamic language concurrency support and the NWO

[B. Estrade]

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 <estrabd at gmail.com>