5 ms·

Are people still using Perl for new software? I remember at a former company, we had a major migration away from Perl 12 years ago. The Perl code base was cons

Are people still using Perl for new software? I remember at a former company, we had a major migration away from Perl 12 years ago. The Perl code base was considered extremely ancient even back then.

forgotmypw17 1y ago
Yes, it's still well-maintained and highly backwards-compatible, avoiding breaking changes between releases.
- walterbell 1y ago
  We need an ROI metric to quantify the backward compatibility and low churn of Perl relative to languages like Python, Ruby, golang.
  - lordofgibbons 1y ago
    Golang declared a perfect backwards compatibility guarantee way back when version 1 was released. So in this regard, Perl isn't unique.
    - naikrovek 1y ago
      well, Go has broken that backwards compatibility when it was deemed important enough to break things. So it's not "perfect" and I imagine Perl's isn't either.
      - drysart 1y ago
        Perl as a language is pretty mature and rarely sees breaking changes (and what breaking changes exist are in corners of the language that are extremely esoteric even for Perl). You can take a Perl script written 25 years ago and it'll still run just fine. New language features and things that might alter existing behavior are usually locked behind a version declaration opt-in at the top of your script. You need to do something similar to `use v5.39;` to unlock new behaviors from that version of Perl -- which may contain breaking changes but those are also generally backward compatible too. But that's for the base language and standard library. Individual third-party packages may vary in their backward compatibility.
        dcassett 1y ago
        I remember a breaking change that was not esoteric: "keys %hash" started producing a different result each time the script was run. It required replacing the construct with "sort keys %hash" to get reproducible results.
        librasteve 1y ago
        Perhaps, but code that inadvertently depends on the Hash implementation returning keys in a particular order is arguably incorrect.
        jcynix 1y ago
        I can't remember a time where "keys %hash" returned the keys in a defined order. And I've been using Perl for over 30 years now. I've just consulted my first issue of "Programming Perl" (printed in 1990l and it says: keys (assoc ARRAY) this function returns a normal array consisting of all the keys of the named associative array. The keys are returned in an apparently random order, but it is the same order as either the values() or each() function produces (given that the associative array has not been modified)
        dcassett 1y ago
        Agreed, but prior to the change the "apparently random" as described in the documentation was similar to using random(fixed_seed), rather than the new behavior of random(system_time), which made the output of the script non-reproducible given the same inputs. The change to Perl's behavior was made for security reasons. (Edited for clarity)
        ether_at_cpan 1y ago
        > I can't remember a time where "keys %hash" returned the keys in a defined order. It was never a _defined_ order, but before version 5.17.6 (November 2012), each hash returned its list of keys and values in a _consistent_ order between runtimes, so some code ended up getting written that depended on this ordering (say in a unit test, or a list that would get assigned into a database). The change was to make the ordering random/inconsistent/unpredictable every time the list was fetched, which as I recall did break some number of tests in CPAN modules and required new releases.
- martinflack 1y ago
  And the last release was three weeks ago! Perl 5.42.0 was released July 3, 2025.
- SoftTalker 1y ago
  > avoiding breaking changes Perl 6? It was so breaking they don't even call it Perl anymore.
  - kstrauser 1y ago
    In fairness to Perl, that's a good reason not to consider it a breaking change.
  - em-bee 1y ago
    perl 6/raku was a redesign. as far as i remember, upgradeability from perl 5 without code changes was never the goal.
    - SoftTalker 1y ago
      Isn't that the definition of a breaking change?
      - em-bee 1y ago
        yeah, in the same sense that D is a breaking change for C, or wayland for X11. the point is that as far as i know it was never intended that existing perl 5 code would be rewritten. unlike the python 2 to 3 change where the intention was that people would convert using 2to3 and later using compatibility modules that allowed writing code that works with both. python 2 development stopped after 12 years, much later than they expected.
      - 0xbadcafebee 1y ago
        If Ford makes a 4-door passenger car, and then comes out with a 2-door sports car, and keeps producing both cars, that's not a breaking change. It's just a new car. Perl 5 is still supported, Perl 6 (Raku) continues independently.
    - aaronbaugher 1y ago
      It's unfortunate that that wasn't clear to people who weren't closely involved with Perl at the time. So many people got the impression that Perl 5 was outdated as soon as 6 was in development, so they thought they had to move on from it. It's too bad Raku didn't have a different name from the start.
