I worked with Perl daily and find CPAN even more of a wasteland than NPM. The average package there hasn’t been updated in a decade and has ancient dependencies to match; takes months / years for clients to be written for new tech.
Languages like perl--like common lisp, and c--are Stable. They change, some, but you can count on old code working. If a 10-year-old package Works, what reason is there to update it? I wrote a c library which has seen no updates in about 2 years--because it doesn't need them. It already does everything I need it to do.
Often I'll just not find the library I want since nobody using that tech is actually writing Perl. For example, complete lack of a working GraphQL package until late 2017.
CPAN search in particular is unbelievably bad. The first result for 'Postgres' is a package last updated in 1998 (not joking), try to find a usable driver here: https://metacpan.org/search?q=postgres. Even the widely used DBI package has last seen an update almost a year ago.
As for DBI, it's definitely in the "stable" category and isn't trying to keep up with anything; the DBD::Pg driver though was last updated this month.
Isn't Perl 6 already backwards incompatible?
> module names are both filesystem lookups and package stash lookups
>> names converted to lowercase internally
Converting names to lowercase internally fixes this.
> it's entirely possible for valid programs to use two modules that only differ in case
Many people (myself included) would see this as a mis-feature not worth saving.
To this day, I've seen package management systems for many languages, and none I've seen has been as good as CPAN in terms of
(1) Consistent place for distribution + documentation (cpan.org/metacpan.org)
(2) Automated testing on a wide variety of platform and configuration (cpantesters.org)
(3) CPAN has as standard for declaring dependencies in packages, but a newer "cpanfile" may be more akin go "modern" dependency management. Perl has also had a way of 'use Package $version' right in the source code for ages.
(4) the command "cpanm Package::Name" (or even the older "cpan Package::Name") almost always results in figuring out whatever distribution needs to be installed, even if the distribution is named differently from the package name.