Hacker News Reader

Comment by lordofgibbons | Hacker News Reader

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.

View on HN

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.

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.

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?

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.

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

My bad, I got the two mixed. I meant trivial where by it's dead simple to switch over. Thanks for the pointer.

The experience is all good. The toolchain, the speed of both development and execution, the breadth of CPAN and the famous backwards-compatibility all make for a happy development team.

The advantages are the same as they have been for years: cross-platform compatibility, one system to run all aspects of a large project, the flexibility to get the job done in the simplest, most efficient and most maintainable manner.

One caveat: we don't do any MSWin32 development at all. I'm vaguely aware that there are some extra considerations on that O/S but it isn't something which we have to deal with.

Sounds good, thanks. I suppose ai models are really good at generating perl?

I've been surprised. I have a coworker who has a deep industry knowledge but none of it was in Perl, he was reaching for ChatGPT a lot early on and while sometimes it wasn't how I would have written it it wasn't wrong. So I did some experiments and I asked Claude to do things like generate apps using the latest Class syntax which is only 3 years old at this point … it didn't have a problem.

Edit: well it occasionally had a problem where it would confuse things for Moose or Raku … but by and large it wasn't wrong it's just the syntax is new. I know Perl developers who have the same issues.

I'd run from a place that wants to use Perl for new software. Run and never look back.

Whereas I'd run to such a place. I miss it.

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.

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

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.

The friction difference between "part of the syntax of the language" and "have to use this library" is enormous.

Enormous like "import re"? It is still part of core python.

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.

> stop the code I'm writing, jump to the top of the file, import re, go back to where I was.

If you're just shitting out a one off script and that's really a problem for you, you can just "import re" where you are, there's nothing other than convention and scope that forces you to import everything at the top. Given thats also a problem with sys and os, importing all the commonly used libraries and carrying that around as a template (from print import pprint, anyone?) also seems reasonable, if that's really a problem for you.

With perl you just run $foo =~ /regex/ anywhere, you can also put that into an if condition or assign the results to a variable, you can use variables like $1 and $2 (the captures) immediately after, as they are global. You can use any choice of delimiter for the regex to improve readability (i.e. you don't have to use quotes, if your regex contains a lot of quotes).

So you can do while ($foo =~ /bar/) or even ($result) = $foo =~ /bar/.

Python has only raw strings and until recently you couldn't even do if ($regex) { ... } you had to assign the match to a variable and check it, causing lots of nested if/then blocks. It's just clunkier.

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.

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

We need an ROI metric to quantify the backward compatibility and low churn of Perl relative to languages like Python, Ruby, golang.

Golang declared a perfect backwards compatibility guarantee way back when version 1 was released. So in this regard, Perl isn't unique.

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.

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.

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.

Perhaps, but code that inadvertently depends on the Hash implementation returning keys in a particular order is arguably incorrect.

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)

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)

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

And the last release was three weeks ago! Perl 5.42.0 was released July 3, 2025.

> avoiding breaking changes

Perl 6?

It was so breaking they don't even call it Perl anymore.

In fairness to Perl, that's a good reason not to consider it a breaking change.

perl 6/raku was a redesign. as far as i remember, upgradeability from perl 5 without code changes was never the goal.

Isn't that the definition of a breaking change?

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.

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.

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.

> It's too bad Raku didn't have a different name from the start.

We thought that it would take a year or two, not decades.

Also, the intent was to have a Perl 5 compatibility mode.

Looks like the last time I tried out Perl 6 was almost 10 years ago. Even wrote a few blog posts about it before giving up on it again. Might be time to take another look.

There is a Perl 5 compatibility mode: it's called Inline::Perl5.

Maybe not the one that was originally planned. But that was only a real possibility if Perl 5 would be able to get rid of its XS addiction.

Ask yourself: how many of the up river Perl modules are Perl only?

Agreed. Probably why they renamed it. I think everybody probably wishes they'd taken a new name from the start.

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

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.

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

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.

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.

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

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.

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.

I quite enjoyed Perl Best Practices[0] for the rationales behind every decision, most of which I could get on board with. Plus, if you really like it you can auto-reformat code with perltidy[1] using the "--perl-best-practices" flag or check your files with Perl::Critic[2] policies based on PBP.

It's dear to me because it came along at a time when I needed short breaks from thesis writing.

  [0] https://www.oreilly.com/library/view/perl-best-practices/0596001738/
  [1] https://metacpan.org/dist/Perl-Tidy/view/bin/perltidy
  [2] https://metacpan.org/pod/Perl::Critic

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

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/

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.

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?

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

I suggest that there are no meaningful conclusions to be gleaned from the TIOBE rankings.

Perl is outstanding, I wish more things used it!

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.

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

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

Reply on news.ycombinator.com