6031769 1y ago
Yes, we mostly use Perl for new software. If you let your codebase get into an "ancient" state then that's a problem of your own creation rather than that of the language or system in which it is written.
- kosolam 1y ago
  I’m very curious to hear your experience building greenfield projects with perl today. And what are the main advantages you feel that you get from it?
  - doublerabbit 1y ago
    For my company, it's cross-platform and just works. It's file & data capabilities are powerful enough to deal with lots of miniature sized files from the renderer. Perl just hovers them up and does whatever processing. We did test Python but it just felt clunky in it's habits and felt lacking in terms of performance such as stalling in building a dictionary list of files to work with. Perl may be one of the older languages, but it still holds strong. If Perl is supported for your $OS your script is guaranteed to execute. Sure, adjustments may have to be made if you're targeting the underside of the rainbow such as Windows but it's trivial for *nix hosts. Migrating from Ubuntu to Debian, BSD? -- 99.9% chance your script will run. I am bias, in that their isn't anything majority wrong with perl. It was used as the main language back in the 80's for a reason and Perl's ecosystem (cpan) is still pretty comprehensive and still holding weight. As it's not taught anymore due to newer trends this is causing it's shine to dull and it's overall presence dropping away. I wouldn't disagree that new languages boast optimism in to the future of programming technologies but with perl it has been battle tested and just works.
    - sundarurfriend 1y ago
      > Sure, adjustments may have to be made if you're targeting the underside of the rainbow such as Windows but it's non-trivial for *nix hosts. The rest of your comment makes me think the "non-trivial" was a typo and meant to be something else.
daneel_w 1y ago
I maintain and develop the back-end of a telecom services provider. It's almost 100% Perl, and once in a blue moon when we add something entirely new we usually stick with Perl.
polytely 1y ago
I've actually started using raku for hobby projects recently (my day job is C#) and it is actually really fun to write.
SoftTalker 1y ago
How good are LLMs at writing Perl? I've tried to use Perl a few times, even being pretty conversant with shell scripting, sed, awk, etc. I found Perl to be difficult because it's so full of idioms that you "just have to know" and (to me anyway) TIMDOWTDI actually makes things harder for a new/learning perl developer. What I want is TITBWTDI (this is the best way to do it).
- doublerabbit 1y ago
  Not bad. At my last gig we had a modernization project where we were converting Perl to Python and the company invested in their own self-hosted co-pilot. (Bank) It would hiccup where it would write the existing perl codebase in to a hallucinated python syntax but this was two years ago.
- johnisgood 1y ago
  Claude seems to fare well. I have used it for a couple of existing and new projects written entirely in Perl. LOC was below 2k per project.
- cestith 1y ago
  Check out Modern Perl. It won’t limit you to one best way for everything. It will give you one best way to do many things, and a smaller set of good ways to do others. https://isbn.nu/9781680500882 https://isbn.nu/9781680500882 Keep in mind though that the current state of Perl includes being in the process of getting a native object model baked into the language core. So that’s still in some flux but it’ll be better than choosing among eight different external object model libraries. It’s also more performant. The docs for that I’m not sure are in a bound paper book anywhere yet, but I’d happily be corrected.
  - chromatic 1y ago
    I'm not aware of any published books yet, but I'd like to publish a 5th edition of Modern Perl sometime, and it will include the native object model.
