Exactly. I’d argue what makes modern PHP less awful is almost entirely in what it lacks. Checking a bunch of random OOP boxes is not going to make it a good language. People love plenty of programming languages that don’t check those boxes. (Lua, C, Go are all languages that lack many of those OOP features, for example.)
And to be sure, modern PHP is better. The beginnings of typing, the fixing of horrible standard library behaviors, and an ecosystem with package management are game changers. But to me, all of that means nothing if the ecosystem is primarily running legacy apps. There are clearly proponents of modern PHP that embrace the new PHP, but what really gives it any modern relevance is old school apps like Mediawiki, phpBB, etc. and I feel like they all underscore what I dislike about PHP: not a single problem but a mindset that is incompatible with modern internet. There is no assumption of shared nothing; most apps assume the disk can be used for persistence. And it’s tricky to dockerize a PHP app effectively since you typically need multiple processes; I know there’s work on an app server in PHP itself but last I checked it was for development, and rather I ended up using uWSGIs embedded PHP support as the only solution I could even find that could do this in a way that wasn’t horrifically ugly or intensive.
It still has its issues. For me the prime issue with PHP is the execution model. I am not in for my document root being my source dir. This weird behavior comes from the CGI era and to this day it doesn’t really feel like there is intent to move away from it. Rather, the age old front controller pattern is poised as a “solution,” entangling web server, PHP and application configuration together in some unholy mess, versus the modern pattern of having an app server.
> And it’s tricky to dockerize a PHP app effectively since you typically need multiple processes;
Absolutely. I handle a lot of the devops work at my job and PHP containers are just all around more annoying to build, configure and run than most other languages. Even on modern frameworks like Laravel still have a lot of default assumptions of being hosted on a server all by themselves.
It's weird how a language that gained so much traction for being the easy language to host has become one of the harder ones to deploy in the modern era.
And to be sure, modern PHP is better. The beginnings of typing, the fixing of horrible standard library behaviors, and an ecosystem with package management are game changers. But to me, all of that means nothing if the ecosystem is primarily running legacy apps. There are clearly proponents of modern PHP that embrace the new PHP, but what really gives it any modern relevance is old school apps like Mediawiki, phpBB, etc. and I feel like they all underscore what I dislike about PHP: not a single problem but a mindset that is incompatible with modern internet. There is no assumption of shared nothing; most apps assume the disk can be used for persistence. And it’s tricky to dockerize a PHP app effectively since you typically need multiple processes; I know there’s work on an app server in PHP itself but last I checked it was for development, and rather I ended up using uWSGIs embedded PHP support as the only solution I could even find that could do this in a way that wasn’t horrifically ugly or intensive.
It still has its issues. For me the prime issue with PHP is the execution model. I am not in for my document root being my source dir. This weird behavior comes from the CGI era and to this day it doesn’t really feel like there is intent to move away from it. Rather, the age old front controller pattern is poised as a “solution,” entangling web server, PHP and application configuration together in some unholy mess, versus the modern pattern of having an app server.