I don't think the software engineering field is particularly rational and mostly follows trends or what looks good or familiar. We have a proclivity to assume that anything old is legacy. Most developer have never studied any CS history and are quite young, so they're bound to reinvent the wheel as well.
I think its fine to use older technology if its the right fit for the problem, and since the tech is battle-tested, you can read up as to why it went out-of-fashion, and as a result can minimize the risks with using it. It's "predictably disappointing".
Two things I think Perl always had a good reputation for was CPAN, providing interfaces to "everything", and a high degree of testing. I love that golang and rust both emphasize testing in modules/crates/packages. Writing perl CGI scripts I always had test-cases for the whole lifecycle, and that's something that isn't so common these days writing handlers in other languages.
Even the ones who studied it still fall into the trap of novelty for novelty sake. I'm guilty of that as well 20+ years ago at the start of my career, I believe it's one of those wisdom rites of passage someone needs to go through to value the lesson.
Boring old tech that works is pretty good, if it's not unmaintained, gets updates while keeping a stable core, has an ecosystem of good libraries and documentation, I'll always choose it over some new fangled thing from the past 2-5 years.
You need to feel the pain of depending on something that is taken away, or dies a slow but surely death, or creates massive headaches to upgrade, to value the stability of boring old tech.
I feel it's a cycle bound to be repeated by each generation.
There's not much money in working for a small saas unless you're the founder.
A truly modern language is Rust.
When Ruby made western presence it was clunky. No one knew what it was and it got stuck with that personality. It had an ecosystem too but never hooked in to the western world.
Java is tainted by Oracle and seen as "business".
And it's also weird how Postgres has made an uprising appearance. It was sitting duck back in the 00's. I knew it existed because as an script kiddie I could install a php forum and select it as a database backend but I never did.
Want to make a LCD display? You can simply by slapping a python library in to your code.
Ecosystems pull coders in. Thinking about it, it's probably why Perl was popular before with CPAN.
The old net was special but skills had to be learnt. Remember the days when you had one server for one service?
The new net is terrible but everything is handed to you on a golden plate.
IMHO deploying PHP to production is easier than Ruby/Python. You need a web-server but once it's configured (not a rocket science) you just copy all .php files. For ruby you also want to have a web-server (e. g. nginx) unless the load is negligible. If you want to deploy a project with all dependencies you probably need something like rvm but some gems would be easier to install form OS packages (like pg or other wrappers around C/C++ libraries installed from OS packages too). And then for ruby you need an additional daemon (HTTP) which will be restarted on updates (and auto-restarted if it will crash).
"There are only two kinds of languages: the ones people complain about and the ones nobody uses" -- Bjarne Stroustrup
At least when I first encountered Ruby it felt somewhat cool and exotic, I think because of a combination of its friendly website (compared to say Java), Japanese origin, and the fact that some of the first Ruby I ever learned was from why's (poignant) Guide to Ruby.
Don't recent PHP releases actually have a pretty good selection of nice, modern features? Union types, JIT compiler, pattern matching against types, nullsafe operator, gradual typing, etc. It seems like FP style is better and better supported with each new release, which is another hallmark of modern languages like Rust.
If you're stuck on some cursed, barely-maintained PHP 6 legacy codebase, you can't enjoy these things, but when it comes to choosing PHP for new projects it seems like it's more modern than its reputation.
I wouldn't be against starting a new project in Ruby or RoR.
If rails is the best at making web apps, and other ecosystems in other languages maybe get you 90% of the way, might as well use something else and not deal with ruby sucking at other jobs.
All that extra complexity is great for the economy.
I struggled to explain I would now have to spend 4 hours updating dependencies, maintaining a node js pipeline and dealing with typescript all because you couldn't handle adding a new fucking single form input to a form with only 3 existing inputs, which would have taken only 3 lines of code between the HTML and C#. The cake was this is an intranet app where the entire form only gets used a few times a year at best.
But Rails is hard to beat for CRUD apps.
I'm honestly surprised it didn't take off massively for internal enterprise CRUD stuff. It's by far the most productive stack I've ever used, the second closest being .NET w/ EntityFramework.
It was the darling of the early SaaS explosion of the early 2000s, and then just kind of died off in hype.
I like that it's opinionated, stops be from going down rabbit holes, and batteries included. There's nothing in the JS/TS framework of the day world that leaves me wondering "hmm, maybe I should stop using rails for this." It all seems worse, somehow, despite being more "modern."
so why not use JS directly or build on top of that???? that's what people do