But PHP developers, boy oh boy, are a different story.
My favourite is how they all still debate setter and getters and almost none know the language but only the framework they use and code usually turns into a huge pile of unmaintainable crap. But hey they use ORMs just in case they’ll swap database engines (happens so rarely not even worth mentioning).
And PHP has wide built-in support for multiple database engines (check out PDO) so this is largely not a part of an ORM.
This leaves the ORM to focus on higher-level work, like how to abstract the differences away regardless of which engine you end up using and focussing on the representation of your data and the API you use to interact with it.
That's pretty powerful and has allowed tools like Laravel and Symfony to suit a super wide range of needs.
But yes, it does also mean that you're not switching your entire language or framework stack when some database technology providers baits-and-switches their licensing - which has been known to happen
Such a nice language bastardised by over engineering and reinventing the wheel. Sad.
Can you expand on this please? What exactly makes it easy to scale in which way?
How will you deal with the wall you hit when you outgrow your one central database?
As such errors would be contained within the context of that request, while memory leaks if any would be a non issue since gc is done when the process literarily ends. So that covers that aspect of scaling.
Then all of these external state maintenance dependencies each scale independently. For instance session data can be distributed against endless clusters of redis or nosql instance. Heck some people even used remote file systems for it. Databases would be clustered too - say a couple mysql percona write instances and endless read instances. If that’s not enough then use an intermediary localised storage and queue writes. Or use something like cassandra. Database connections can also be round robin’d since each script would be re executed and connection reopened anyway (can be reused if needed) so they can connect to any server in your cluster. You can also use a database load balancer and sharding, or nosql for fast writes than then get further processed into a relational database.
All in all php webapps can be scaled infinitely. Not as efficiently per instance but fairly straight forward by even average devs with the right guidance.
For some past clients i scaled apps to billions of unique monthly requests with a fairly low effort. Happy to answer any specific question.
That's not to say that it doesn't happen in other languages, but I've never seen PHP code written by a stranger that didn't make me squirm.
Last time, long time ago, when i touched a php symfony project i ended coding yml instead of actual php because _everything_ was in a config file - hundreds of packages and libraries just because the dev couldn't be bothered to issue calls to native php functions. Hilarious. However i did make a killing in training teams in design patterns and coding practices to help them maintain quality.
And almost always my advice was to write framework agnostic code (treat the framework as if it were just a dependency). Worked nice. Clean little specialised classes, no config maintenance madness, i also enforced running code linters and smell detectors on each commit and push. Gave up on the language when i noticed that _literarily_ all teams had the exact same issues, the exact same topics of debate and the exact same flamewars.
Therefore all in all i think, for me, php belongs to history, and without wanting to insult anyone, i try and avoid any debated with a pho developer - it simply gets stuck in a bike shedding endless loop.
As I gained more experience, I've become wary (and weary) of how a language or framework can mis-guide programmers into messy code that's difficult to grow and maintain. But then again, as long as the work gets done and money gets made, perhaps it doesn't matter much to some people. For myself, I want to take pride and pleasure in the work, and there are other languages with better design and developer experience.
Living with some of the hellish code that exists in the wild (and honestly terrible code that I've written myself) has been a great learning experience, making me a better programmer. It's important to be sensitive to code smell, noticing how it's going in the wrong direction and what can happen in the long term, understanding how it happens, what can be done to prevent it - and better yet, how a language (syntax, patterns, tooling, ecosystem) can be designed to guide oneself and others so that good code can be written "naturally" by following best practices that are built into it.