5 ms·

> If you're using python for the web you're already part of the complexity problem, atleast from the perspective of someone deploying php 15 years ago. The pro

> If you're using python for the web you're already part of the complexity problem, atleast from the perspective of someone deploying php 15 years ago. The problem with deploying PHP is that it immediately gives you something for very little effort, but the effort scales incredibly disproportionately once you outgrow your need for the bare functioning minimum. I personally prefer the "modern" approach of dropping a single, statically compiled binary, which exposes a listening HTTP socket. In case of Go or Rust+Actix, this could sit directly on port 80, but as soon as you add HTTPS, ACME, virtual hosts, etc the story is basically the same regardless of language/framework choice, PHP included.

dec0dedab0de 5y ago
Oh I agree, I still get chills when I think about troubleshooting PHP. I was really just making the point that the effort to deploy python as a webapp these days would have been considered overly complex to the average developer 15 years ago. Just how some of the current stuff seems to the OP, so maybe not all seemingly complex stuff is bad.
- winrid 5y ago
  The debugging story around PHP is better than other major scripting runtimes like Node. With PHP and kcachegrind you can really understand where you're spending CPU easily. The tools for Node work but just aren't there yet. Another nice combo is Java + Mission Control.
  - dec0dedab0de 5y ago
    The debugging story around PHP is better than other major scripting runtimes like Node. With PHP and kcachegrind you can really understand where you're spending CPU easily. The tools for Node work but just aren't there yet. Another nice combo is Java + Mission Control. Fair enough, but I was thinking more along the lines of debugging logic. With python I can open up a local repl or jupyter, run the affected functions/methods, and from there I can get a nice traceback, modify code, or monkey patch something to figure it out. If I can't reproduce the bug locally, I can run a repl directly on the server to see how the code runs differently. My frustration with PHP is just memories of making an edit, refreshing the page, and crossing my fingers. Then once it's working forgetting to save it anywhere else because there wasn't a repo to begin with. I know the tooling has got much better, and PHP developers actually use deployment pipelines these days, and it was mostly caused by myself, and my co-workers not knowing any better. Still just how I remember it. And I don't think I'm the only one.
    - 9dev 5y ago
      Fair enough as well, but the internet seems full of people who’ve used php decades ago, and spread falsehoods based on that as fact. Your REPL complaint specifically is void these days - you can do exactly the same with a php interpreter, there’s kernels for Jupyter, tracebacks, repl locally and in any production environment (readline is baked in). It’s incredibly frustrating to see people discuss the language without any actual knowledge of it. Modern php involves one of the most stable package managers of any language, an extremely fast runtime with a JIT compiler and opcode cache, asynchronous code and coroutines (well, native green threads at least, but proper coroutines via an extension), mature frameworks, stateful application servers, solid standards among frameworks, containerised stacks,… it’s a joy to work with, yet people complain about standard library function names and form handling in templates from 1999.
- m3047 5y ago
  This is why you shouldn't run Python in your downloads directory: python3 -m http.server 8000 Concepts of "app" have changed and superstitious ritual has built up around the sacrament of deployment.
  - dec0dedab0de 5y ago
    If you're running malicious code it doesn't matter which directory you're running it from. And I hope noone is using http.server to deploy their python webapps. the documentation even has a warning right at the top https://docs.python.org/3/library/http.server.html https://docs.python.org/3/library/http.server.html
jread 5y ago
When did you last use PHP? It's not the PHP of 15 years ago. It scales fine when properly written and deployed.
- rollcat 5y ago
  I didn't mean scalability in terms of performance, but scalability in terms of maintenance effort. It's easy to SCP some files in, but the moment you want atomic deployments, it gets unnecessarily interesting.
  - hardee 5y ago
    Atomic deployments with PHP is basically as simple as "git pull" in a temporary working directory and copying it to a release directory..
    - t312227 5y ago
      for your "personal blog" git pull can be used as deployment - don't forget to exclude the access to the .git directory in .htaccess ... but for "serious" applications / deployment-routines this is never an option ... you have to use some kind of deployment & configuration mechanism.
  - thomaslord 5y ago
    PHP is the only language I've set up production environments for, but I can't see any reason why it would be more complicated than other languages. I have a PHP project that handles atomic deployments by pointing the web server at a symlink named "latest". New versions get deployed into their own folder in the "versions" folder, and then the "latest" symlink gets pointed to the new version. Super simple to set up, and as long as you delete old versions as you go (keeping, say 3 versions so you can roll back as necessary) that's pretty much all there is to it. This all gets triggered by a Gitlab CI workflow, so I can hit a button to deploy after merging changes. Another PHP-focused way to handle this would be deploying into a new folder, then updating the nginx config to point to that folder and running `service nginx restart`. You can also use one of the many other atomic deployment options that replace more than just the running code, at which point the only difference between deploying a PHP webapp and deploying a Java/Go/Rust webapp is what gets included in your new server/container when you build it.

