Other languages haven't caught up on PHP about ease of deployment.

If you need a fast hot reload, it isn't trivial in other languages. PHP does it with no effort. Save and refresh runs the updated code instantly, not to mention asking people to run PHP app is far easier as every general hosting provider has PHP installed.

On the other hand, language structure is quite behind others but can't blame when it had been around since 20+ years ago.

The new type hinting is so basic, not sure how realistically useful it is compared to typing in TypeScript.

Thats hot patching, not reloading as I've come to know it in the web development world.

Hot reloading works the same for all languages I know, which is a hardcoded port pushing notifications to clients that they should reload the browser.

The client is mostly a js library or a browser plugins. Either works.

I know it's also used differently in some contexts, but they wouldn't apply here as far as I can tell. There aren't any long running processes that need to reload the code after all. It's only read when is actually executed. Which is never unless you use the hot reloading I was talking about earlier... Or trigger it manually, making it a regular reload.

You're entirely missing the point by focusing on why someone may or may not have used the wrong words - with an application written in many other languages, you have to do something special to be able to update some server-side code and have that new code be run when you next hit the server.

If pointing out that he's using the wrong technical term is 'missing the point', I'm not sure there was one to begin with.

most examples of why php is so easy to deploy show it with hello world examples you'd never encounter in the wild.

yes, you can edit the php code directly on the server that is executing it. just like with python, nodejs, ruby ... and even java if you're not worrying about scalability.

there is really very little difference if you ignore the fact that it gets hard with the codesize and the environment in which the service is deployed in. the language is almost always the smallest challenge.

and fwiw, i'm definitely not "against" php in any way. i think ssr script languages are wonderful for easy development - especially if you combine them with something like intercoolerJS for interactivity. extremely easy to get started and you're even able to make ssr-"components" by just fetching each segment separately, which isn't really any overhead with HTTP2 nowadays.

I can, on my local server, change the code, hit it again, and have my changes reflected in what happens. Doing that with Python, Node.JS, Ruby, or Java requires extra configuration. That's the point.

Rewriting a bunch of text files isn't atomic, so you need to take a planned outage or atomically rename the source dir so you don't serve 5xx errors from parsing half-written source. At that point you might as well have a deploy process, which can be as simple as "rsync && mv" into each host.

Indeed, but again, I don’t care about that while I’m developing locally.

Not sure if you even understand what you're talking about.

As for node.js, I set up pm2 to watch for file changes and restart ts-node process and this takes a few seconds, which is slower than I can hit alt-tab back to the browser, which is annoying to see 'Bad Gateway' error page quite often, not to mention embarrassing to explain and help set it up to someone new to other languages than PHP.

PHP is instant and I'd like to know if there's a solution in node.js that can do the same.

That's not hot reload, and pretty much every language has frameworks that are capable of that.

Hot reload is trivial in Common Lisp, and only marginally less so in Elixir. Turns out it's just not enough of a differentiator to actually tip the scales.

Go itself is also not a revolutionary language, actually the fact that it isn't revolutionary is one of it's "raisons d'etre". Go is mixing up various popular concepts into a reasonably compact package.

> why does a language need to be constantly revolutionary if it solves what it sets out to solve well?

That's a very big If in PHP's case.

If anything PHP is THE language that solves what it sets out to solve.

It does a few things and does them well.

What is the problem of admitting PHP solves the problem of quickly deploying web sites?

Because it fundamentally destroys the current agenda within software development, that tools should be created for developer satisfaction, not customer satisfaction.

Am I the only one scratching their head at this argument in 2020? 15 years ago when shared hosting was more common I would buy it, but I just don't find myself wasting time on figuring deployments out in other languages/frameworks. By far the biggest time sink in that area is setting up continuous integration and monitoring/alerting systems, and those problems are exactly the same regardless of language.