Why I Use Perl: Reliability

| 4 Comments

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.)

4 Comments

only problems I found is a failing Test::Vars test (bug seems to be reported) and a warning in the json meta test (dzil thing) Both of which are used if you're using @TestingMania plugin for dzil

It is great for sure. My own problem, and I am sure it has a solution, I just haven't looked hard enough, is that it requires re-install of all modules for every upgrade, because the modules are stored in a version specific directory.

However, it does make sense, because some modules (esp. XS) need to be re-compiled against newer version of Perl. But then if I upgrade Perl, and have not yet installed the modules, which in your case took 4 hours, there would be downtime.

I know of perlbrew, but didn't find it to be a good solution, because it requires ENV variables. Crons, remote logins and so on have problems with that.

Any tips on how to handle this? Maybe another article? I really enjoy reading these.

Thanks!

I like installing it from source. Here are a few links that you might find helpful:
"Item 110. Compile and install your own perls" from Effective Perl Programming, Second edition ( http://my.safaribooksonline.com/book/programming/perl/9780321718303/miscellany/ch13lev1sec1 ).

"Compile a development version of perl" ( http://www.effectiveperlprogramming.com/blog/750 )

"Make links to per-version tools" ( http://www.effectiveperlprogramming.com/blog/92 ).

You could use perlbrew to compile all the deps up-front, then install the new perl for the system and copy over your site_perl.

Modern Perl: The Book

cover image for Modern Perl: the book

The best Perl Programmers read Modern Perl: The Book.

affiliated with ModernPerl.net

Categories

Pages

About this Entry

This page contains a single entry by chromatic published on May 29, 2012 10:27 AM.

Keep Your ResultSets DRY was the previous entry in this blog.

When You Can't Misuse the Immutable is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.


Sponsored by Blender Recipe Reviews and the Trendshare how to invest guide

Powered by the Perl programming language

what is programming?