- Enk1du 1y ago
G3rn0ti 1y ago
I am working for a company maintaining an enterprise grade software system that is primarily driven by Perl 5 and Postgres. It generates about EUR 50 million in revenue every year. To avoid creating new Perl code from scratch we created a REST API many years ok which new frontends and middlewares use instead of interacting with the core itself. That has been successful to some extent as we can have frontend teams coding in JS/TypeScript without them needing to interact with Perl. But re-writing the API‘s implementation is risky and the company has shied away from that. Fixing API bugs still require to dive into a Perl system. However, I found it easier turning Python or JS devs into Perl devs than into DB engineers. So, usually, the DB subsystem bears the greater risk and requires more expensive personnel.
autoexec 1y ago
Perl is still what I reach for when I have a regex heavy task. At my job there's a near 50/50 split between python and perl scripts. I've re-written some of the perl used for general sysadmin tasks in python too, but I haven't seen enough benefit to justify doing more. It works. Plus, in my opinion, perl is more fun to write.
- nailer 1y ago
  > Perl is still what I reach for when I have a regex heavy task. That's the point of PCRE though - you get Perl's excellent regex implementation in more places.
  - autoexec 1y ago
    It's not usually that there are features I need which python doesn't support, it's just much more cumbersome to use in python compared to perl where it's part of the language and can be used just about anywhere without even adding another import.
    - macintux 1y ago
      The friction difference between "part of the syntax of the language" and "have to use this library" is enormous.
      - bornfreddy 1y ago
        Enormous like "import re"? It is still part of core python.
        macintux 1y ago
        Yes. When writing a Perl script, there's literally zero friction to using regular expressions because they're baked in. I just type what I want to run. When writing a Python script, I realize I want a regular expression, and I have to stop the code I'm writing, jump to the top of the file, import re, go back to where I was. Now, maybe I'm writing a quick script and I don't care about tidiness, and I only have to stop what I'm doing, put "import re", and then write the code I want, but still, I'm stopping. Or I'll wait until I've written the code I want, and go back and put it in. If I remember. If not, I'll find out when I run it that I forgot it. Or my IDE will show me in red ugly squigglies that I need to right click or hover, and there'll be a recommended solution to import it. This is all friction that isn't there with Perl.
0xbadcafebee 1y ago
Python is only 3 years younger than Perl, should we throw Python away? (actually, I'm on board...)
2OEH8eoCRo0 1y ago
Perl is outstanding, I wish more things used it!
weare138 1y ago
Yes. I do. Just in case anyone doesn't know Perl has been in active development and has been adding new features the entire time. It was never 'dead'. This is Perl's new OO interface that was recently added as a stable feature in 5.40: https://github.com/Perl-Apollo/Corinna https://github.com/Perl-Apollo/Corinna
- perigrin 1y ago
  It's still considered an experimental feature, just as it was in 5.38.x. Also the linked documents aren't 100% reflective of what's been implemented so far, a better URL would probably be https://perldoc.pl/perlclass https://perldoc.pl/perlclass.
petesergeant 1y ago
Generally only places that have a large amount of existing Perl and Perl developers. It’s a fine language with a strong ecosystem but even most Perl shops have a second backend language these days. I would happily use it again, but the only compelling reason to write new stuff in Perl is if most of your existing stuff is.
77pt77 1y ago
Well, I assume this is for Perl 6 that never really caught on.
oofbey 1y ago
The TIOBE index says Perl is currently the #11 most popular programming language (up from #30 a year ago). ref: https://www.tiobe.com/tiobe-index/ https://www.tiobe.com/tiobe-index/ Now, I don't actually believe this, because that puts Perl way ahead of Rust (currently at #18). So the big thing I'm taking away from this little research post is that I no longer trust the Tiobe index. Too bad - it felt pretty reliable for a long time.
- leejo 1y ago
  Which is more believable or surprising: a) there is probably several orders of magnitude more Perl code running out there in the wild than Rust? b) the TIOBE index was ever meaningful?
  - oofbey 1y ago
    I'm sure (a) is true. But TIOBE is supposed to be some balance between "total mass of existing code" and "current interest in new code".
