If you’re thinking of PHP version less than 8 you need to have another look
Totally stateless. Uncached server side rendered response times in double digit milliseconds.
Types
Extremely battle, highly tested frameworks.
Excellent tooling for tdd, bdd, static analysis, automated browser testing, coding standards and auto fixing. Even fully automated refactoring for things like package upgrades (Rector)
Regular, solid, releases bringing updates and fixes
Arguably one of the best package management systems, Composer. And only one, none of this constantly changing tooling that some other ecosystems seem to do
Properly open source platforms to power all kinds of web projects from e-commerce, CRM, social, scraping, analytics, monitoring, API, CMS, blogging
Basically if your target is server side web stuff then it’s really good
Or, you can continue to demonstrate how out of touch you are by continuing with the old “PHP bad” jokes if you want!
For a bit of templating? Yes!
What drives response times up is typically the database or some RPC, both of which are out of control of PHP, so I assume these were not factored in (because PHP can’t win anything there in a comparison).
Anything under like 100ms load is instant to the user, especially a page load. It’s a balancing act of developer experience vs performance. To split hairs over milliseconds seems inconsequential to me. I mean, PHP requires $ before variables! That’s the real controversy :p
If you run it in old-school CGI mode, no, because each request would spawn a new process. But that’s nowhere near state-of-the-art. So typically you would still have a long-running process somewhere that could manage a connection pool. No idea if it does, though. Can’t imagine that it wouldn’t, however, since PHP would be slaughtered in benchmarks if there was no way to keep connections (or pools) open across requests.
not only that but you just install it with the lamp stack setting in ubuntu tasksel with apache and mariadb. the beating that these can take (except maybe the sql) and survive is great. you also have access to the whole of linux to do more advanced stuff, while other languages/ stacks shy away from exec
All of that can be the same as other stacks except the Apache bit. You can stand up a Go application on Ubuntu hitting MariaDB as its persistence layer. Or Python. Or Node. Or Java. Or even Ruby. Shit, Haskell can do it.
Also, exec is a code smell. Arbitrary code execution is a massive security risk, and the effort to mitigate that risk is often less than explicitly building out the required functionality.
I think you need to explore more technologies, my friend. And read up on some security things
Edit: I now realize you mean exec as in calling out to a shell. All languages have this. Still, the overhead of spawning and managing a new process is often more than just implementing the logic in your application itself.
Problem is, you’re mixing a number of different concepts into a nonsensical claim.
Exec as an “execute a string as a language instructions” is nothing new nor unique to PHP. Ruby on Rails, for example, uses it in a controlled manner to generate methods on ActiveRecord models.
Exec as an “replace this process with another process” is old news again. It’s not even language specific.
Popen/spawn family (which seems to be what you alluded to) is, once again, nothing new and is used everywhere.
PHP is amazing
If you’re thinking of PHP version less than 8 you need to have another look
Totally stateless. Uncached server side rendered response times in double digit milliseconds.
Types
Extremely battle, highly tested frameworks.
Excellent tooling for tdd, bdd, static analysis, automated browser testing, coding standards and auto fixing. Even fully automated refactoring for things like package upgrades (Rector)
Regular, solid, releases bringing updates and fixes
Arguably one of the best package management systems, Composer. And only one, none of this constantly changing tooling that some other ecosystems seem to do
Properly open source platforms to power all kinds of web projects from e-commerce, CRM, social, scraping, analytics, monitoring, API, CMS, blogging
Basically if your target is server side web stuff then it’s really good
Or, you can continue to demonstrate how out of touch you are by continuing with the old “PHP bad” jokes if you want!
Thirst thought, that sounds slow. But for the use case of delivering html over the Internet it is fast enough.
Double digit milliseconds sounds slow to you?
For a bit of templating? Yes! What drives response times up is typically the database or some RPC, both of which are out of control of PHP, so I assume these were not factored in (because PHP can’t win anything there in a comparison).
Anything under like 100ms load is instant to the user, especially a page load. It’s a balancing act of developer experience vs performance. To split hairs over milliseconds seems inconsequential to me. I mean, PHP requires $ before variables! That’s the real controversy :p
True, but it accumulates. Every ms I save on templating I can “waste” on I/O, DB, upstream service calls, etc.
If it’s stateless and nothing is kept in memory, can you have a connection pool?
If you run it in old-school CGI mode, no, because each request would spawn a new process. But that’s nowhere near state-of-the-art. So typically you would still have a long-running process somewhere that could manage a connection pool. No idea if it does, though. Can’t imagine that it wouldn’t, however, since PHP would be slaughtered in benchmarks if there was no way to keep connections (or pools) open across requests.
Extremely strong functional programmer support, too!
On the note of testing, Pest is still one of the best testing options I’ve seen across a variety of langs.
What’s wrong with version 8?
Dude was saying that 8 is good, but people still think of version 5 when talking about PHP. Not recommended to still use in 2023.
Even 5.3 was good enough.
4 was hilariously bad though
I’d say 5.4 was when it publicly got great - but yea, a lot of ground work for that was in 5.2/5.3
he meant 8 is great
On the opposite - version 8 is great.
not only that but you just install it with the lamp stack setting in ubuntu tasksel with apache and mariadb. the beating that these can take (except maybe the sql) and survive is great. you also have access to the whole of linux to do more advanced stuff, while other languages/ stacks shy away from exec
All of that can be the same as other stacks except the Apache bit. You can stand up a Go application on Ubuntu hitting MariaDB as its persistence layer. Or Python. Or Node. Or Java. Or even Ruby. Shit, Haskell can do it.
Also,execis a code smell. Arbitrary code execution is a massive security risk, and the effort to mitigate that risk is often less than explicitly building out the required functionality.I think you need to explore more technologies, my friend. And read up on some security things
Edit: I now realize you mean
execas in calling out to a shell. All languages have this. Still, the overhead of spawning and managing a new process is often more than just implementing the logic in your application itself.I’m sorry, what?
Turns out arbitrary code execution is actually great(!)
it does not have to be arbitrary my dude
Problem is, you’re mixing a number of different concepts into a nonsensical claim.
Exec as an “execute a string as a language instructions” is nothing new nor unique to PHP. Ruby on Rails, for example, uses it in a controlled manner to generate methods on ActiveRecord models.
Exec as an “replace this process with another process” is old news again. It’s not even language specific.
Popen/spawn family (which seems to be what you alluded to) is, once again, nothing new and is used everywhere.
i just meant that python’s and node’s implementation is shit