Skip to content(if available)orjump to list(if available)

What Killed Perl?

What Killed Perl?

58 comments

·November 19, 2025

autarch

As a very long-time Perl developer and FOSS contributor, I think this blog post is incorrect about whether Perl 6/Raku was a factor in Perl's decline. I think Perl 6/Raku did a few things that hurt Perl 5:

1. It pulled away folks who would otherwise have spent time improving Perl 5 (either the core or via modules).

2. It discouraged significant changes to the Perl 5 language, since many people figured that it wasn't worth it with Perl 6 just around the corner.

3. It confused CTO/VP Eng types, some of whom thought that they shouldn't invest in Perl 5, since Perl 6 was coming soon. I've heard multiple people in the Perl community discuss hearing this directly from execs.

Of course, hindsight is 20/20 and all that.

Also, even if Perl 6 had never happened the way it did and instead we'd just had smaller evolutions of the language in major versions, I think usage would still have shrunk over time.

A lot of people just dislike Perl's weird syntax and behavior. Many of those people were in a position to teach undergrads, and they chose to use Python and Java.

And other languages have improved a lot or been created in the past 20+ years. Java has gotten way better, as has Python. JavaScript went from "terribly browser-only language" to "much less terrible run anywhere language" with a huge ecosystem. And Go came along and provided an aggressively mediocre but very usable strongly typed language with super-fast builds and easy deploys.

Edit: Also PHP was a huge factor in displacing Perl for the quick and dirty web app on hosted services. It was super easy to deploy and ran way faster than Perl without mod_perl. Using mod_perl generally wasn't possible on shared hosting, which was very common back in the days before everyone got their own VM.

All of those things would still have eaten some of Perl's lunch.

hylaride

I think this is mostly the correct take. Perl's strength is that it was really good and quick and dirty one-offs, especially with text manipulation. This made it particularly popular with UNIX sysadmins and sometimes network admins. This was helped by the fact that CPAN made it easy to share a lot of these, which added to its popularity (it can't be overstated how revolutionary CPAN was).

The 1980s/1990s was full of many different data formats in a time before XML/JSON, often by long dead companies. Many a tech person was in a situation where "Oh fuck, how do I get this data out of some obscure database from some dead company from Boston that only ran on SCO UNIX into SAP/Oracle/etc" only to see somebody else already done it and made a CPAN module.

But stories like that became less common as DBs converged into a few players.

runjake

I was a Perl programmer from the early 1990s until into the 2000s and I mostly agree with you. It was a variety of factors.

The point where I disagree is I think Perl 6/Raku played a significant role in Perl's decline. It really gave me the perception that they were rudderless and that Perl probably had no future.

Other than that, I absolutely loved Perl. I love the language. It's super expressive. I never took a liking to CPAN. And I wonder if it could make a comeback given better dependency management.

I think Perl with tooling similar to uv would cause me to switch back today.

autarch

> The point where I disagree is I think Perl 6/Raku played a significant role in Perl's decline. It really gave me the perception that they were rudderless and that Perl probably had no future.

I assume you disagree with the blog post, not with my comment, since this is exactly what my comment says too!

Taikonerd

I would also say -- in the late 90s, Perl's claim to fame was that it had CPAN. At the time, CPAN was revolutionary: a big, centralized repo of open-source libraries, which you could install with a single command.

Now, of course, that's a common and maybe even expected thing for a library to have: Python has Pypi, Javascript has NPM, etc.

pizlonator

Python and Ruby killed Perl.

Before Perl, there was no scripting language that could do systems tasks except maybe shell and tcl, but that's shell is an extremely unpleasant programming experience and the performance is horrid, and tcl's string-based nature is just too weird.

Perl gives you something more like a real programming language and can do shell-like tasks and systems tasks very nicely. Compared to what came before, it is amazing.

But then Ruby and Python came along and checked the "real programming language" box even more firmly than Perl while retaining the shell/systems angle. Ruby and Python were better than Perl along exactly the same axis as the one on which Perl was better than Tcl and shell.

daneel_w

> "Perl gives you something more like a real programming language ..."

It is a real general-purpose programming language, not a "scripting" language. Did you ever have a look at it?

spankalee

That's a difference without a distinction

Kye

Good luck getting any two people to agree on a sharp line between programming language and scripting language. Perl seems to swap sides depending on the year people are arguing about it.

daneel_w

In my experience those can't discern what's what are usually the ones who mainly did a bit of dabbling in either.

null

[deleted]

HeinzStuckeIt

Already in the very early millennium, jokes like “Perl is an explosion in an ASCII factory” were going around the computer-nerd community, while several publishers were putting out affordable and fun and engaging books to learn Python. No surprise that Perl quickly declined in popularity for scripting. It has been amusing to watch the continual waves of reawakened interest in awk, while Perl seems to remain perennially marginalized now.

RodgerTheGreat

The value proposition for AWK is very different from Perl. AWK is a tiny language that can be learned quickly, and it's ubiquitous: a hard requirement for even the most bare-bones POSIX environment. AWK is on your machine already; Perl may not be. If you have to install Perl, you could just as easily install any one of hundreds of alternative scripting languages.

AWK scripts don't have any kind of dependency management features, so they naturally lend themselves toward being freestanding and self-contained. Perl, on the other hand, has a massive package ecosystem with transitive dependencies and widely varied quality and design aesthetic, amplified by the baroque design of the language. AWK is as close as a language can be to immune to dependency hell.

