Section · language decisions
Every comparison here is scoped to one job with stated constraints. Dimensions are explainable
and carry a confidence level. Where we have no basis, the dimension says none
instead of inventing a lean.
The format
What it is good for
Five bands, sixteen real task shapes. Open one to see why it sits where it does and what to weigh against it. The bottom two bands exist because a page that only lists strengths is advertising.
▰▰▰▰ Strong fit ▰▰▰▱ Reasonable ▰▰▱▱ Contested ▰▱▱▱ Poor fit ▱▱▱▱ Wrong tool
Strong fit
The work is shaped like the language. Choosing Perl here needs no argument beyond the code itself.
Extraction, substitution and reshaping are the operations the language was designed around. A binding operator returns captures directly; there is no match object to unpack and no import to remember.
Nothing, if the transformation is regex-shaped. Once the output grows into validated records, re-read the comparison below.
Unattended glue is judged on what happens in two years. Perl 5 is on effectively every Unix host, a single file has no dependency tree to rot, and you get real data structures the moment shell quoting stops being adequate.
Shell, if the job genuinely is three commands and a pipe. A compiled tool, if the host might not have perl — which is increasingly true of minimal container images.
One line, no script file, no temporary directory, and a backup extension if you want one. This is the case where a one-liner is not a party trick but the professional choice.
sed for the simplest substitutions. Anything with lookahead, named captures or conditional logic belongs in Perl.
Normalising addresses, comparing query signatures, following redirect chains and reasoning about link graphs — string work with structure, which is exactly the intersection Perl sits on.
Nothing, for the analysis. A headless browser, if the pages render their content client-side.
Reasonable
Perl does this well. Whether you should is usually a question about your team rather than about the language.
Mojolicious is a complete framework with no non-core dependencies, and PSGI decouples the application from the server entirely. The honest limit is organisational: the pool of people who will maintain it is smaller.
Your team's primary language, if the service is greenfield and nothing else nearby is Perl.
Reading structured input and emitting formatted output is what Perl 1.0 existed for. Template::Toolkit and Mojo::Template are both mature.
A reporting tool, if non-engineers need to change the output.
Nested data, error handling beyond exit codes, and code that survives an OS upgrade without a rebuild.
Ansible or similar, if the work is configuration management rather than logic.
Contested
Genuinely arguable. Anyone who tells you this one is obvious has not stated their constraints.
If your users must not think about a runtime, a single static binary wins the argument before any code is written. If your users are sysadmins on hosts that already have perl, that advantage evaporates.
Go or Rust when you ship to strangers. Perl when you control the hosts.
A transformation that stays regex-shaped stays comfortable. One that grows into validated, versioned records starts wanting a type system and a validation library.
Python, if the output schema is going to keep growing. Perl, if the shape is stable and the host is locked down.
Perl rewards conventions — strict, warnings, named subs, no clever punctuation variables — and punishes their absence more visibly than most languages. With them it reads fine. Without them it becomes the stereotype.
Whatever your team already reads fluently. That is not a cop-out; it is usually the correct answer.
Poor fit
The language can do it. The ecosystem around it cannot, and you will feel the absence daily.
Dataframes, statistical modelling and plotting are not where Perl's ecosystem went. Choosing it costs you libraries you will actually need, and no amount of language quality compensates.
Python or R. Perl still fits upstream, preparing the data before it reaches the analysis.
Training, inference and the tooling around them live elsewhere. There is no version of this argument where Perl wins.
Python.
Mojo::UserAgent handles static fetch and DOM selection well. Driving a real browser engine is where the tooling ecosystem is decisively elsewhere.
Playwright or Puppeteer, in a language they support first.
Wrong tool
Not a tradeoff. Listing these is how the rest of the scale stays credible.
Frontend code runs in a JavaScript engine. This is a platform fact, not a preference.
JavaScript or TypeScript.
There is no maintained route to a shipping iOS or Android application.
Swift, Kotlin, or a cross-platform framework.
Packers exist and are fragile. If a single self-contained artefact with no interpreter is a hard requirement, that requirement has already chosen the language.
Go, Rust or C.
Published
One published, two commissioned. The in-progress entries are listed with their real status, not hidden until launch day.
Read a mixed-format access log from stdin, extract five fields, normalise timestamps to UTC, drop bot traffic and emit newline-delimited JSON — as one file a colleague can run with no build step. Both implementations are on the page. The deciding factor turns out not to be the language.
Editorial check · 5 dimensions · 3 limitations
The comparison where deployment, not language ergonomics, decides the answer. Not published — this is the backlog entry, listed so you can see it exists.
Where shell quoting stops being adequate, and what you give up by moving. Not published.
The most useful submissions name a task precisely enough that two implementations can be judged against it. The second most useful are corrections to a dimension we got wrong.