March articles on beautiful Perl features
Continuing the dev.to series about beautiful Perl features, here are the recent articles (March 2026) :
Continuing the dev.to series about beautiful Perl features, here are the recent articles (March 2026) :

Two weeks ago we posted "PDL in Rust - A Native Reimplementation of the Perl Data Language". At the time the score was 45 tests, all green. That was enough to say "it compiles, it runs, here is the arithmetic surface." It was not enough to say "you can use this."
We are now on the second number. The current PDL implementation in pperl covers roughly 3,000 assertions end-to-end: about 1,400 on the Perl-facing connector side and about 1,600 on the engine side. As of this writing roughly 98% of the connector assertions match upstream PDL 2.103 exactly, and most of the remaining couple of dozen we already know why they fail. By the time you read this the numbers will have drifted a little in our favour - give or take - but the shape is the point, not the decimal.
Everything described below is shipping, today, at https://perl.petamem.com.
We were all present.
Modern software distribution has converged on a simple idea: ship a self-contained artifact. Whether that means a statically linked binary, a container image, or a snap/flatpak, the benefits are the same -- dependency management is solved at build time, platform differences are absorbed, and upgrades and rollbacks reduce to swapping a single file.
Perl's App::FatPacker
applies the same principle to Perl scripts. It bundles every pure-Perl
dependency into a single executable file. No cpanm, no
local::lib, no Makefile on the target -- just copy the file
and run it. The technique is well-established -- cpm (the
CPAN installer we use in the build) is itself distributed as a fatpacked
binary.
The distribution pipeline looks like this:
Code repo --> CI --> fatpack --> deploy --> laptops / jumpboxes / servers
|
single file,
no dependencies
Finally - GTC 2.0, an all in one color library, is released ! This post will not be rehash (of) the (very) fine manual, but give you a sense what you can achieve with this software and why it is better than any other lib of that sort on CPAN. If you like to look under the hood of GTC, please read my last post.

