6 ms·

Wait, Go hasn’t had any revolutionary change since it arrived 10 years ago. It is still basically the same language/package. I’m not saying that is bad, but w

Wait, Go hasn’t had any revolutionary change since it arrived 10 years ago. It is still basically the same language/package. I’m not saying that is bad, but why does a language need to be constantly revolutionary if it solves what it sets out to solve well? Catch up to other languages? You can easily argue the opposite, that other languages has finally catched up to PHP, ease of deployment, ease of horizontal scaling, fast reload/build time, built in string templating, simplified variable syntax (auto, var), etc I can go on, but if you already framed the question to the disadvantage of one party you will not really get a fair answer.

creshal 6y ago
> 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.
- hu3 6y ago
  If anything PHP is THE language that solves what it sets out to solve. It does a few things and does them well.
- mekster 6y ago
  What is the problem of admitting PHP solves the problem of quickly deploying web sites?
  - fetbaffe 6y ago
    Because it fundamentally destroys the current agenda within software development, that tools should be created for developer satisfaction, not customer satisfaction.
    - deleted 6y ago
      [deleted]
  - sfkdjf9j3j 6y ago
    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.
mekster 6y ago
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.
- 411111111111111 6y ago
  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.
  - vertex-four 6y ago
    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.
    - 411111111111111 6y ago
      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.
oblio 6y ago
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.

creshal 6y ago

> 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.

hu3 6y ago
If anything PHP is THE language that solves what it sets out to solve. It does a few things and does them well.
mekster 6y ago
What is the problem of admitting PHP solves the problem of quickly deploying web sites?
- fetbaffe 6y ago
  Because it fundamentally destroys the current agenda within software development, that tools should be created for developer satisfaction, not customer satisfaction.
  - deleted 6y ago
    [deleted]
- sfkdjf9j3j 6y ago
  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.

mekster 6y ago

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.

411111111111111 6y ago
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.
- vertex-four 6y ago
  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.
  - 411111111111111 6y ago
    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.

oblio 6y ago

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.