Let me preface this by saying that I pass zero judgment to any people who use PHP by choice or otherwise, and that I don't assume I'm "better" or smarter than anyone else for their programming tool choice.
But, if you genuinely want to know why some of us hate on PHP, I can tell you the reasons that I would never choose PHP for a production backend (now, I do think PHP is a fantastic scripting/sysadmin language- better than Python for sure, but I don't know Perl well enough to judge against that).
PHP is single-threaded. I feel like that's a pretty decent reason all by itself to not want to use it in an enterprise environment.
PHP is not really async, either. Yes, there are are run-loop libraries, and some libraries even claim to be async all by themselves, but these solutions are awkward and cumbersome and easy to use incorrectly.
PHP's array data type is ridiculously bad. In every conceivable way. If you want to use it as a contiguous, linear, collection, then it's slow and bug-prone (e.g., using array_filter, but forgetting to wrap it in array_values). If you want to use it as a dictionary, then it will sneakily convert your keys into numbers which doesn't matter until it does (like when trying to operate over filenames in a directory and someone named a file "1". Then you try to do some operation that expects a string and your code explodes several hours into its operation... Ask me how I know).
PHP's iterators and other, more professional-grade, data structures are not as "first class" as plain-old array, so nobody uses them. IIRC (it's been a while), you theoretically need to enable them in your php.ini and/or install them at the OS level, which kind of kills the whole "PHP is so easy to deploy! Just FTP a file and you're done!"-thing.
I prefer static typing to dynamic typing. PHP's static typing is weak (as in not strict enough) and not expressive enough for me (no generics, no sum types, no extending classes/types).
PHP does not allow for custom equality definitions. Also, since everything is references, I believe you can blow the stack if you try to check that two objects are equal that reference each other.
The architecture of every HTTP request getting a fresh instance of PHP is actually pretty nice. And a ton of work has been put into the language/runtime to make sure it's stupid-fast at ramping up and parsing the request data. HOWEVER, as soon as you slap one of these popular frameworks (Laravel, Symfony, etc) on top, you've basically ruined it and made it slow, with all of the extra framework initialization junk. I remember seeing engineering effort go into "compiling" Symfony code to make it load quickly (I don't remember how Laravel works). But think about that for a second- we're going to choose an interpreted language that can't cache any state beyond a single request, and we're going to add a COMPILE STEP to it?! So that we can work against the init-process-teardown cycle that it's designed for? Are we really sure we actually wanted to use PHP?
I used to have more specific complaints about strings and the numeric types, etc, but it's been a little while since I've had to write any PHP (I haven't used version 8, but I was using 7.4, I think, so I'm still fairly immune to the "You only remember PHP before it became awesome in 7+." criticism).
I'm more than sure that any regular PHP dev has no problem dismissing all of my complaints. Just like when I went to the doctor and told him my elbow hurts when I bend my arm. He told me to stop bending my arm! Problem solved. ;)
There’s a lot of debate about this kind of stuff on the internals mailing list. In fact, the array string to number thing was just recently discussed and why it is the way it is[0]. It would take an entirely new type to support keeping it as a string.
But, if you genuinely want to know why some of us hate on PHP, I can tell you the reasons that I would never choose PHP for a production backend (now, I do think PHP is a fantastic scripting/sysadmin language- better than Python for sure, but I don't know Perl well enough to judge against that).
PHP is single-threaded. I feel like that's a pretty decent reason all by itself to not want to use it in an enterprise environment.
PHP is not really async, either. Yes, there are are run-loop libraries, and some libraries even claim to be async all by themselves, but these solutions are awkward and cumbersome and easy to use incorrectly.
PHP's array data type is ridiculously bad. In every conceivable way. If you want to use it as a contiguous, linear, collection, then it's slow and bug-prone (e.g., using array_filter, but forgetting to wrap it in array_values). If you want to use it as a dictionary, then it will sneakily convert your keys into numbers which doesn't matter until it does (like when trying to operate over filenames in a directory and someone named a file "1". Then you try to do some operation that expects a string and your code explodes several hours into its operation... Ask me how I know).
PHP's iterators and other, more professional-grade, data structures are not as "first class" as plain-old array, so nobody uses them. IIRC (it's been a while), you theoretically need to enable them in your php.ini and/or install them at the OS level, which kind of kills the whole "PHP is so easy to deploy! Just FTP a file and you're done!"-thing.
I prefer static typing to dynamic typing. PHP's static typing is weak (as in not strict enough) and not expressive enough for me (no generics, no sum types, no extending classes/types).
PHP does not allow for custom equality definitions. Also, since everything is references, I believe you can blow the stack if you try to check that two objects are equal that reference each other.
The architecture of every HTTP request getting a fresh instance of PHP is actually pretty nice. And a ton of work has been put into the language/runtime to make sure it's stupid-fast at ramping up and parsing the request data. HOWEVER, as soon as you slap one of these popular frameworks (Laravel, Symfony, etc) on top, you've basically ruined it and made it slow, with all of the extra framework initialization junk. I remember seeing engineering effort go into "compiling" Symfony code to make it load quickly (I don't remember how Laravel works). But think about that for a second- we're going to choose an interpreted language that can't cache any state beyond a single request, and we're going to add a COMPILE STEP to it?! So that we can work against the init-process-teardown cycle that it's designed for? Are we really sure we actually wanted to use PHP?
I used to have more specific complaints about strings and the numeric types, etc, but it's been a little while since I've had to write any PHP (I haven't used version 8, but I was using 7.4, I think, so I'm still fairly immune to the "You only remember PHP before it became awesome in 7+." criticism).
I'm more than sure that any regular PHP dev has no problem dismissing all of my complaints. Just like when I went to the doctor and told him my elbow hurts when I bend my arm. He told me to stop bending my arm! Problem solved. ;)