Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw

Why upgrade perl?

by poulhs (Beadle)
on May 20, 2013 at 08:41 UTC ( [id://1034301] : perlquestion . print w/replies, xml ) Need Help??

poulhs has asked for the wisdom of the Perl Monks concerning the following question:

We (as so many others) use perl intensivly, but we are currently stuck with the stock RHEL6 perl (that is 5.10.1).

I am considering building our own perl (in /opt/somehwere), adding the modules that we need, and keeping that up-to-date (using jenkins to build our own RPMs for deployment). I have a feeling about the amount of work involved with this (been down that road before), and my boss asked the ultimative question:

Is it worth it?

So I started to prepare a what's-the-difference tutorial (from perldelta's), then 5.18.0 came along and threw given/when and ~~ into experimental::smartmatch, so now I am (almost) back to square 0. Almost all I got is some optimizations and some hash-key security...

Compared to 5.10.1, why should I upgrade to 5.18.0?

  • I know the pain, what is the gain?
  • What do you think is the most important arguments for upgrading to 5.18.0?
  • How will 5.18.0 make us happier, our life easier and sun shine more frequently?
  • Or am I complete lost, and should I continue being stuck with the stock?
Thank you Monks, for allowing a humble perler interrupt you.

Replies are listed 'Best First'.
Re: Why upgrade perl?
by tobyink (Canon) on May 20, 2013 at 09:12 UTC

    5.16+ has much better Unicode support than 5.10.1, including the "unicode_strings" feature (where all strings are treated as Unicode except in the scope of use bytes or use locale), and the fc function which is useful for case-insensitive string comparisons.

    Perl 5.16 has the __SUB__ keyword which acts as a coderef pointing to the current sub. This is useful for writing anonymous recursive functions.

    5.14+ supports the package NAME BLOCK syntax, which is cute, but isn't going to change your world.

    use v5.12 (or above) automatically enables use strict, reducing some typing.

    The yada-yada operator, introduced in Perl 5.12 is handy during development.

    There are beginning to be a few nice CPAN modules like Switch::Plain, Fun and Try that use the pluggable keyword API introduced in Perl 5.12/5.14.

    Whether these are compelling enough reasons to upgrade will depend a lot on how you use Perl, and what you use it for. I'd certainly suggest having a copy of Perl 5.18 on a development machine to make sure that the code you write runs on it; whether you deploy it for production use is a different matter though.

    package Cow { use Moo; has name => (is => 'lazy', default => sub { 'Mooington' }) } say Cow->new->name

      use v5.12;
      use strict;
      is not much reduced typing ;-)
      (I know it gives more than just strict)

        use v5.12; is less typing than use v5.10; use strict; though.

        package Cow { use Moo; has name => (is => 'lazy', default => sub { 'Mooington' }) } say Cow->new->name