dec0dedab0de 5y ago

Oh I agree, I still get chills when I think about troubleshooting PHP. I was really just making the point that the effort to deploy python as a webapp these days would have been considered overly complex to the average developer 15 years ago. Just how some of the current stuff seems to the OP, so maybe not all seemingly complex stuff is bad.

winrid 5y ago
The debugging story around PHP is better than other major scripting runtimes like Node. With PHP and kcachegrind you can really understand where you're spending CPU easily. The tools for Node work but just aren't there yet. Another nice combo is Java + Mission Control.
- dec0dedab0de 5y ago
  The debugging story around PHP is better than other major scripting runtimes like Node. With PHP and kcachegrind you can really understand where you're spending CPU easily. The tools for Node work but just aren't there yet. Another nice combo is Java + Mission Control. Fair enough, but I was thinking more along the lines of debugging logic. With python I can open up a local repl or jupyter, run the affected functions/methods, and from there I can get a nice traceback, modify code, or monkey patch something to figure it out. If I can't reproduce the bug locally, I can run a repl directly on the server to see how the code runs differently. My frustration with PHP is just memories of making an edit, refreshing the page, and crossing my fingers. Then once it's working forgetting to save it anywhere else because there wasn't a repo to begin with. I know the tooling has got much better, and PHP developers actually use deployment pipelines these days, and it was mostly caused by myself, and my co-workers not knowing any better. Still just how I remember it. And I don't think I'm the only one.
  - 9dev 5y ago
    Fair enough as well, but the internet seems full of people who’ve used php decades ago, and spread falsehoods based on that as fact. Your REPL complaint specifically is void these days - you can do exactly the same with a php interpreter, there’s kernels for Jupyter, tracebacks, repl locally and in any production environment (readline is baked in). It’s incredibly frustrating to see people discuss the language without any actual knowledge of it. Modern php involves one of the most stable package managers of any language, an extremely fast runtime with a JIT compiler and opcode cache, asynchronous code and coroutines (well, native green threads at least, but proper coroutines via an extension), mature frameworks, stateful application servers, solid standards among frameworks, containerised stacks,… it’s a joy to work with, yet people complain about standard library function names and form handling in templates from 1999.
m3047 5y ago
This is why you shouldn't run Python in your downloads directory: python3 -m http.server 8000 Concepts of "app" have changed and superstitious ritual has built up around the sacrament of deployment.
- dec0dedab0de 5y ago
  If you're running malicious code it doesn't matter which directory you're running it from. And I hope noone is using http.server to deploy their python webapps. the documentation even has a warning right at the top https://docs.python.org/3/library/http.server.html https://docs.python.org/3/library/http.server.html

jread 5y ago

When did you last use PHP? It's not the PHP of 15 years ago. It scales fine when properly written and deployed.

rollcat 5y ago
I didn't mean scalability in terms of performance, but scalability in terms of maintenance effort. It's easy to SCP some files in, but the moment you want atomic deployments, it gets unnecessarily interesting.
- hardee 5y ago
  Atomic deployments with PHP is basically as simple as "git pull" in a temporary working directory and copying it to a release directory..
  - t312227 5y ago
    for your "personal blog" git pull can be used as deployment - don't forget to exclude the access to the .git directory in .htaccess ... but for "serious" applications / deployment-routines this is never an option ... you have to use some kind of deployment & configuration mechanism.
- thomaslord 5y ago
  PHP is the only language I've set up production environments for, but I can't see any reason why it would be more complicated than other languages. I have a PHP project that handles atomic deployments by pointing the web server at a symlink named "latest". New versions get deployed into their own folder in the "versions" folder, and then the "latest" symlink gets pointed to the new version. Super simple to set up, and as long as you delete old versions as you go (keeping, say 3 versions so you can roll back as necessary) that's pretty much all there is to it. This all gets triggered by a Gitlab CI workflow, so I can hit a button to deploy after merging changes. Another PHP-focused way to handle this would be deploying into a new folder, then updating the nginx config to point to that folder and running `service nginx restart`. You can also use one of the many other atomic deployment options that replace more than just the running code, at which point the only difference between deploying a PHP webapp and deploying a Java/Go/Rust webapp is what gets included in your new server/container when you build it.