Dancer2 + DBIx::Class::Async + HTMX
Tech trio embrace in harmony: Dancer2, DBIx::Class::Async and HTMX.
For more information, please follow this link: https://theweeklychallenge.org/blog/dancer2-dbic-async-htmx
This week in PSC (214) | 2026-02-02
With Leon at FOSDEM it was only Paul and Aristotle this week, but the discussion ranged widely.
Sydney February Meeting! 2025
Sydney Perl continues regular meetings with our next in February
Please join us on Tuesday 24th Feb 2025 at Organic Trader Pty Ltd.
Unit 13/809-821 Botany Road Rosebery
6:30pm to 9pm.
Chances are folks will head to a nearby Pub afterward.
I will talk about my 5 years working at Meta Platforms and 6 months at Amazon Inc. specifically contrasting their engineering culture, and generally discussing what Google calls an SRE culture. Contrasting my experiences at Big Tech to "Middle Tech".
Getting there:
Come in the front door marked
"Konnect" then take the first door on the right, and up the stairs to
Level 1.
Mascot station + 20 minute walk or 358 bus to Gardener's Road if you
don't want to walk so far.
Or Waterloo Metro station + 309 bus to Botany Road after Harcourt Parade.
ANNOUNCE: Perl.Wiki V 1.39 & Mojolicious.Wiki V 1.13
Get them, as always, from my Wiki Haven.
Evolution of DBIx::Class::Async
How do you make the world’s best Perl ORM non-blocking without rewriting your entire schema? Find out the answer in this post: https://theweeklychallenge.org/blog/dbix-class-async-evolution
A new sponsorship model
Last year, I wrote that the total cost of a Perl Toolchain Summit is in the order of 50,000€. It's all covered by sponsors and attendees (and the leftovers from the previous years).
We're now preparing the Perl Toolchain Summit 2026, which will be held from Thursday, April 23rd until Sunday, April 26th, in Vienna, Austria.
Today, I'll briefly explain why we need sponsors for the event, and propose a new way to think about sponsorship to our corporate sponsors.
This week in PSC (213) | 2026-01-26
All three of us discussed:
- We agree with the general idea of an improved PRNG, so we encourage Scott to continue working on the PR to get it into a polished state ready for merge
- Haarg’s ”missing import” PR now looks good; Paul has LGTM’ed it
- TLS in core still remains a goal for the next release cycle.
Crypt::OpenSSL3might now be in a complete enough state to support a minimal viable product “https” client to be built on top of it, that could be used by an in-core CPAN client
Call for proofreaders : blogging on beautiful Perl features
Hi fellow Perlists,
Now that I am retired, I have a bit more time for personal projects. One project dear to my heart would be to demonstrate strong features of Perl for programmers from other backgrounds. So I'm planning a https://dev.to/ series on "beautiful Perl features", comparing various aspects of Perl with similar features in Java, Python or Javascript.
There are many points to discuss, ranging from small details like flexibility of quote delimiters or the mere simplicity of allowing a final comma in a list, to much more fundamental features like lexical scoping and dynamic scoping.
Since I'm not a native english speaker, and since my knowledge of Java and Python is mostly theoretical, I would appreciate help if some of you would volunteer for spending some time in proofreading the projected posts. Just send an email to my CPAN account if you feel like participating.
Thanks in advance :-), Laurent Dami
Ready, Set, Compile... you slow Camel
"Perl is slow."
I've heard this for years, well since I started. You probably have too. And honestly? For a long time, I didn't have a great rebuttal. Sure, Perl's fast enough for most things, it's well known for text processing, glueing code and quick scripts. But when it came to object heavy code, the critics have a point.
Otobo supports the German Perl Workshop
We are happy to announce that Otobo also is part of our event!
Die Rother OSS GmbH ist Source Code Owner und Maintainer der Service Management-Plattform OTOBO.
Gemeinsam mit der Community entwickeln wir OTOBO kontinuierlich weiter und sorgen dafür, dass das Tool zu 100 % Open Source bleibt.
Unsere Kunden unterstützen wir mit partnerschaftlicher Beratung, Training, Entwicklung, Support und Managed Services.
https://otobo.io/de/unternehmen/karriere/
ANNOUNCE: Perl.Wiki V 1.38 & Mojolicious.Wiki V 1.12
Download from the usual place, my Wiki Haven.
SBOM::CycloneDX 1.07 is released
I've released a new version of SBOM::CycloneDX with support for the OWASP CycloneDX 1.7 specification (ECMA-424).
This release includes the new elements introduced in 1.7, with a focus on:
- Enhancements to Cryptography Bill of Materials (CBOM)
- Citations: references and sources for evidence/metadata
- Intellectual Property Transparency: references to associated patents (number, jurisdiction, link, assignee) for compliance / due diligence needs
New experimental "SBOM::CycloneDX::Lite" interface: A lightweight module designed to generate BOMs with a simpler API, using the most common CycloneDX properties.
Examples included in the distribution (use them as a starting point to build your own applications/tools that generate BOM files):
- "x509-to-cbom" : generates a CBOM from an X.509 certificate
- "rpm-to-sbom" : generates a SBOM from installed RPM packages (on RHEL-based)
The goal of this module is to help the Perl community generate BOM files more easily, improving security and compliance across the ecosystem and making the software supply chain more transparent.
SBOM::CycloneDX is available on CPAN / MetaCPAN: https://metacpan.org/pod/SBOM::CycloneDX
Related projects: - App::CPAN::SBOM - https://metacpan.org/dist/App-CPAN-SBOM - Modules::CoreList::SBOM - https://github.com/giterlizzi/perl-Module-CoreList-SBOM
I'll Have a Mojolicious::Lite
I’ve built mojoeye, a tiny Perl app to run system and security checks across our internal Linux hosts:
https://github.com/GwynDavies/mojoeye
It’s built for environments where time, attention, and continuity are scarce. Checks are plain Perl scripts, the server is a single-file Mojolicious::Lite web app, and each host runs a small single-file client that reports back. There’s a short tutorial that gets someone productive in about 30 minutes.
Thank you, Mojolicious!
MIT licensed; currently tested on Debian- and Fedora-like systems.
— Gwyn
vitroconnect sponsors the German Perl Workshop
We are proud to have the support of vitroconnect.
vitroconnect implementiert Schnittstellen und Geschäftsprozesse für eine Reihe von marktführenden Unternehmen über die eigene Brokerage Plattform. Darüber hinaus können auch frei konfigurierbare White Label Bündelprodukte geliefert werden. Seit 2011 ist vitroconnect mit seinen Kund:innen aus der Telekommunikation gewachsen: Auf der vitroconnect Plattform werden aktuell über 100 Partner verwaltet. vitroconnect ist die größte netzunabhängige Brokerage-Plattform für TK-Breitbandanschlüsse in Deutschland.
How can we make this Moose faster?
(I make no apologies for the ChatGPT images in my recent blog posts, by the way. No artists are missing out on being paid: I wasn’t going to hire an artist to illustrate these blog posts which will be read by like three people.)
A while back, I wrote MooseX::XSAccessor which you can add to Moose classes to inspect your attributes and try to replace the accessors with faster XS-based ones. Now I’ve done the same for constructors (new) and destructors (DESTROY) with MooseX::XSConstructor.
There are probably still bugs, but initial benchmarks look promising:
Understanding TPRF's Finance, 2026 Edition
An Analysis of The Perl and Raku Foundation's 2024 Finances
In October 2024, I published an article analyzing the financial situation of The Perl and Raku Foundation (TPRF). Since then, I have left the board, and my life is now largely unrelated to Perl. I no longer have insight into TPRF's internal decision-making but I got a few suggestions to continue, so this article again analyzes TPRF's finances using publicly available data for the 2024 calendar year. There is an unavoidable delay between when nonprofit tax returns are filed and when they become public.
Executive Summary
- Assets at end of 2023: $200,215
- Revenue in 2024: $86,845
- Expenses in 2024: $188,037
- Assets at end of 2024: $101,525
Revenue: A Positive Turn
Taking the Win - Perl in the TIOBE Index
There has been much to say about Perl improving in TIOBE during 2025 and ending in the top 10 which is roughly where things were around 2016.
Many things are working well in the Perl community and we should expect to be seeing them paying off.
For example:perlmodules.net is down for 1-2 weeks
Because metacpan.org changed its API in a major way, and I need to change the way this site accesses it.
Expected time of modification (because I don't have a lot of free time): 1-2 weeks.
Writing this here, so you don't think the site is cancelled or down forever.
Marlin Racing
When I first introduced Marlin, it seemed the only OO framework which could beat its constructor in speed was the one generated by the new Perl core class keyword. Which seems fair, as that’s implemented in C and is tightly integrated with the Perl interpreter. However, I’m pleased to say that Marlin’s constructors are now faster.
(Though also I forgot to include Mouse in previous benchmarks, so I’ve rectified that now.)
Rate Plain Tiny Moo Moose Core Marlin Mouse Plain 1357/s -- -1% -48% -55% -73% -77% -78% Tiny 1374/s 1% -- -48% -54% -72% -77% -78% Moo 2617/s 93% 91% -- -13% -47% -56% -58% Moose 3001/s 121% 118% 15% -- -39% -50% -52% Core 4943/s 264% 260% 89% 65% -- -17% -21% Marlin 5976/s 340% 335% 128% 99% 21% -- -4% Mouse 6237/s 359% 354% 138% 108% 26% 4% --
Supercharge Event Loops with Thread::Subs
There are two issues with event loop coding, related to the need to maintain an asynchronous, non-blocking style.
- It's harder to write and maintain than linear, blocking code.
- Despite all the asynchronous behaviour, it's still single threaded.
You can break out of the async/non-blocking mode by forking, of course, but it's not a lightweight operation and creates the risk of orphaned processes even if most of the IPC work is hidden by a good library.
Wouldn't it be nice if you could simply write subs in the plain old linear, blocking style and then call them asynchronously, letting them run in parallel to your main thread until they're ready, no forking required? After all, you're probably already using some kind of async result mechanism like callbacks, or promises, or AnyEvent condition variables, or Future objects to manage existing async behaviour. Wouldn't it be nice if you could just call a sub and deal with it using one of those mechanisms instead of the usual synchronous behaviour?
Enter Thread::Subs.
About blogs.perl.org
blogs.perl.org is a common blogging platform for the Perl community. Written in Perl with a graphic design donated by Six Apart, Ltd.