null

[deleted]

7thaccount

It's been discussed before, but Python just seemed more straightforward to a lot of people. It had a built-in object oriented model as well when that was the rage instead of the weak default one and dozen modules on CPAN to do object oriented programming. There was generally one way to do something and that was easier to learn than TIMTOWTDI.

cestith

One of Python’s killer features is how easy it is to find a Python library wrapping some native code library written in C or Fortran. Those used to be notoriously difficult to write for Perl.

autarch

I was writing a comment asking if it was really easier. Then I took a look at Cython. Yes, this looks easier than Perl's XS, which I have some experience with! There are ways to do something similar in Perl these days, notably https://metacpan.org/pod/FFI::Platypus. But these are relatively new (starting in the 2010s) compared to the history of Perl, and Cython goes back to the early 2000s.

cestith

Somewhere in the continuum from SWIG through XS and on to Platypus there are also the Inline modules these days. They allow one to put inline sections of other languages into Perl code the way many language tools used to allow one to inline assembly into C or Pascal code.

There are some of these modules for other languages than those listed here, a lot of them as high level as Perl (including Raku and even another Perl system for some reason).

https://metacpan.org/dist/Inline-C/view/lib/Inline/C.pod

https://metacpan.org/dist/Inline-ASM/view/ASM.pod

https://metacpan.org/dist/Inline-CPP/view/lib/Inline/CPP.pod

https://metacpan.org/dist/Inline-CPR/view/CPR.pod

https://metacpan.org/pod/Inline::Lua

https://metacpan.org/dist/Inline-Java/view/lib/Inline/Java.p...

https://metacpan.org/pod/Inline::Guile

https://metacpan.org/dist/Inline-SLang/view/SLang.pod

There are even tools to convert from Inline to XS for C and C++.

https://metacpan.org/dist/InlineX-CPP2XS/view/CPP2XS-Cookboo...

https://metacpan.org/pod/InlineX::XS

HumanOstrich

I learned and used Perl professionally from around 2005-2015 and experienced first-hand the ossification, fear of change, and lack of innovation in Perl 5 development. It seems all the talent and effort started being wasted on making Perl 6 the bestest, most elegant, most useful programming language in the world. Just seeing the neglect of Perl 5 kept me from ever considering Perl 6 and motivated me to move to other languages.

jmclnx

I started learn Perl 5 right before 6 was announced. When I saw what was happening with Perl 6, I decided just to stick with sh, awk and friends.

IIRC, The Perl 6 development thing went on for a very long time and got nothing but bad press. That took the wind out of my sails.

stickfigure

Perl is powerful, expressive, and cryptic. Its popularity faded during a time when the popular trend of programming languages was towards simplicity and legibility. C++ gave way to Java and C#.

Also, Perl's strength was text processing in a world where data was moving out of simple columnar text formats and into databases, xml, json, and other formats better represented by object models than lines of text.

mono442

I think it is due to the fact that Perl has some confusing bits like those variable prefixes ($@%), the lack of function arguments (I know that this has changed recently), not really great error handling, etc and so people started using languages which seemed easier to use like Python.

throwway120385

The variable prefixes are just the tip of the iceberg. The real problem with those prefixes is that they, themselves, are context-dependent on attributes associated with the underlying data type at run time. So you can find yourself in a situation where the behavior of the syntax differs in ways that are difficult to control for during development.

mono442

Yep, there're all sorts of things like this in Perl. Its semantics has always been confusing to me.

rwky

I still use perl. It's my go to for string parsing (think pipe log file, do something with it and send it to stdout). It's also my go to for anything that I still want to work in 10 years.

woof

It was never about Perl, it was the plethora of alternatives.

Python evolved, PHP had 1000 times more "how to get started" articles, Node happened. And LAMP became the default for noobs.

HelloNurse

Personally, back when Perl 6 was harmless vaporware, I never found a place for Perl 5.

For moderately advanced text processing with regular expressions, supposedly its strong point, it was far less elegant and concise than AWK at the low end and far less readable and less batteries-included than Python for more complex tasks involving some integration.

For dynamic web pages, another of the main uses of Perl, PHP was purposefully designed and (while not really good) practical and user-friendly, with plenty of other obviously more robust and serious options (Ruby, Java, later Python, etc.) for more enterprise projects.

runjake

It sounds like Perl just wasn't your style and that's okay.

But, Perl was immensely popular, particularly in the 1990s in its 4.x/5.x days. We used it because it was precisely more elegant, ergonomic and performant than awk :-)

Later on, Python gained more traction because it was more batteries-included, and PHP evolved from being a toy named "Personal Home Page".

pjmlp

As someone that was already working during the dotcom wave, Perl is a tool I would still reach for, given the problem I might trying to sort out, if on an UNIX like platform.

> Binary package managers that chase down dependencies on their own weren’t a thing until the early 2000s, I think?

UNIX package managers started to be made available during the 1990's.

kqr

Yes, but they were either source package managers or they didn't resolve dependencies transitively, only complained about missing direct dependencies.

cafard

About a dozen years ago, I noticed that the young all seemed to know Python, and did not seem to know Perl. Given that they would be maintaining such code as I wrote and was worth keeping around, I moved to writing in Python. Now when I write Perl, I do silly things like forget semicolons.

Perl can be very well written. I deeply regret not encountering Perl Best Practices when it came out.