Docker/containerd is your friend, especially if you don't want to maintain a LAMP stack and try to match php versions.

And Go is even similar. Instead of having to deal with docker/docker-compose, I can just put an executable somewhere. If I have multiple apps, I just set up a reverse proxy through my web server and I'm done.

It's a bit telling that I essentially need to run a docker container for something so simple. Statically compiled binaries are super simple to use.

When dealing with contractors, it's impossible not to maintain a LAMP stack. Often times I don't get to choose the technology I have to deploy, and it's not fun when I get to wrestle with PHP. Luckily the contractors' time spent fixing their deployment instructions is billable for me.

> requires fifty packages

At least the packages are often done professionally (e.g. symfony developed ones etc.). The standard library is pretty great so you don't always have to rely on packages. Often the same third party packages you'd have to rely on in PHP, you'd have to rely on similar packages for go.

> you get segmentation faults

Not sure where you get this from. In my 6 or so years of professional PHP development I've never seen a segmentation errors.

Anyway, still prefer a single go executable. It's just so much simpler.

Ouch.

If accurate, then it's sad to see PHP to fall this way. I remember the good days when all it took to deploy your PHP project was (S)FTPing the code to a folder and pointing Apache to it.

You can still do that today, even with laravel and composer. There's no requirement to make your deployment process any more complicated...