Why I Use Perl: Reliability

Perl 5.16 came out last week. That's the tenth stable release of Perl 5 in the past two and a half years and either the third or fourth major release in the same period. (I consider 5.10.1 a major release. Others do not. It matters little.)

I've already switched my main development and deployment environment to 5.16 and will switch over the remaining two user-facing servers to 5.16 in the next couple of weeks. In fact, switching my main development server to 5.16 took eight minutes last Monday, the day of the release.

While so much of the shiny-chasing buzz in the micro-ISV startup built-it-and-they-will-fund world seems to chase Clojure and Node.js and app-in-a-page tricks, Perl 5 continues to be my workhorse. It's my language of choice for prototyping and deployment, in part because it's so reliable.

I maintain three modest-sized applications these days. They need to work and continue to work. (They're in the scale of a few tens of thousands of lines of SLOC, counting tests.) They do rely on a many libraries from the CPAN, including DBIx::Class, Catalyst, and Moose, along with other specialized tools. A quick find for .pm files in my site_perl/ directory shows 4126 individual modules. My rough guess is that this represents between 250 and 300 direct dependencies and their supporting materials.

When the Perl 5.16 release candidate came out, I immediately installed it with perlbrew (see Testing Perl release candidates with perlbrew). I set about installing all of the CPAN dependencies for each of those three projects.

The entire process took four wall hours, though most of that time the process chugged along without my intervention. I found three problems. One is a dependency with a weird version number that'll be a problem on every version of Perl, and it has an upstream bug report. One was a temporary problem with a fresh release of a module already fixed in source control and unrelated to 5.16. The other was a known and temporary incompatibility with 5.16 with an existing patch.

Out of 250 or 300 dependencies for my tens of thousands of lines of production-ready code, on the day of release of the release candidate, only one incompatibility existed, and it already had a patch. (The patch worked.) Think about that. Before Perl 5.16 had its official release, enough of the CPAN had been tested and proven working with 5.16-to-be that I could have run user-facing applications on a release candidate with no disruption in service.

(As of this writing, the CPAN hosts almost 25,000 distributions and over 107,000 modules.)

All of my tests for each of my applications passed, too.

We in the Perl world talk a lot about the testing culture of Perl. It took a lot of work to demonstrate the value of automated testing way back in the late '90s and early 2000s, but that word has spread beyond the language itself and into the ecosystem.

I have the utmost confidence that I can switch the two remaining servers over to Perl 5.16 at my leisure in the next couple of weeks with minimal effort—not only because I've tested my applications with Perl 5.16 to my confidence but because the entire Perl ecosystem has been tested extensively across platforms.

For me, one of the strongest reasons to use Perl is that upgrading is no longer a question of "What will break?" but "How boring is this process?"

(If you haven't used Perl 5 in a while, Modern Perl: the Book shows how to get the most out of the language.)