- petdance 1y ago
  I suggest that there are no meaningful conclusions to be gleaned from the TIOBE rankings.

Are people still using Perl for new software? I remember at a former company, we had a major migration away from Perl 12 years ago. The Perl code base was considered extremely ancient even back then.

forgotmypw17 1y ago

Yes, it's still well-maintained and highly backwards-compatible, avoiding breaking changes between releases.

walterbell 1y ago
We need an ROI metric to quantify the backward compatibility and low churn of Perl relative to languages like Python, Ruby, golang.
- lordofgibbons 1y ago
  Golang declared a perfect backwards compatibility guarantee way back when version 1 was released. So in this regard, Perl isn't unique.
  - naikrovek 1y ago
    well, Go has broken that backwards compatibility when it was deemed important enough to break things. So it's not "perfect" and I imagine Perl's isn't either.
    - drysart 1y ago
      Perl as a language is pretty mature and rarely sees breaking changes (and what breaking changes exist are in corners of the language that are extremely esoteric even for Perl). You can take a Perl script written 25 years ago and it'll still run just fine. New language features and things that might alter existing behavior are usually locked behind a version declaration opt-in at the top of your script. You need to do something similar to `use v5.39;` to unlock new behaviors from that version of Perl -- which may contain breaking changes but those are also generally backward compatible too. But that's for the base language and standard library. Individual third-party packages may vary in their backward compatibility.
      - dcassett 1y ago
        I remember a breaking change that was not esoteric: "keys %hash" started producing a different result each time the script was run. It required replacing the construct with "sort keys %hash" to get reproducible results.
        librasteve 1y ago
        Perhaps, but code that inadvertently depends on the Hash implementation returning keys in a particular order is arguably incorrect.
        jcynix 1y ago
        I can't remember a time where "keys %hash" returned the keys in a defined order. And I've been using Perl for over 30 years now. I've just consulted my first issue of "Programming Perl" (printed in 1990l and it says: keys (assoc ARRAY) this function returns a normal array consisting of all the keys of the named associative array. The keys are returned in an apparently random order, but it is the same order as either the values() or each() function produces (given that the associative array has not been modified)
        dcassett 1y ago
        Agreed, but prior to the change the "apparently random" as described in the documentation was similar to using random(fixed_seed), rather than the new behavior of random(system_time), which made the output of the script non-reproducible given the same inputs. The change to Perl's behavior was made for security reasons. (Edited for clarity)
        ether_at_cpan 1y ago
        > I can't remember a time where "keys %hash" returned the keys in a defined order. It was never a _defined_ order, but before version 5.17.6 (November 2012), each hash returned its list of keys and values in a _consistent_ order between runtimes, so some code ended up getting written that depended on this ordering (say in a unit test, or a list that would get assigned into a database). The change was to make the ordering random/inconsistent/unpredictable every time the list was fetched, which as I recall did break some number of tests in CPAN modules and required new releases.
martinflack 1y ago
And the last release was three weeks ago! Perl 5.42.0 was released July 3, 2025.
SoftTalker 1y ago
> avoiding breaking changes Perl 6? It was so breaking they don't even call it Perl anymore.
- kstrauser 1y ago
  In fairness to Perl, that's a good reason not to consider it a breaking change.
- em-bee 1y ago
  perl 6/raku was a redesign. as far as i remember, upgradeability from perl 5 without code changes was never the goal.
  - SoftTalker 1y ago
    Isn't that the definition of a breaking change?
    - em-bee 1y ago
      yeah, in the same sense that D is a breaking change for C, or wayland for X11. the point is that as far as i know it was never intended that existing perl 5 code would be rewritten. unlike the python 2 to 3 change where the intention was that people would convert using 2to3 and later using compatibility modules that allowed writing code that works with both. python 2 development stopped after 12 years, much later than they expected.
    - 0xbadcafebee 1y ago
      If Ford makes a 4-door passenger car, and then comes out with a 2-door sports car, and keeps producing both cars, that's not a breaking change. It's just a new car. Perl 5 is still supported, Perl 6 (Raku) continues independently.
  - aaronbaugher 1y ago
    It's unfortunate that that wasn't clear to people who weren't closely involved with Perl at the time. So many people got the impression that Perl 5 was outdated as soon as 6 was in development, so they thought they had to move on from it. It's too bad Raku didn't have a different name from the start.