Re: Why upgrade perl?
by space_monk (Chaplain) on May 20, 2013 at 08:45 UTC

    At some point older versions will not be supported and have unpatched security vulnerabilities, module updates won't run on older versions of Perl etc.

    You should take the opportunity to work out some form of company wide regular upgrade process and to make it as painless as possible. I'm not sure about the benefits of being right on the leading edge, but you shouldn't be too far behind it.

    Update: Some people have pointed out that releases are customised and may be difficult to upgrade. There is an argument for leaving the system Perl unaffected and having an independent site Perl, which is hopefully kept up to date.

    If you spot any bugs in my solutions, it's because I've deliberately left them in as an exercise for the reader! :-)

      I agreee that one should not fall too far behind... (tell RedHat)

      Company wide upgrade process is in place, that is (concerning this subject): follow RedHat on Linux..

      We use satellite server for maintaining OS and other packages. We are a managed hosting company, and keeping the servers updated is natural.

      We use perl to write integration code between CMDB and other stuff, on our own infrastructure servers - and here we have the possibility to install our own tools if we need

      I know that older versions are not supported by the community (and that the support from RedHat may vary;-) )

      My problem is that I lack the arguments, when there are no significant differences between 5.10.1 and 5.18.0. Yes, I know about the security issues, but that goes for all RedHat stock stuff, and as long as we don't expose our services to the public, I think that this argument will only hold half-way through...

      thanks for your answer

      At some point older versions will not be supported and have unpatched security vulnerabilities
      I don't think this is valid argument for RHEL. They maintain and fix perl by their selves AFAIK.
      module updates won't run on older versions of Perl
      I didn't see much modules, which won't work on perl 5.10 and even 5.8 (but I didn't check some huge frameworks)

        RedHat shipped a badly crippled version of perl a few years ago and took a long time (almost two years, IIRC) to fix the situation after being notified.

Re: Why upgrade perl?
by derby (Abbot) on May 20, 2013 at 12:07 UTC

    Forget the upgrade argument, install your own version of perl *just* to isolate your app from vendor choices that may conflict with your own choices. There are some high level arguments on why to leave the vendor install alone on the perlbrew homepage.


      For me, this is the primary argument. The vendor's installation is the vendor's. They will not consult you to see if your application will run under a future (or past) version that they want to move to, nor will they rush an upgrade just because your application 'needs' some feature. You are able to test, package, and deploy your application based on your requirements, instead of the current implementation selected by your OS vendor.*

      * Yes, this is a broad brush, and there are some instances where using the OS vendor's version of perl is the RightThing, but that is a tradeoff and business / marketing decision, IMO. Just my $0.02.


      I think it's valid argument only if your applications are really huge or they're bloatware without testsuite, full of legacy code with 100+ CPAN dependencies and full of technical debt. And you're totally unsure why it would/wouldn't work on certain version of Perl.

      Otherwise it will be pretty easy to test it with several versions of Perl, on dev machine, to make sure the code matches Perl specification, and that you are not using some crazy CPAN modules. Any incompatibility will be a good reason to investigate the reason to make sure your code actually does not contain bugs. Easier deploy to RHEL servers is a bonus

        Until your OS patch changes the OS's version of perl (or a library) under the hood, breaking the assumptions made by your application. This happens in large enough organizations where 'the canonical OS platform is X.Y.Z, and all machines must be upgraded to X.Y.Z by this and such date' (yes, it does happen :-/ ). Using your own perl gives one fewer moving part not under your control.

        If you are releasing on CPAN, then yes - test far and wide. There are times for both approaches.


Re: Why upgrade perl?
by Anonymous Monk on May 20, 2013 at 09:16 UTC


    If you have to ask :) it isn't worth it :)

    Don't worry about new syntax ... not that important, but bug fixes, esp regarding threads are

    The other thing is increasingly improved unicode support

    This brings you up to perl-5.14.4, or perl-5.16.3

    If you're thinking you need some of the fancy new regex features, you don't, all you need is marpa scanless

    Re: perldeltas - every perl*delta in one file (pod.lst) ( perldeltas.html#p5144-Security     perldeltas.html#p5163-Security )

Re: Why upgrade perl?
by Laurent_R (Canon) on May 20, 2013 at 10:35 UTC

    I am not sure why in details, but we upgraded some of our servers to Perl 5.16 because it seems to have much better threads.

      we upgraded some of our servers to Perl 5.16 because it seems to have much better threads.

      Any pointers to the evidence?

      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.

        As I said, I do not really know the details. This is not my main work, but an application for which I only work occasionally. It was previously working on 5.8, if I remember correctly (or perhaps 5.10, but I think it was 5.8), and they decided to upgrade because they wanted to use threads in a new framework developped internaly, and, apparently, it does make a difference. I do not know the details personally, but I would tend to trust the person who proposed that upgrade decision, because I know it is someone who usually knows fairly well what he is doing.

        But the point is that the improvement was compared to Perl 5.8, not a more recent version.

Re: Why upgrade perl?
by rjt (Curate) on May 20, 2013 at 21:46 UTC

    In most cases, rolling your own Perl does not require an inordinate amount of work. I refer to you to Perlbrew and cpanminus, both of which can be potentially life-changing.

    The benefits of running your own Perl go beyond the new language features (which are significant between 5.10 and 5.18; see perldelta for more information). By running your own Perl, you gain complete control over what you upgrade, and when you upgrade. OS Perl releases are often for the benefit of the OS itself: to support scripts used by the particular Linux/UNIX distribution you run, so those releases tend to lag pretty far behind. In this case, five and a half years! The releases are often patched as well, either to backport bug fixes, or for other reasons. Hence, you are not running vanilla Perl.

    For these reasons, you will often have trouble installing CPAN modules, and are often faced with the dilemma of whether to use the (older) RPM provided by your Linux distribution, if anyone bothered to package it at all, or abandoning it entirely if it won't install via CPAN due to incompatible dependencies or Perl version.

    Running your own Perl will fix these issues, but note that any Perl modules that depend on C/C++ libraries may still cause problems if the RedHat versions lag too far behind. Staying with the OS Perl and OS-packaged mods usually avoids this issue by keeping all the versions in sync even if they're old, or not providing packages for newer modules.

    Nothing's perfect, but once you get past the fear of the unknown and acclimate to the perlbrew process, many headaches go away.

    That being said, upgrading the programming language (or its modules) that underlies a large programming project is not something to be done on a whim, as interfaces can change, subtle changes can cause bugs (such as the hash order randomization change), and other unexpected problems can occur. That is not to say that upgrading isn't worth it, but you would be well-advised to have a fallback plan, and an excellent suite of unit tests and manual test plan to quickly find any regressions.

      For these reasons, you will often have trouble installing CPAN modules
      You're overstating the case. Granted, I'm a sample size of one, but, although my primary job description is "Perl programmer", I'm also the local devop[1], so I maintain several boxen running a mix of distros[2], some of which are rather ancient[3]. With the exception of Perl 5.8.x vs. 5.10, I have never encountered an issue with a CPAN module failing to install due to the system perl being too old. OP said he's currently on 5.10.1, so my experience suggests that this should not be an issue for him.

      [1] ...and used to be a full-time sysadmin, once upon a time.

      [2] The ones I install tend to run Debian and legacy systems are mostly Red Hat, but just about anything can pop up on occasion - SUSE, Mandriva, you name it.

      [3] The current oldest is a Fedora Core 5 server, which we finally managed to start moving things off of just last week.

        I am frankly quite intrigued why you say, “overstating the case,” because I certainly have encountered incompatibility issues on a great many upgrades.   And, given that RedHat’s most-essential software tools run on Perl, that does become a serious concern.   I am not challenging your POV, but it does surprise me to hear this.

Re: Why upgrade perl?
by poulhs (Beadle) on May 22, 2013 at 09:32 UTC


    • security fixes
    • indepence of /usr/bin/perl
    • improved UNICODE support
    • improved thread support
    • misc. "minor" syntactical sugar (package Foo VER, __SUB__,

    My €.1 about relying on stock /usr/bin/perl vs. latest and greatest:
    It is true that vendor may choose to upgrade their perl in a way that is incompatible, and that this may hurt us. But that will be true for anything installed on a box: libc, libssl, openssh, bash. The reason for incompatiblity may as well be due to some community/-ies changing policy/-ies (like openssh vs. bash and the handling of .bash*). And the incompatibility problem would certainly have hit us if we had choosen latest and greatest, as 5.18.0 did move the given/when and ~~ into experimental mode (and thus removing my best arguments...).

    The only feasible way to handle this problem, is (at least in our case), automated testing of our perl modules/scripts and all our other stuff, to ensure it works in the next new environment, whether it is new due to satellite server upgrades and/or a new version of latest and greatest.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://1034301]
Approved by marto
Front-paged by marto
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (3)
As of 2024-03-02 07:20 GMT
Voting Booth?
My favourite way to spend a leap day ...

Results (29 votes). Check out past polls.