A little part of my Perl soul died the other day when I read a tweet by Mark Jason Dominus:

Perl didn't work for this guy, here's why. It was a really good article, should be required reading for #perl folks: synflood.at/blog/index.php...

When Andreas Krennmair announced a new Twitter client called baconbird in late 2010 he sounded very enthusiastic about Perl, saying

The code itself is about 850 SLOCs of Perl code, the user interface is based on STFL, the Twitter backend uses Net::Twitter, and all the OO glue code in between uses the Moose object system. All in all it took me less than 2 weeks of my free time to develop the first version of it.

I was excited to read this post because I really like his newsbeuter feed reader (I've chatted once or twice with Andreas over IRC about it and helped package it), and it was interesting to see him choose Perl over C++ for this new project. I pulled in the baconbird dependencies and started using it right away.

Some months later Andreas wrote a blog post entitled "I don't want my programming languages to be hip" in which he praised the Perl community, saying

I just want a quiet, hype-free, pragmatic, down-to-earth knowledgable community. . . Exactly the things that I learned to despise about the culture revolving around Ruby and Rails are something that I haven't experienced in the Perl community at all so far. Libraries, framework, documentation and people had more time to mature, probably, while still being down-to-earth. I can expect good documentation, functioning software, friendly people and most importantly accurate words in announcements and discussions.

Everything seemed peachy. We had a happy Perl programmer on our hands.

Last week, however, within a year of baconbird's release, Andreas blogged about the problems he has been having with Perl:

But first things first: my first poor choice was using Perl. Sure, Perl provided me with all the tools to come to meaningful results really quickly, through the vast amount of ready-to-use modules in the CPAN archive. And that's what's really great about it. What's not so great about Perl are the ideas of concurrency. You basically have to resort to event-based, async-I/O programming, which is not only painful by itself, but also extremely painful to integrate with my widget set of choice, STFL. And threads in Perl... don't do it, that's what everyone says. That meant that I couldn't do any of the Twitter communication asynchronously in the background, but had to do it in my primary thread of execution, essentially make it part of the subsequent calls of the input loop, if I wanted to retain sanity and a certain level of productivity. And that made baconbird really slow to use, and when Twitter's API was offline, baconbird practically hung. That made baconbird just a PITA to use, and I had to change something about it.

That post is entitled "Rebooting the baconbird project" but his new Twitter client is a complete rewrite and has a new name: gockel. It's written in Go, which has a particular focus on concurrency, as I understand it.

So far I've been disappointed by the comments on Andreas's post. I'm not skilled enough in Perl or concurrency to say anything about how to solve his problems, but maybe someone else will be inspired to post an nice comment with some suggestions. As I quoted above, he isn't using an event-based model (so I take it AnyEvent is a non-starter) and he's really into STFL (newsbeuter uses this well), which seems to complicate matters. Maybe Go is simply a better tool in his situation. Maybe threads::tbb could help. I don't know.