6031769 1y ago

Yes, we mostly use Perl for new software. If you let your codebase get into an "ancient" state then that's a problem of your own creation rather than that of the language or system in which it is written.

kosolam 1y ago
I’m very curious to hear your experience building greenfield projects with perl today. And what are the main advantages you feel that you get from it?
- doublerabbit 1y ago
  For my company, it's cross-platform and just works. It's file & data capabilities are powerful enough to deal with lots of miniature sized files from the renderer. Perl just hovers them up and does whatever processing. We did test Python but it just felt clunky in it's habits and felt lacking in terms of performance such as stalling in building a dictionary list of files to work with. Perl may be one of the older languages, but it still holds strong. If Perl is supported for your $OS your script is guaranteed to execute. Sure, adjustments may have to be made if you're targeting the underside of the rainbow such as Windows but it's trivial for *nix hosts. Migrating from Ubuntu to Debian, BSD? -- 99.9% chance your script will run. I am bias, in that their isn't anything majority wrong with perl. It was used as the main language back in the 80's for a reason and Perl's ecosystem (cpan) is still pretty comprehensive and still holding weight. As it's not taught anymore due to newer trends this is causing it's shine to dull and it's overall presence dropping away. I wouldn't disagree that new languages boast optimism in to the future of programming technologies but with perl it has been battle tested and just works.
  - sundarurfriend 1y ago
    > Sure, adjustments may have to be made if you're targeting the underside of the rainbow such as Windows but it's non-trivial for *nix hosts. The rest of your comment makes me think the "non-trivial" was a typo and meant to be something else.

daneel_w 1y ago

I maintain and develop the back-end of a telecom services provider. It's almost 100% Perl, and once in a blue moon when we add something entirely new we usually stick with Perl.

polytely 1y ago

I've actually started using raku for hobby projects recently (my day job is C#) and it is actually really fun to write.

SoftTalker 1y ago

How good are LLMs at writing Perl? I've tried to use Perl a few times, even being pretty conversant with shell scripting, sed, awk, etc. I found Perl to be difficult because it's so full of idioms that you "just have to know" and (to me anyway) TIMDOWTDI actually makes things harder for a new/learning perl developer. What I want is TITBWTDI (this is the best way to do it).

doublerabbit 1y ago
Not bad. At my last gig we had a modernization project where we were converting Perl to Python and the company invested in their own self-hosted co-pilot. (Bank) It would hiccup where it would write the existing perl codebase in to a hallucinated python syntax but this was two years ago.
johnisgood 1y ago
Claude seems to fare well. I have used it for a couple of existing and new projects written entirely in Perl. LOC was below 2k per project.
cestith 1y ago
Check out Modern Perl. It won’t limit you to one best way for everything. It will give you one best way to do many things, and a smaller set of good ways to do others. https://isbn.nu/9781680500882 https://isbn.nu/9781680500882 Keep in mind though that the current state of Perl includes being in the process of getting a native object model baked into the language core. So that’s still in some flux but it’ll be better than choosing among eight different external object model libraries. It’s also more performant. The docs for that I’m not sure are in a bound paper book anywhere yet, but I’d happily be corrected.
- chromatic 1y ago
  I'm not aware of any published books yet, but I'd like to publish a 5th edition of Modern Perl sometime, and it will include the native object model.
Enk1du 1y ago

G3rn0ti 1y ago

