4 ms·

They didn't say "background processing". They said "backend stuff"—ie, the code that runs on the server that does the processing for stuff the client submits, a

They didn't say "background processing". They said "backend stuff"—ie, the code that runs on the server that does the processing for stuff the client submits, as opposed to "frontend stuff," which runs on the client itself. 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.

gumballindie 3y ago
However php can be used for background processing if done right - but its speed in processing large amounts of data is dogshit. For instance if you wish to iterate massive arrays in one go then python is waaay better. If you wish to iterate each one at a time then that can easily be done via queues and can be parallelised endlessly quite easily. 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.
- trog 3y ago
  There is (almost) /always/ a faster language. As with any stack, the advantage of PHP being used for background processing in a PHP application is you're already using it, so you don't end up having to manage multiple codebases. 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!)
  - gumballindie 3y ago
    Well ok but it seems like the C app you “wasted time” on lasted 20 years. I bet the rest of that stack either moved away from php or added extra languages. 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.
    - trog 3y ago
      > I bet the rest of that stack either moved away from php or added extra languages. 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.
mikl 3y ago
There’s not a lot of applications beyond a certain size that don’t need background processing, and that’s exactly where using PHP bites you in the buttocks. As soon as you get outside the request/response cycle, the runtime really starts to show its shortcomings.
- danaris 3y ago
  I think that's showing a bias toward a particular kind of application. 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.

gumballindie 3y ago

However php can be used for background processing if done right - but its speed in processing large amounts of data is dogshit. For instance if you wish to iterate massive arrays in one go then python is waaay better. If you wish to iterate each one at a time then that can easily be done via queues and can be parallelised endlessly quite easily. 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.

trog 3y ago
There is (almost) /always/ a faster language. As with any stack, the advantage of PHP being used for background processing in a PHP application is you're already using it, so you don't end up having to manage multiple codebases. 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!)
- gumballindie 3y ago
  Well ok but it seems like the C app you “wasted time” on lasted 20 years. I bet the rest of that stack either moved away from php or added extra languages. 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.
  - trog 3y ago
    > I bet the rest of that stack either moved away from php or added extra languages. 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.

mikl 3y ago

There’s not a lot of applications beyond a certain size that don’t need background processing, and that’s exactly where using PHP bites you in the buttocks. As soon as you get outside the request/response cycle, the runtime really starts to show its shortcomings.

danaris 3y ago
I think that's showing a bias toward a particular kind of application. 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.