I've worked with Perl for many years and still actively develop for it at work.
IF you deliberately ignore some of the crufty parts of the language (ie you follow "Modern Perl") it's... ok. Perfectly possible to write good code with it if you understand the quirks, but you have to be strict to avoid the stereotypical "line noise", and not everyone is. Some parts are legitimately awesome though: Moose, for example, is a fantastic OO model that I wish was usable in other languages (although you do pay for it with long load times).
However, the ecosystem and community have been struggling to keep up with the rest of the world for a while now, and where you used to be able to assume that CPAN would yield something useful for most tasks, that's becoming increasingly untrue, and a lot of projects are now abandoned.
I still reach for it for small things, but I wouldn't start a large project with Perl now, I don't think.
We use it at my workplace pretty extensively. Where possible, new work is done in Go, and as time and effort permits work is underway to port things to Go, but there is enough legacy stuff in Perl like our (front-end, customer-facing) web application that sometimes new features are written in Perl.
Modern Perl using Moose is pretty nice to develop in. I find it much easier to express things in Perl than in Go, but I am not an expert in either language despite having several years practice with the former and a couple of years with the latter.
I'd say the biggest issue with Perl is that modules on the CPAN are slowly going stale, and that my understanding is that there is a lot of Perl (C) and XS (C FFI) code that is not actively maintained or necessarily properly developed (including, I believe, parts of the Perl runtime itself). This can lead to segfaults with who knows what behavior.
Take this with a grain of salt: I've never been a good C programmer.
An aside: one of my coworkers is a founder of MetaCPAN, which is a great site.
Not sure about new projects, but Amazon.com's front end is built on perl (not sure many components behind it use perl, but perl is the presentation layer). You can see references to mason still in the HTML source. https://metacpan.org/pod/HTML::Mason.
Purely anecdata but I still see lots of "quick scripts" thrown together in Perl, and perl -pie is still very popular. I don't see many projects start in Perl as the primary language, but Perl is still a string processing powerhouse for people that know it.
It is also an essential part of current infrastructure. The fact that few projects "start" in perl today is not really consequential of its current importance. For instance, do you know that a brand new install of MacOS catalina contains more perl scripts than python and shell scripts altogether?
Perl has its share of problems, but it is still a very useful language, and it is still used far more extensively than a lot of people think.
And yes, it is still used for new projects, and no it is not necessary to sacrifice your mental health nor your earning potential to use it.
It is not, nor will it ever be the darling of the startup world. But most of the software development in the world is not done at startups.
I'm not saying you'll get rich writing Perl, nor am I saying that it is growing in "market share" if you want to call it that. In fact, considerably less people use it now than did in the past.
However, you can still make a decent living writing Perl in 2020.
Of course, my advice would be to learn multiple languages, and most importantly, never stop being willing to learn new things, if you want to be a developer your entire career.
I also think it's important to be willing to occasionally learn old things. You never know when you might be called on to make changes (sometimes extensive ones) to a legacy system, and "rewriting it in language 'X'" is often not an option.
I can't say I agree with the mental model critique for the most part. I think some languages do make it easy to write convoluted code, but through judicious use of coding standards (including a helping of common sense [don't be clever where you can at all avoid it, which IME is ~~almost~~ all the time], code linters, and so on) I think how you use a language plays a huge part in code maintainability.
For instance, I've heard PHP get shit on pretty badly all around the web, but I've worked at PHP shops that had nice, clean codebases, and my current Perl codebase is, in many ways, nicely structured. That's not to say there aren't some hairy codepaths that could use refactoring, but I really think that kind of thing, again, can happen in almost any language.
I used to code in Perl when managing systems. I liked it a lot (after having coded in C it felt really modern) ad like many others, the understanding of my own code declined exponentially with time.
I am not a pro developer, just an amateur one who was surprised to see a mention of an old love.
Most of our stack is written in Perl. Was maintained initially, then rewritten using Mojolicious, now constantly maintained and modernized. Haven't used Moose though, too many deps, too heavy. Moo is good enough, Mojo::Base is minimal but okay.
If anyone wants to give it a shot and play with it without downloading or installing anything, check out https://perl.bot/ 5.32 is the default on there now. The code gets run server side and doesn't require JavaScript to function.
What does the packaging system for perl look like these days? Does `cpan install` somewhat work?
One of the reasons I have never gone back to Perl after moving to Python in the early 2000s is that the packaging system was horrific. Even Python's weird mix of system packaging and pip mostly just works, and the story has gotten a lot better with virtualenvs, pip, and such.
Meanwhile I have rarely successfully installled anything with CPAN, it always seems to fail out with some odd error in the middle of building something. Experiences like this make the activation energy required for me to do any fun side projects using Perl instead of Python.
Are my observations atypical? Is there a better way to use and install third-party Perl packages that I don't grok?
This works nearly always, except when header files or C libraries are missing on the system (like you need libpq-dev on Debian/Ubuntu to install DGD::Pg, the postgresql database connector).
With the system perl, local::lib also works, but it's a bit fiddly to set up initially.
It is atypical. Cpan install just works and has been like that at least 15 last years. Also major package managers have automated converters which are mature, so one-step install and convert is also a thing.
Python's pip+virtualenv is often much worse, so many of the packages need `wheel` but don't depend on it and failed builds are treated as successful, so it's not as smooth as could be, but much is improved since Python 3.5+.
