Perl certainly has a similar spread of problems and solutions, some of which clearly were inspired by python and ruby solutions. local::lib, Carton, perlbrew/plenv are all recommended immediately to solve these problems, but they are still solutions one has to go looking for, it's easy to first fall into problematic setups by not using them (at least all modern CPAN clients will set up a local::lib by default now).
I very much prefer "typeless data with typed operators" over Javascript's "typeless data with typeless operators" or basically any language that was forced to add ===.
Okay, I see. You should use what most easily provides the features you want, to be sure, and it certainly has not been battle tested the way, say, Catalyst has. But I think you are still selling it short. Mojolicious is foremost about consistency and practicality, beauty (if you would consider it that) is simply a side effect; and it is probably in more use than you think.
Indeed and as a Perl developer I make use of XS/external libraries, cooperative multitasking (event loops/promises), and forking to cover these use cases. It doesn't preclude wanting the additional option to take advantage of threads in a useful way, since they do exist.
Modern web development doesn't use these, and mod_perl is certainly not recommended anymore - CGI still has its uses, but don't use CGI.pm. A modern webapp is written in Mojolicious or a Plack based framework, and they can all deploy transparently via a standalone server, or any PSGI or CGI server, or even mod_perl or fastcgi if you really need to.
I'm not sure what gave you the idea that just because Mojolicious is Perl, it would have "a pile of corner cases" while a "simple nodejs app" wouldn't. Mojolicious is built from the ground up to be effortlessly asynchronous and performant and handle all common needs. Don't punish it for the horrible CGI.pm that has been removed from core Perl.
Yes, Perl's threading support is terrible, and I do wish it was as effortless as in Raku. But you'd be surprised how often you actually only need an event loop and non-blocking implementations, and for the rest of the time there's Mojo::IOLoop->subprocess or IO::Async::Function to provide a thread-like model with efficient forking.
In this case, it's a Perl concept related to DWIM (Do What I Mean), where the features will make practical assumptions about what you need to accomplish in their implementation, so you don't have to worry about the details. It can be abused (and is) but is also very useful for quick oneliners in particular.
Not to be confused with the Perl feature called magic, where functionality can be attached to a variable to affect what happens whenever it is accessed. Though this is often used to implement the former concept.
The Python situation had a major difference: the current maintainers of Python 2 and Python 3 are the same, and Python 2 is still intended to be EOLd. A clean break would surely have avoided many problems but it's hard to speculate how it would have gone.
I am not that familiar with Python, but the GIL has long prevented any real in-process concurrency. Perl has concurrency but it's complex, heavy, and poorly supported. Raku's approach to this is built to avoid all these problems (like Elixir).
Perl 5 has never been at the end of its life (though it was intended to be 15 years ago, things changed), this is one part of what this rename is meant to clarify. It still has a major release each year and modules are released to CPAN constantly: https://metacpan.org/recent
I can say that at least currently, there is no appetite for Perl attempting to "reclaim" the Perl 6 version in the foreseeable future. It would be a disaster in both community relations and marketing. It will either be Perl 7 or Perl 34+.
Oneliners that range from simple text processing to complex magic. Wonderful web applications in Mojolicious. Lexical scoping and strict variable checking. Four strong event loop ecosystems, futures and promises, and an in development async/await syntax all for collaborating asynchronous tasks. Great integration with shared libraries through XS and FFI. A consistent culture of documentation and testing for everything on CPAN. And mainly, familiarity with the language.
It's not so much a feature as how really old versions of Perl worked. Any program using strict doesn't allow it unless it's a known subroutine name, built-in or other symbol.
Except in certain cases because back-compat is complicated.
It is pretty unfortunate that so many people used "PostgreSQL" and "Postgres" in their module name and DBD::Pg didn't, so it gets ranked lower for those queries. But ranking is a hard problem when there is no curation. The MetaCPAN team does want to improve this if possible.
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.
To put some numbers in this thread, it was fixed in CPAN.pm version 1.90 in 2007, which first came with Perls 5.8.9 and 5.10.0 (but can be updated on older Perls).
A lot of things would have made more sense in hindsight, but it's not where the community was at the time, and ultimately Larry said no to a straight rename. He is taking less of a role now so it can be revisited.