[koffiezet]

> because of the runtime! It's so dead simple to develop and deploy PHP.

As someone who had to deploy PHP applications: hell no. For developers it might be easy, but for admins, the runtime is nowhere near good. Sure if you think deploying your site using scp, already discovered rsync to do this, or even use the cutting edge way of deploying by using a git checkout on the server, you might think it's great. But that's how you take down sites or have service interruption.

The problem is not that it cannot be done right, the problem is that the runtime enables and even promotes such bad practices, and makes doing it properly harder than it should be. And then we don't go into php extensions, performance tuning, profiling, scaling, ...

[kingdomcome50]

I deploy PHP applications all the time! I simply cannot share your sentiment though.

I cannot think of an easier deployment paradigm than what essentially amounts to a copy and paste in the simplest case (i.e. what we should strive for), and maybe one or two more steps in a more complex case (e.g. `composer install`).

An entire PHP installation can literally be copied and pasted onto another machine and "just work"(though you may need to fiddle with some paths in the .ini). Similarly PHP is fast enough that it's unlikely to ever be the bottleneck in terms of performance/scaling for 99% of use-cases.

I suppose I can agree that PHP may lend itself well to certain kinds of "bad practices", but that's true for any system if not managed well.

[koffiezet]

I think we live in different worlds, and that's a bit PHP's problem, many of it's devs and users do.

From my pov, manually logging in on a server has been something for emergencies only for a long time now (10y+), and if it's frequently required or even essential to deploy and run an application, this is a sign of bad practices. So the last thing I want to read to deploy some software is "can literally be copied and pasted onto another machine". Maybe you can do that, but you never ever should even have to consider doing this. Where is your versioning, ci/cd (testing, quality gates, automated deploy), how do you roll back in case of a problem? How do you track when new versions were deployed? How do you address patching, runtime differences, active PHP modules and php-level config? What webserver do you use, how does it need to be tuned for your workload? PHP-FPM? Do you expect something specific? Do you rely on .htaccess files? The list goes on and on.

These things are a major hassle at the scale I've had to deploy PHP services. Its best option is containerise them, and then you have a bunch of other challenges due to the process per request runtime design impacting monitoring, metrics, autoscaling, ...

[kingdomcome50]

Sorry. I wasn't advocating for "copying and pasting", rather, I was using that as an example of how simply PHP can be managed. More generally, the simplest case is often a good proxy for what to expect when dealing with more complex scenarios. Of course we automate the above behind the proper pipelines!

Many of your other concerns are big "nothing burgers". It's not like versioning, patching, config, tuning, monitoring, etc. are any less of a pain in other runtimes. At worst you could argue that it's different.

[tored]

Agree.

The strength of PHP is also its weakness.

Because of the separation between PHP and the web server it makes developing PHP really easy because the web server handles the request for you.

But you pay the price when configuring your environment. Apache conf, php.ini, php modules, htaccess, etc.

To avoid too much craziness I tend to avoid custom htaccess files, unusual php modules, or weird php.ini settings to minimize the friction when deploying.

For large project you are almost required to run containers, but even then you can’t escape the custom bash script.