I am working for a company maintaining an enterprise grade software system that is primarily driven by Perl 5 and Postgres. It generates about EUR 50 million in revenue every year. To avoid creating new Perl code from scratch we created a REST API many years ok which new frontends and middlewares use instead of interacting with the core itself. That has been successful to some extent as we can have frontend teams coding in JS/TypeScript without them needing to interact with Perl. But re-writing the API‘s implementation is risky and the company has shied away from that. Fixing API bugs still require to dive into a Perl system. However, I found it easier turning Python or JS devs into Perl devs than into DB engineers. So, usually, the DB subsystem bears the greater risk and requires more expensive personnel.

autoexec 1y ago

Perl is still what I reach for when I have a regex heavy task. At my job there's a near 50/50 split between python and perl scripts. I've re-written some of the perl used for general sysadmin tasks in python too, but I haven't seen enough benefit to justify doing more. It works. Plus, in my opinion, perl is more fun to write.

nailer 1y ago
> Perl is still what I reach for when I have a regex heavy task. That's the point of PCRE though - you get Perl's excellent regex implementation in more places.
- autoexec 1y ago
  It's not usually that there are features I need which python doesn't support, it's just much more cumbersome to use in python compared to perl where it's part of the language and can be used just about anywhere without even adding another import.
  - macintux 1y ago
    The friction difference between "part of the syntax of the language" and "have to use this library" is enormous.
    - bornfreddy 1y ago
      Enormous like "import re"? It is still part of core python.
      - macintux 1y ago
        Yes. When writing a Perl script, there's literally zero friction to using regular expressions because they're baked in. I just type what I want to run. When writing a Python script, I realize I want a regular expression, and I have to stop the code I'm writing, jump to the top of the file, import re, go back to where I was. Now, maybe I'm writing a quick script and I don't care about tidiness, and I only have to stop what I'm doing, put "import re", and then write the code I want, but still, I'm stopping. Or I'll wait until I've written the code I want, and go back and put it in. If I remember. If not, I'll find out when I run it that I forgot it. Or my IDE will show me in red ugly squigglies that I need to right click or hover, and there'll be a recommended solution to import it. This is all friction that isn't there with Perl.

0xbadcafebee 1y ago

Python is only 3 years younger than Perl, should we throw Python away? (actually, I'm on board...)

2OEH8eoCRo0 1y ago

Perl is outstanding, I wish more things used it!

weare138 1y ago

Yes. I do. Just in case anyone doesn't know Perl has been in active development and has been adding new features the entire time. It was never 'dead'. This is Perl's new OO interface that was recently added as a stable feature in 5.40: https://github.com/Perl-Apollo/Corinna https://github.com/Perl-Apollo/Corinna

perigrin 1y ago
It's still considered an experimental feature, just as it was in 5.38.x. Also the linked documents aren't 100% reflective of what's been implemented so far, a better URL would probably be https://perldoc.pl/perlclass https://perldoc.pl/perlclass.

petesergeant 1y ago

Generally only places that have a large amount of existing Perl and Perl developers. It’s a fine language with a strong ecosystem but even most Perl shops have a second backend language these days. I would happily use it again, but the only compelling reason to write new stuff in Perl is if most of your existing stuff is.

77pt77 1y ago

Well, I assume this is for Perl 6 that never really caught on.

oofbey 1y ago

The TIOBE index says Perl is currently the #11 most popular programming language (up from #30 a year ago). ref: https://www.tiobe.com/tiobe-index/ https://www.tiobe.com/tiobe-index/ Now, I don't actually believe this, because that puts Perl way ahead of Rust (currently at #18). So the big thing I'm taking away from this little research post is that I no longer trust the Tiobe index. Too bad - it felt pretty reliable for a long time.

leejo 1y ago
Which is more believable or surprising: a) there is probably several orders of magnitude more Perl code running out there in the wild than Rust? b) the TIOBE index was ever meaningful?
- oofbey 1y ago
  I'm sure (a) is true. But TIOBE is supposed to be some balance between "total mass of existing code" and "current interest in new code".
petdance 1y ago
I suggest that there are no meaningful conclusions to be gleaned from the TIOBE rankings.