Hacker News Reader

Comment by dgb23 | Hacker News Reader

> Also, might make more sense to choose java if you need types.

Java is not a replacement for "PHP with types". There is currently nothing you can deploy as easily as a PHP web app. The operational overhead is very low because cheap, robust hosting providers have decades of experience with the most typical LAMP style stack.

I would also disagree in terms of language features. Gradual typing through type hints (and other 'on demand'-style consistency features) is a very ergonomic way to introduce consistency during development (plus implied performance optimizations). You write in 'free-dynamic-mode' initially and then add type hints where they make sense bit by bit, typically in function signatures. There are many examples of this in the (semi?) dynamic world.

View on HN

You couldn't be more wrong about the ease of deployment.

PHP is one of the hardest things to deploy. You need at least a web server and a process manager. Most popular choices are nginx + PHP-FPM or Apache + libapache2-mod-php.

You also need to learn how to properly configure both of them, since both have like a million options, and default installation doesn't work in a lot of cases (e.g. uploading of files larger than a few MB).

If you don't want to use libapache2-mod-php, you will have to figure out how to deploy two different services, which makes things difficult in a Docker environment.

---

As opposite to that, deployment story with Go, Rust, and similar compiled-to-a-single-binary languages, is a lot easier. Just drop the binary to a server or add it to a Docker container.

Many smaller PHP web sites are deployed on VPSes and managed with CPanel or Plesk control panels. None of what you describe is necessary. The web server is pre-configured and PHP settings can be easily changed. Even setting up PHP on Ubuntu or CentOS is a 5 minute job. Tweaking configuration settings for max upload, max post size, etc. are very common and well understood.

Once everything is in place, most deployments are as simple as copying the new build over and changing a symlink. No process restarts, nothing.

"Easy to deploy" and "Many cheap webhosts are already configured for it" are still very different things. I never found it helpful to conflate them. For example, a VPS with CPanel/Plesk is quite the dependency. As is "a cheap PHP webhost with servers configured for your PHP scripts".

I look at it this way: PHP apps are so easy to deploy, it's a commodity. I run my own dev servers then move them to VPSes, billed to the client, for deployment.

Seconded. I was left scratching my head for a long time trying to work out why php-fpm, when reloaded via systemctl on CentOS 7, was not setting-up /var/run/php-fpm.sock with the correct ownership. I eventually had to write a shell script to resolve the issue. The version of php-fpm in question, by the way, was a more up-to-date version than the CentOS 7 default. Anyway, that's just one example of how mdoern PHP deployments differ from the over-hyped static deploys of yesteryear where you just FTP a bunch of .php files into your DocumentRoot.

For reference, related php-fpm config directives: listen.owner, listen.group, listen.acl_users, listen.acl_groups

And probably some SELinux config as well if the installed php package doesn't have them.

Reply on news.ycombinator.com