All three of us showed up to a shorter meeting that dealt entirely with triage. Last week’s new blocker was resolved in the meantime, but we had a few new small ones show up, which we merged fixes for. The last-minute IO::Compress release has needed some oopsie fixes. Another release candidate is inevitable and will be shipping this week.
I'm pleased to announce the release of perl-lsp version 0.6.0; you can install it from Github releases, from crates.io via cargo install perl-lsp, or as a vscode or vscodium extension. If you are a zed user, you can opt in using the zed-perl extension following these instructions.
The tech world is experiencing an identity crisis. Pundits are shouting from the digital rooftops that traditional coding is over, replaced by natural human language interfaces. They're calling it a radical new paradigm.
But if you've been paying attention to Perl since 1987, you know this isn't a revolution--it's a homecoming.
When Larry Wall created Perl, he didn't just build a language to sit closer to the metal; he built it to sit closer to speech. While computer science worshiped at the altar of rigid mathematical purism, Perl introduced a context-aware structure built on nouns, verbs, singulars, and plurals.
Today, Large Language Models operate entirely on probability, semantics, and context. We've spent decades forcing humans to think like transistors; now, we've successfully forced silicon to learn human.
Perl programmers are uniquely wired for this future. We've spent forty years treating programming as an exercise in linguistics and context.
The community isn't fading into the past; it's providing the blueprint for what's next. Case in point: The Public Enrichment and Robotics Laboratories (RoboPerl) are currently engineering PerlGPT--a model trained specifically to understand best practices, architectures, and the nuanced wisdom of "Perl poets."
The future of engineering belongs to those who can speak fluent intent.
👉 Watch Randal's full talk on how structural context is dominating the modern landscape: https://youtu.be/hAd6MHXrdh4
A new blocker appeared. It is only just impactful enough to register, but unfortunately not negligible enough to ignore. We will attempt a resolution before we consider other options.
There has been some more activity in the LLM policy discussion, where we didn’t get around to posting our thoughts last week. We will rectify that.
Last month saw the official announcement of The Raku Foundation,
including an invitation to every member of the global Raku community to register
their interest in the organization and become members, with the right to vote on its leadership,
policies, and activities. Once again, I would encourage everyone who loves Raku
to do exactly that.
I've been working on a CPAN module called JSON::JSONFold, and I wrote an article describing the motivation and design. I'd really appreciate feedback from other Perl developers.
JSON serializers tend to give us two choices: compact JSON, which is efficient but a dense wall of text that's painful to read, or pretty-printed JSON, which is readable but often wastes a lot of vertical space (a small array of numbers can turn into ten lines).
I wanted something in between. JSONFold keeps the shape of pretty-printed JSON, but folds small, simple structures back onto a single line whenever that improves readability. It works on top of your existing serializer (JSON, JSON::PP, JSON::XS, etc.) - you keep using whatever you already have, and JSONFold just reformats the output.
If you're like me, you use a constant a lot (I may overuse it). I often use it to turn typos in words and fields into compile-time errors, and for that I usually create constants that either are the named the same as the word, or the word uppercased, like this
use constant +{ SERVICE => 'Service', INSTANCE => 'Instance' };
GTC 2.20 brings a huge amount of new features again (described in this post) and is starting an additional, more trimmed down, high level API, geared more toward what designers expect. But it also comes with new documentation and error handling, the two most important things that were missing for a professional distribution.
So I've created a programming language which blends a fairly JavaScript-like syntax with fairly Perl-like semantics, and a few other features that I haven't really seen in many programming languages.
This Perl:
use Path::Tiny;
my $str = uc(substr(Path::Tiny->new("myfile.txt")->slurp_utf8, 0, 80));
Becomes this in ZuzuScript:
from std/path import Path;
let str := new Path("myfile.txt")
▷ ^^.slurp_utf8
▷ ^^[0:80]
▷ uc ^^;
The ▷ operator means "evaluate the left side, then evaluate the right side with ^^ set to the result of the left side". It's conceptually similar to | in shells and seems to make a lot of expressions so much easier to understand.
Then here is a reminder that in light of current events you will want to update your account to use a different email address. (There are about 130 of you that get to jump through this hoop now.)
This post is the first in a series that will follow my re-development of the Devel::ptkdb debugger. This post explains the beginnings of my involvement with the Perl Tk debugger.
I was once again privileged to be able to attend this year's Perl Toolchain Summit. This is the 13th year (in a row if you discount the Covid years) that I have been able to attend and it is the technical highlight of my year.
This year the event was held in Vienna and, for the first time, my wife accompanied me. We took a direct train from Zürich to Vienna and had a wonderful trip through the glorious Swiss and Austrian countrysides.
We arrived fairly late on Wednesday evening so didn't meet up with anyone then, but we saw a few of the other attendees at breakfast the next morning, and then I set off for the venue where I met up with everyone else, heard BooK's opening speech, took part in the introductions and then split off into a room with the MetaCPAN group with whom I spent about half of my time. Meanwhile, my wife set off to explore Vienna.
A quick summary of what I got up to at PTS 2026 in Vienna.
Test::Smoke's long-term future. I had several useful discussions with H. Merijn Brand (Tux) and Todd Rinaldo (toddr) about keeping Test::Smoke maintainable for the long term. This tied directly into the MetaCPAN hosting migration below: DigitalOcean offers managed Postgres, Hetzner doesn't, and Test::Smoke's existing database usage wasn't especially efficient. The outcome was toddr starting a rewrite that runs as a single container backed by SQLite and local files -- much more portable and easier to operate.
Migrating MetaCPAN from DigitalOcean to Hetzner. I spent a big chunk of the summit pairing with Shawn Sorichetti (hide) on the migration, including reorganising our Kubernetes setup so it deals more cleanly with multiple environments. Shawn was making a large number of changes; I focused on reviewing them quickly so we could iterate fast.