6 ms·

My favorite thing about PHP is the execution model. Every single request is brand new and runs the whole program start to finish. IMO that's extremely powerful

My favorite thing about PHP is the execution model. Every single request is brand new and runs the whole program start to finish. IMO that's extremely powerful in its simplicity and while you can get it in other languages, it feels like like a "core competency" for PHP (just like how async code is easier in javascript than in python, because JS kind of had it from day 1)

resonious 5y ago
Forgive me for going a little off topic here but is it really true that JS was async-friendly from day 1? When I started using JS seriously 8 years ago, async code was horrible (callback hell, etc.) The web standards guys retrofitted native async way after the matter.
- tylergetsay 5y ago
  async/await is just syntax sugar around promises which are a just a nice way of organizing callbacks, so yes I'd say it's true.
- nkozyra 5y ago
  Probably more accurate to say it was async from day one. Which people probably realized the first time they had to deal with setTimeout The original promises syntax and chaining in ES6 were not particularly user friendly.
- kall 5y ago
  Doesn‘t this more or less mean "the only execution environment is event based, has a run loop outside of your control and calls your code whenever it wants" and "there is no busy sleep". So it was callback based from day one. Is that the same as async? I think it is?
  - resonious 5y ago
    That makes sense, thanks! It has indeed been run in a loop from the start despite the poor ergonomics - I did not think of it in that light.
boudin 5y ago
I see this as the opposite and find it adds quite a load of complexity and prevent to do some form of optimization in an app that has its own server. It adds its load of complexity on how to run the apps itself, you need an external server, apps often requiring some customization of the server that will run it (either mod-php or php-fpm). It means that parts of our app settings lives outside of the app, it also make updating php itself quite annoying.
- timw4mail 5y ago
  PHP does have it's own built-in server as well, although it is not really meant for production use. Global PHP configuration options have become less important over time, with resource limits and extensions being most of what has to be configured now.
  - boudin 5y ago
    My bad, I didn't know that about PHP build in server I only host one PHP app now (Nextcloud) and it has definitely been a bit of a pain in comparison with other things I self host.
    - timw4mail 5y ago
      Nextcloud is more complex than most PHP apps.
- tlackemann 5y ago
  I don't find this to be true at all. > you need an external server Spoiler, you need an external server for everything on the web; you've just been brainwashed to think serverless is actually that.
  - thecatspaw 5y ago
    You do not need an _external_ server for a lot of languages. If you use node for example you can use the express package to run a custom server, or embedded tomcat for java
