> PHP's value proposition has always been one thing - ease of deployment. I think that advantage may have been real at one time, when FTP deploys were a thing.

> PHP's value proposition has always been one thing - ease of deployment. I think that advantage may have been real at one time, when FTP deploys were a thing. The myth loves on. Folks that chant this praise are often not be the same folks that have to maintain the webserver side of things, though. Easy to deploy looks like this: ./foobar --port=80 > Listening on port 80, ready for traffic That could be Go, could be Rust. But not PHP. PHP webserver / application separation does bring some advantages - for example if you bring your application to a corrupted state or crash it, it will go and die. Recovery is, well "implied". But deployment wise, no. It actually seems to be a LOT harder to run PHP that at first blush. Take this example: https://github.com/laravel/valet/issues/290 https://github.com/laravel/valet/issues/290 Turns out if you php-fpm app one Tuesday at 15:43 starts to write more than 4k to stderr (maybe it writes some nice verbose logs after being hit by some recoverable error), you will find yourself wondering what does "upstream sent too big header while reading response header from upstream" imply while your endpoint responds with 502. This is just one possible footgun .. ekhm .. tuning option.