Every argument like this that just focuses on the language features and performance completely misses the point.
When I hear people expressing that PHP "sucks", that's mostly coupled to the ecosystem, not necessarily the language itself. Yes, the biggest warts in the language might be non-issues now if you write 100% of your code yourself, but the ecosystem is the same as it ever was.
PHPs utilitarianism is its biggest strength but also its biggest weakness when it comes to its libraries. Packagist is mostly a graveyard of libraries that people have coded up for their exact niche use-case 8 years ago (with no updates since), with little flexiblity beyond that (like you would see for libraries in other ecosystems).
The popular frameworks (mainly the CMSs, but also some of the MVC ones) suffer from a similar fate: Great if you want to hack something up quickly or do a small extension to it, but full of footguns and lacking in developer tooling.
In my few years of experience, the language is not too bad but the ecosystem, job market, and dare I say the self-considered experts who specialize in it, are difficult to tolerate for long. It's great the performance is improving, but there continue to be questionable design decisions in the language, as well as accepted standard practices and libraries.
> if you write 100% of your code yourself
The only way I was able to tolerate it is by carving out my own little world, and being very conservative with any external dependencies. Come to think of it, this approach has worked well for me with other languages but not to this extreme where I consider it a hostile environment.
The problem is that PHP still has no credible competition whatsoever in core use cases like "take an HTML document and replace static part with something fetched from a database", or "take multiple HTML documents and factor out a common structure that you might want to change everywhere at once later". Of course there exist solutions in "modern, well-designed languages" for these, but I will confidently take a challenge from any node.js, Elixir or Ruby developer on who can get it done faster.
Sophistry about how my solution won't scale to a million users per day or I should have used their framework from the start rather than having a bunch of HTML files won't matter to me nor the <10k people I expect on my website. In many cases, modern languages and frameworks drive adoption for themselves by tricking you into solving a problem that is not actually the problem you have, but they happen to be adapted to.
> Packagist is mostly a graveyard of libraries that people have coded up for their exact niche use-case 8 years ago (with no updates since), with little flexiblity beyond that (like you would see for libraries in other ecosystems).
Could you provide some examples? I wrote a lot of PHP libraries over the years, and while some are definitely stale because nobody uses them (and thus I have no incentive to keep the lights on), the only time I see dead packages, they're actually forks of other open source software that people contributed exactly one commit to (to change the package name).
When I hear people expressing that PHP "sucks", that's mostly coupled to the ecosystem, not necessarily the language itself. Yes, the biggest warts in the language might be non-issues now if you write 100% of your code yourself, but the ecosystem is the same as it ever was.
PHPs utilitarianism is its biggest strength but also its biggest weakness when it comes to its libraries. Packagist is mostly a graveyard of libraries that people have coded up for their exact niche use-case 8 years ago (with no updates since), with little flexiblity beyond that (like you would see for libraries in other ecosystems).
The popular frameworks (mainly the CMSs, but also some of the MVC ones) suffer from a similar fate: Great if you want to hack something up quickly or do a small extension to it, but full of footguns and lacking in developer tooling.