PetaMem

pperl 0.6.25 is released; the changelog has the complete record: https://perl.petamem.com/docs/eng/changelog/index.html. Until now pperl showed what it could do: a feature here, a module there, a benchmark won. This release is measured against what others need. The internal libraries and software suites of PetaMem and PetaJoule run on pperl in full, and of the 500 distributions the rest of CPAN stands on, all but three pass - 99.9% of the CPAN River by weight.

Our own customer

The first question to ask of a runtime is whether its makers use it themselves. We do. The libraries and software suites of PetaMem and its sister company PetaJoule run on pperl now, in full: not a demo subset, the code our products are made of. If nothing else, one goal is reached: we are our own best customer. As far as we know, also our only one - which is what the rest of this post is about.

"Run" means they work on pperl, not that they run on it in production. Nor do we recommend that anyone switch yet. Childhood is over for pperl; mature it is not yet. An adolescent, for sure.

What came of running them, a unification of everything we have into one framework and a set of applications on it, has a post of its own.

The CPAN River

Our code is one customer. CPAN is everyone else's. MetaCPAN records for every distribution its river: how many distributions depend on it, directly or indirectly. perl itself is at the source, Exporter and ExtUtils::MakeMaker right behind it; a module nobody requires is at the mouth. We took MetaCPAN's top 500 by that number, as of 2026-10-15, and dropped perl, which is the interpreter and nothing to install. That leaves 499.

A distribution passes in one of two ways. It is built in: the binary carries its main module, as it carries perl's own library and the CPAN modules pperl brings with their compiled parts. Or it is installed: pperl --cpan downloads it, configures and builds it, runs the distribution's own test suite under pperl and installs it. A failing test is a failing distribution. Every run sees nothing but the binary and what --cpan installs itself - no PERL5LIB, no system perl's library, no ~/perl5 - because a module a system perl installed would make a distribution look as if it worked.

A distribution's weight is its river number, and the share is the sum of the weights with that verdict over the sum of all 499. Counting rows, a leaf weighs as much as Exporter; weighted, the three that fail are a tenth of a percent of what CPAN rests on. The sum is not a number of distributions, since dependents overlap. MetaCPAN's live figures for perl's own modules have moved since our snapshot, so a reader checking today will see other numbers there; ours are all from 2026-10-15. The installed 374 include the names a reader will look for: Moose, Moo, Type-Tiny, DateTime, Try-Tiny, libwww-perl, Plack, Mojolicious, Catalyst-Runtime, Dist-Zilla, Template-Toolkit, PPI, WWW-Mechanize.

JavaScript::QuickJS runs on the QuickJS-NG library (libqjs.so.0, the quickjs-ng package on Arch Linux), which pperl does not bundle. Without it, JavaScript::QuickJS and Data::Sah::Coerce still install; their JavaScript tests skip and say why, and the 99.9% holds either way.

What it took

Most of it was not Perl the language. A distribution does not only run, it inspects the machine it is installed on, and it believes the answers.

• It asks for a compiler. Moose, and Catalyst and Dist::Zilla on top of it, check for a working C compiler before they install. pperl runs no XS, so the check answers yes exactly when the compiled part the distribution needs is built in - Moose's, Package::Stash::XS, List::MoreUtils::XS, Params::Util, JSON::XS, YAML::XS, FFI::Platypus and others, each passing its own test suite with the results it has under perl.
• It tries its C and falls back to Perl. DateTime and many more try their compiled part and go on in Perl when it is missing, but only on perl's exact message for that, "Can't locate loadable object". pperl gives that message now.
• It offers a Perl-only build. Params::Validate and others ship a Perl implementation beside the compiled one. pperl --cpan asks for it, as PUREPERL_ONLY=1 does.
• It has no Perl form at all. For a dozen such distributions pperl --cpan fetches a substitute of ours that does the same work in Perl or through pperl's built-in modules, among them Text::CSV_XS and JavaScript::QuickJS. Substitutes come from our server at install time, so one published after your pperl applies to it too.
• It reads the library as files, as Pod::Find and Module::List do, hooks @INC, as Test::Without::Module and FatPacker do, and reads -v and %Config, as the tests of IPC::System::Simple and installed scripts do. Each of these is answered as perl answers it.

None of these is a feature. Each is a place where pperl must be perl as a program finds it, not only as a program runs on it.

The three still failing are XML-LibXML, YAML-Syck and XS-Parse-Keyword: C written against perl's internals, with no Perl form. All are being worked on. No dates.

Getting pperl

A binary to download is what pperl has been so far. That is the next thing to change: the first step is a perlbrew that keeps several perl implementations side by side - perl, jperl, pperl - and after it containers, distribution packages or AppImages, whichever turn out to serve. No dates.

Statistics

pperl 0.6.25 represents approximately 14 days of development since 0.6.23 and contains approximately 2,880,000 lines of changes across 35,000 files from 1 author.

Excluding auto-generated files, documentation, assets, vendored modules and tooling, there were approximately 161,000 lines of changes to 1,800 .rs, .pl, .pm and .t files.

Get 0.6.25 here: https://perl.petamem.com/

• Richard C. Jelinek, PetaMem s.r.o.