I've felt for a while that silent failure is a serious possibility when Linux distributions change bundled Perl versions with little or no discussion.
The medium-term answer for me is probably to learn Python well enough to port my code to it.
I've felt for a while that silent failure is a serious possibility when Linux distributions change bundled Perl versions with little or no discussion.
The medium-term answer for me is probably to learn Python well enough to port my code to it.
I'll note that Perl just went through a year or so of painful argument to rediscover that "Perl should stay Perl", so I'd be more confident in that.
Also, Python is at least as bad as Perl about breaking silently. If you care about maintaining a codebase over time, pick anything that has static types.
I’ve found Go to be a reasonable python replacement, though I haven’t found either python or go to be a reasonable perl replacement.
I don't have much invested in Python at the moment. I would be more aware of and concerned about Python issues if I had larger scripts written in it that I need to maintain.
I have used Perl 5 long enough to know that it is a mature language. I'm concerned about the integrity of CPAN and individual modules' abilities to interoperate with the versions of Linux that I deploy in production.
Perl prioritizes backwards compatibilty above all else so much so that it hides new language features behind either a version declaration `use v5.30;` or a feature declaration `use feature 'say'`
Code written on 5.8 (2002) will run perfectly fine on perl 5.34 (2021). The language and standard library have had a few deprecations but most of them were problematic or unused features and went through a long deprecation cycle where perl would emit warnings about the upcoming deprecation.
That's the core language though, there is nothing to be said about the consistency of CPAN modules just as with any other language's collection of third party libraries. Or with vendor packaging.