Sure, 10-20 years ago the language was more hacky than anything, but nowadays its a solid choice for backend stuff, with lots of activity, new innovations, good, proven frameworks (Symfony, Laravel) and also lots of people who have experience in it.
I have a few projects running a PHP API with a JS frontend (Vue in my case) and it works pretty nicely. Best of both worlds!
What's the difference between that and `pip install psycopg2` (which actually seems easier to me)?
Examples off the top of my head:
* Lists and dictionaries being the same data type ("array"). This makes it impossible to distinguish between an empty list and an empty dictionary, good luck encoding that JSON.
* Arrays are pass-by-value
* '123' == '+123' evaluates to true
* '0' == '0.000' evaluates to true
* `$a = true; $b = false; $c = $a and $b;`, $c evaluates to `true`
* Closures requiring you to explicitly list every variable from the parent scope you want to use
* References (&$var) have a lot of footguns
* array_key_exists and property_exists taking opposite parameter orders
* stdlib naming in general being pretty bad, with the stated justification being that strlen() was used as a hash function in early PHP versions, so functions were named to achieve an even distribution: http://news.php.net/php.internals/70691
* The null-coalescing operator is also an are these even valid identifiers-coalescing operator – here $result is 2:
$myvariable['x'] = 1;
$result = $myvvvvariiiiableee['x'] ?? 2;
All those bad things about PHP you've listed go well with Gary Bernhardt's WTF video about JS's inconsistency.
JavaScript is not well-designed however you squint at it, and claims that it's gotten better must come from people that have not used any other language before.
Hell no. PHP is awful for background processing. I do DevOps for a bunch of different languages (Node.js, Elixir, PHP, Java) and PHP is always the problem child. Poor concurrency, memory leaks, general RAM bloat, etc.
And if you google for “php memory leak”, you’ll get a lot more than 0 results.
Since php scripts are meant to be run once per request memory leaks are not an issue - any build up gets “reset” once execution ends. There are however shit frameworks that have circular references to objects and do all kinds of crap that builds memory up - easily avoided by parallel queue consumers.
Threading and async are non issues given my statement above, hence me blaming on the dev’s skill and not understanding what the language does.
For instance, you dont normally start a background process with an event loop to handle stuff. You start queue consumers at set intervals that run in parallel, or scripts that process batches of code - thus mimicking parallelism in a classic multi threaded app. This way you reduce the blast radius, are guaranteed that at least some data will always be processed and avoid memory leaks alltogether. No need for “conscious” async since its async by nature.
However there is nuance in everything. Would you be able to provide a specific example of where you end up with such issues so i can better detail an example of how i would approach it?
Yes, and that’s exactly why I said that PHP is awful for background processing, because there the process ideally runs continuously, or at least as long as there’s data to process. With PHP, I have to continuously re-spawn the processes to keep the memory leaks in check.
If your application is so simple that it doesn’t need to process data outside of the request/response cycle, I’m sure PHP is fine.
And sure, you can compensate for PHPs lack of async processing by spawning more processes, but that makes the RAM bloat problem even worse.
We actually had a big argument about building them like this for exactly the reasons you mentioned though - the preference for me and some others was to run them as once off's from cron, specifically to avoid the possibility of memory issues.
Our tech lead wanted them to run as services (I think to improve responsiveness primarily). I didn't think it would work as well, but history has proven that it worked fine. I can't say it was better - it took a while to work out the kinks - but these things have been happily running for over a decade with basically zero issues relating to memory leaks, etc. They're not super complicated but not trivial either.
PHP isn't great for persistent background processing because that's not what it's designed for, any more than Python is good as a frontend DOM manipulation language.
But one common issue with php devs is that they are religious about the language. Probably because they dont actually understand programming as a whole - not even php itself. They should use the best tool for the task at hand and not be religious about php.
I remember when i was in that dark place i even considered php for gui apps lmao because php was hot hot hot.
I was involved in several large PHP projects which did a lot of background processing (not Google scale, but telco scale) and performance was more than adequate in all cases.
The advantages of running a single codebases far outweighed any potential benefit of a speed increase from switching to another language. (... I say that having been the jerk that actually did rewrite one small component in C and it turned out to be a huge waste of time and effort and just meant something additional the team has had to manage in the almost 20 years since I did it!)
But yes, the reluctance to use other languages and different codebases was also a common argument in all php teams i worked with. People need to understand that a language is a tool not a religion. If using php for the web layer, python for processing background tasks and nodejs for apis makes sense then do so by all means. PHP devs need to understand that.
The PHP apps i built were for large userbases processing billions of pounds and in one case dollars a year. The language if used right is superb.
It’s the type of dev using it that’s usually not, I am sorry to say that.
Heh, nah, the rest of the stack is still running. The first line of PHP code that I personally wrote was in 1999 and it's still there; the core CMS was written earlier than that.
It's not doing anywhere near the traffic it used to (it was a reasonably popular video gaming site back in the day; it gets almost zero maintenance & I'm continually impressed it's online and working just as well as it did (... arguably better because it has so much less load :)
> It’s the type of dev using it that’s usually not, I am sorry to say that.
I don't disagree but I also don't think that is a problem unique to PHP at all. Arguably some languages are better than others at keeping developers on the rails in some cases, but you're going to see garbage written in everything eventually.
Yes, there are often things besides pure request/response that an application needs—but in all the cases I have yet personally come across, those were easily served by simple cron jobs calling PHP scripts from the command line (either directly, or through a Symfony app's Command interface).
To be clear, I do not at all dispute that many types of application do need some kind of persistent background processes, and those would be much less suitable for building (entirely) in PHP. Indeed, I am happy to also stipulate that it may not always be easy to tell whether that will be the case when initially designing the spec and choosing one's tools.
But there are plenty of applications that work perfectly fine using nothing but request/response, and many others that only need to add simple triggered scripts to that.