A few days ago, when we announced pperl's native module strategy on Reddit, someone asked about PDL support. We replied: "PDL will be supported." — to which u/fuzzmonkey35 responded: "We will live in glorious times when this happens."
Well. It happened.
We (as in: we and our AIs) reimplemented PDL (the Perl Data Language) from scratch in Rust — not a binding, not an FFI wrapper, but a ground-up reimplementation of the core engine. 15 data types, N-dimensional arrays, broadcasting, operator overloading, reductions, linear algebra, transcendental math — all in pure Rust, integrated as a native module into our pperl next-gen Perl5 platform.
use PDL; my $a = pdl([1, 2, 3]); my $b = pdl([10, 20, 30]); say $a + $b; # [11 22 33] say ($a * $b)->sum; # 140 say sin(pdl([0, 3.14159/2, 3.14159]));
45 tests, all green. Same Perl syntax. No XS. No C. No libpdl.
All three of us attended.
We discussed policy questions that were turned up by the recent submission of some LLM-generated PRs. We need to hold conversation about this among the Core team. No contributions of this kind will be accepted while the discussion is still ongoing.
We finally had a good chunk of time to spend on release blocker triage. We made quick progress, working through half our list and closing some issues in the process. We newly marked 4 issues as blockers.
Cross-posted from my blog
Last week, the Perl community came together for the 28th German Perl Workshop. This year, it was held at the Heilandskirche in Berlin Moabit. Excitingly, we had the nave for the presentations.
While the name is still German Perl Workshop, we now draw attendees from all over the globe. Presenters came from India, the US and various European countries. Maybe it is time to announce it as a more international conference again.
Available now from my Wiki Haven: Perl.Wiki.html V 1.42 & the JSTree version.
Also, I've uploaded to CPAN 2 modules:
1: CPAN::MetaCurator V 1.13
2: CPAN::MetaPackager V 1.00
Q & A:
1: What is the relationship between these 2 modules?
CPAN::MetaPackager's scripts/build.db.sh inputs
a recent version of the Perl file 02packages.details.txt,
and outputs an SQLite file called cpan.metapackager.sqlite (15Mb).
The latter ships with the module.
Future versions of this module will use the differences between the db
and newer versions of 02packages.details.txt to do the usual thing of
add/change/delete entries in cpan.metapackager.sqlite.
2: CPAN::MetaCurator's scripts/build.db.sh inputs
an JSON export from Perl.Wiki.html called tiddlers.json,
and outputs an SQLite file called cpan.metacurator.sqlite (15Mb).
The latter ships with the module.
Then scripts/export.tree.sh outputs a file called cpan.metacurator.tree.html.
This latter file is a JSTree version of Perl.Wiki.html, as mentioned above.
Note: By setting the env var INCLUDE_PACKAGES to 1 before you run export.tree.sh
the code will read the cpan.metapackager.sqlite table 'packages' and that changes
the output tree a bit, since the code then knows the names of modules released
to CPAN.
We took PetaMem's 13-year-old Lingua::* number conversion modules - dormant since 2013 with 17 languages - and brought them back to life. The suite now covers 61 languages across 7 writing systems (Latin, Cyrillic, Arabic, Devanagari, Armenian, Hebrew, CJK), including all 24 EU official languages plus Latin, Hindi, Yiddish, Mongolian, Uyghur, and more.
New in this release: cross-language numeral arithmetic with overloaded operators, ordinal support for 14 languages, capabilities introspection, and a Galois-field-based transitive test that walks the entire number space across all languages - 5000 steps, zero failures.
my $a = Lingua::Word2Num->new("zwanzig"); # German 20
my $b = Lingua::Word2Num->new("šestnáct"); # Czech 16
say ($a + $b)->as('fr'); # trente-six
say ($a + $b)->as('la'); # triginta sex
Everything on CPAN: cpanm Task::Lingua::PetaMem
A small group of volunteers continue to maintain the DBD::Oracle driver without any sponsorship or funding.
Who have curated yet another dev release which has hit the CPAN in the form of v1.91_5 - probably the last dev release before a new version.
It has grown to be quite large so will probably be released as 1.95 or something to give it some distance from the last release. For that same reason I am hoping for anyone using DBD::Oracle in their stack to help us test it out.
Given the nature of Oracle it is very challenging to exhaustively test it, despite having quite a respectable set of unit tests. There are several current supported OS and architectures, and supported client and server versions, on top of Perl versions. Plus all the historical OS and architectures (and client and server and Perl versions) which are still running in production. Support for which is as I mentioned entirely up to volunteers and folks sending in fixes or enhancements.
All three of us attended this long meeting covering quite a bit ground:
On Jan 10th I had said in a post here, that perlmodules.net 's update (to use the new metacpan API) would take 1-2 weeks.
It took 1-2 months. (two in fact)
Now it's up again.
Sorry.
Huge congrats goes to Olaf A. for fixing my code.
Bye.
Note to perlmodules.net's users: Since you must have gotten a ton of emails from the website today regarding all the CPAN module releases that have occurred in the past 2 months, you are advised to check also your spam folder, since some of the emails might have ended there by your mail provider (it might have misinterpreted the deluge of incoming mails as spam). Please move them from the Spam folder to your inbox if you can, to prevent perlmodules.net from being blacklisted as a spammer (not 100% sure that's how blacklisting works, but anyway). Thanks.
We're thrilled to announce the release of Dancer2 2.1.0! This release represents a major investment in the health and quality of the project. We've gone deep into the issue tracker and PR backlog, closing out some of our oldest open issues — some dating back years — and significantly grooming both the issue and pull request queues. A big thank you to everyone who contributed.
This release addresses a number of long-standing issues:
All three of us were present for a quick meeting.
We discussed the progress of our outreach to some potential new core team members. We will be holding a vote once we hear back from everyone.
We noticed that a minor step in the PSC transition was missed during this cycle. We agreed that there needs to be a checklist for the procedure, and we intend to write it up.
We started with the release blocker triage, but the meeting was short so we didn’t look at many issues. We have no candidate blockers so far.
I'm hoping to reach anyone using Protocol Buffers in Perl, soliciting their experiences and best practices.
A Googler is soliciting help on an official set of bindings just this year. Which is great!
There seems to be Google::ProtocolBuffers which is now 10 years old - I suspect it is not a good choice.
The Google::ProtocolBuffers::Dynamic seems like the best choice right now but wont compile for me on Debian Trixie. I haven't gone too deep in to why, but upb seems to be on a branch, is old, and fails to compile.
A colleague recently just for fun had Claude create a pure perl library that passes all the tests and dropped it on github.
I ask as have been experimenting with protoconf which builds on protocol buffers.
Related. I do like Thrift a lot and it seems to be maintained which is nice, but it seems to have failed to gain traction.
The "Beautiful Perl features" series on dev.to continues !
Since my last announcement, the following articles have been added :
I'm still hoping to attract interest from people from other programming cultures, but so far most comments came from people already in the Perl community. Let's see what the future brings us!
The more I investigate into various programming features, the more I'm impressed by the Perl vision: the initial design and later evolution into Perl5 were incredibly innovative and coherent. Raku is even more impressive, but that's another story. Regarding Perl, I am tired of reading comments on so many platforms that the language is "ugly" and "write-only" -- this is not true! If this dev.to series can help to reverse the trend, I will be happy :-)
After two weeks of various people absent on various travels, we got the band back together for a fairly adminstrivial meeting.
Contentious changes freeze has set in, so we will now be monitoring for release blockers. We took stock of the currently open issues and PRs from this release cycle and will be triaging for blockers in the coming weeks.
We need release managers for two more dev releases and the final. Paul will probably take over one of the dev releases. We are figuring out the rest.
blogs.perl.org is a common blogging platform for the Perl community. Written in Perl with a graphic design donated by Six Apart, Ltd.