defanor 5y ago
That's not quite a language feature though: one can write (Fast)CGI or similar programs in any common language.
- chippiewill 5y ago
  I've never actually tried writing CGI scripts with a non-PHP language (I've not really seen the point since it's usually more ergonomic to just use a language native-server interface like Python's WSGI). Do any other languages have the same kinds of optimisations that PHP has with FPM where it keeps the process alive but pretends it's a complete fresh execution at the language level? (getting the performance benefits of a persistent process, while having the simplicity of CGI-style execution).
  - tyingq 5y ago
    >Do any other languages have the same kinds of optimisations that PHP has with FPM where it keeps the process alive but pretends it's a complete fresh execution at the language level? I know that's how the TCL and Perl FastCGI implementations work. I suspect that's how most of them work, and there's lots of languages supported by FastCGI.
  - defanor 5y ago
    > Do any other languages have the same kinds of optimisations that PHP has with FPM where it keeps the process alive but pretends it's a complete fresh execution at the language level? I'm not aware of other languages where it is baked into a language itself, but FastCGI libraries tend to be basically drop-in replacements for CGI ones (at least it's the case with common C, Perl, and Haskell libraries; sometimes CGI and FastCGI libraries are combined, so that they are usable in either setting): you get the optimization, while still can pretend that it's a regular CGI. I guess the primary difference from PHP is just that global/static variables would survive.
fooyc 5y ago
Async code is a good way to achieve some level for performance in I/O bound workloads, but it's a pain for the programmer. Because of that I wouldn't say that it's necessarily a good thing that JS is async-first. In my opinion, high level languages should not expose async primitives to the programmer - this should be abstracted away by the language and its runtime. Go is doing this (all I/O is async under the hood), and it's awesome: You can write synchronous/sequential code and get the performances of async. I would love if other languages copied that.
- Klathmon 5y ago
  >In my opinion, high level languages should not expose async primitives to the programmer Just another reason why the "each request gets a process" architecture can work well. You generally don't need to worry about async stuff in PHP, because your request has the whole process to itself.
- afiori 5y ago
  Before being async as in async/await Javascript was also async as in having an external event loop and being event driven.
  - fooyc 5y ago
    Yup. Go too, but the programmer doesn't need to know it.
TheCoelacanth 5y ago
Isn't that exactly the same as most web frameworks except without a few lines of code saying something like "when this URL is accessed, run this function to handle it"?

resonious 5y ago

Forgive me for going a little off topic here but is it really true that JS was async-friendly from day 1? When I started using JS seriously 8 years ago, async code was horrible (callback hell, etc.) The web standards guys retrofitted native async way after the matter.

tylergetsay 5y ago
async/await is just syntax sugar around promises which are a just a nice way of organizing callbacks, so yes I'd say it's true.
nkozyra 5y ago
Probably more accurate to say it was async from day one. Which people probably realized the first time they had to deal with setTimeout The original promises syntax and chaining in ES6 were not particularly user friendly.
kall 5y ago
Doesn‘t this more or less mean "the only execution environment is event based, has a run loop outside of your control and calls your code whenever it wants" and "there is no busy sleep". So it was callback based from day one. Is that the same as async? I think it is?
- resonious 5y ago
  That makes sense, thanks! It has indeed been run in a loop from the start despite the poor ergonomics - I did not think of it in that light.

boudin 5y ago

I see this as the opposite and find it adds quite a load of complexity and prevent to do some form of optimization in an app that has its own server. It adds its load of complexity on how to run the apps itself, you need an external server, apps often requiring some customization of the server that will run it (either mod-php or php-fpm). It means that parts of our app settings lives outside of the app, it also make updating php itself quite annoying.

timw4mail 5y ago
PHP does have it's own built-in server as well, although it is not really meant for production use. Global PHP configuration options have become less important over time, with resource limits and extensions being most of what has to be configured now.
- boudin 5y ago
  My bad, I didn't know that about PHP build in server I only host one PHP app now (Nextcloud) and it has definitely been a bit of a pain in comparison with other things I self host.
  - timw4mail 5y ago
    Nextcloud is more complex than most PHP apps.
tlackemann 5y ago
I don't find this to be true at all. > you need an external server Spoiler, you need an external server for everything on the web; you've just been brainwashed to think serverless is actually that.
- thecatspaw 5y ago
  You do not need an _external_ server for a lot of languages. If you use node for example you can use the express package to run a custom server, or embedded tomcat for java

defanor 5y ago

That's not quite a language feature though: one can write (Fast)CGI or similar programs in any common language.

chippiewill 5y ago
I've never actually tried writing CGI scripts with a non-PHP language (I've not really seen the point since it's usually more ergonomic to just use a language native-server interface like Python's WSGI). Do any other languages have the same kinds of optimisations that PHP has with FPM where it keeps the process alive but pretends it's a complete fresh execution at the language level? (getting the performance benefits of a persistent process, while having the simplicity of CGI-style execution).
- tyingq 5y ago
  >Do any other languages have the same kinds of optimisations that PHP has with FPM where it keeps the process alive but pretends it's a complete fresh execution at the language level? I know that's how the TCL and Perl FastCGI implementations work. I suspect that's how most of them work, and there's lots of languages supported by FastCGI.
- defanor 5y ago
  > Do any other languages have the same kinds of optimisations that PHP has with FPM where it keeps the process alive but pretends it's a complete fresh execution at the language level? I'm not aware of other languages where it is baked into a language itself, but FastCGI libraries tend to be basically drop-in replacements for CGI ones (at least it's the case with common C, Perl, and Haskell libraries; sometimes CGI and FastCGI libraries are combined, so that they are usable in either setting): you get the optimization, while still can pretend that it's a regular CGI. I guess the primary difference from PHP is just that global/static variables would survive.

fooyc 5y ago

Async code is a good way to achieve some level for performance in I/O bound workloads, but it's a pain for the programmer. Because of that I wouldn't say that it's necessarily a good thing that JS is async-first. In my opinion, high level languages should not expose async primitives to the programmer - this should be abstracted away by the language and its runtime. Go is doing this (all I/O is async under the hood), and it's awesome: You can write synchronous/sequential code and get the performances of async. I would love if other languages copied that.

Klathmon 5y ago
>In my opinion, high level languages should not expose async primitives to the programmer Just another reason why the "each request gets a process" architecture can work well. You generally don't need to worry about async stuff in PHP, because your request has the whole process to itself.
afiori 5y ago
Before being async as in async/await Javascript was also async as in having an external event loop and being event driven.
- fooyc 5y ago
  Yup. Go too, but the programmer doesn't need to know it.

TheCoelacanth 5y ago

Isn't that exactly the same as most web frameworks except without a few lines of code saying something like "when this URL is accessed, run this function to handle it"?