On a related note I often feel like the goal of these trends in general is to re-invent what the average PHP + MySQL (LAMP stack) web space used to be. Something where someone else manages your server, where disk space and so on were just an abstraction, something you deploy some file (back then some PHP, now often a Docker image) and it just runs. Somehow over some web interface, sometimes via FTP there’s also access to logs. Only if you had a decent enough internet connection, deployment went a lot faster compared to now. I know there’s testing, etc. that are good developments but some parts are due things like pulling base images, installing packages into them, building things on top, etc.
I know, I am oversimplifying, but it feels like largely that’s the overall goal with many cloud products. Bringing back the ease of just uploading some PHP. Just that people use other languages as well.
I wonder what would have happened if stuff like [Hack](https://en.wikipedia.org/wiki/Hack_(programming_language) came along a bit earlier and became big. Maybe that could have lead to other languages targeting the VM and we’d have seen things similar to the JavaScript world happening.
As an AWS Lambda (and also Azure Functions) user (developer) I agree. I have to admit, that the downsides (limited debuggability) also remind it to the early PHP times. (Personally I find Azure smoother in local emulator/debuggability support)
Still I think it has its merits, and is a good choice in many cases.
Yes exactly! That’s why I have been talking about FastCGI. I would like the deployment model of PHP without actually using PHP. When you switch to Python or Ruby, you get a better language, but all of the sudden you have all these other problems (managing a server).
There’s no reason that those 2 things should be coupled (language and deployment model). Maybe when modphp and modpython were a thing they were coupled, but these days FastCGI seems to be the more standard / decoupled / server-agnostic deployment model.
But you also need container support for Python/Ruby. virtualenv/bundler may suffice in some cases but you also want to deploy specific versions of native libraries, which are better handled by containers.
There’s no reason that you can’t do that with a FastCGI process in a container, although as far as I know almost nobody does it. Some hosting provides run CGI in chroot, but you can’t really install and libraries there. It’s just a single script.
BTW I tried NearlyFreeSpeech’s fastcgi support, mentioned in the thread, and they use FreeBSD jails with a fixed “realm” that they update every quarter or so. It’s a big bundle of software like Python, Ruby, and even Go and Rust compilers on FreeBSD. So that is not quite what I want either.
Also, although FastCGI is meant for front ends, it’s not a stretch to imagine it as a basis for a “FaaS” platform.
People complain about the shell language (which I’ve taken pains to clean up), but YAML is a worse language than shell (and double that for Go templates generating YAML or JSON)
We need to bring the interactivity of Unix shell back to distributed systems. The great analogy is that YAML configuration is basically like “IBM Job Control Language” before Unix came around.
Shell is already used to configure local development environments, and he’s complaining we have to push to clusters all the time to test, which is a great point. We should be able to test locally.
On a related note I often feel like the goal of these trends in general is to re-invent what the average PHP + MySQL (LAMP stack) web space used to be. Something where someone else manages your server, where disk space and so on were just an abstraction, something you deploy some file (back then some PHP, now often a Docker image) and it just runs. Somehow over some web interface, sometimes via FTP there’s also access to logs. Only if you had a decent enough internet connection, deployment went a lot faster compared to now. I know there’s testing, etc. that are good developments but some parts are due things like pulling base images, installing packages into them, building things on top, etc.
I know, I am oversimplifying, but it feels like largely that’s the overall goal with many cloud products. Bringing back the ease of just uploading some PHP. Just that people use other languages as well.
I wonder what would have happened if stuff like [Hack](https://en.wikipedia.org/wiki/Hack_(programming_language) came along a bit earlier and became big. Maybe that could have lead to other languages targeting the VM and we’d have seen things similar to the JavaScript world happening.
As an AWS Lambda (and also Azure Functions) user (developer) I agree. I have to admit, that the downsides (limited debuggability) also remind it to the early PHP times. (Personally I find Azure smoother in local emulator/debuggability support)
Still I think it has its merits, and is a good choice in many cases.
Yes exactly! That’s why I have been talking about FastCGI. I would like the deployment model of PHP without actually using PHP. When you switch to Python or Ruby, you get a better language, but all of the sudden you have all these other problems (managing a server).
There’s no reason that those 2 things should be coupled (language and deployment model). Maybe when modphp and modpython were a thing they were coupled, but these days FastCGI seems to be the more standard / decoupled / server-agnostic deployment model.
https://lobste.rs/s/xl63ah/fastcgi_forgotten_treasure
But you also need container support for Python/Ruby. virtualenv/bundler may suffice in some cases but you also want to deploy specific versions of native libraries, which are better handled by containers.
There’s no reason that you can’t do that with a FastCGI process in a container, although as far as I know almost nobody does it. Some hosting provides run CGI in chroot, but you can’t really install and libraries there. It’s just a single script.
BTW I tried NearlyFreeSpeech’s fastcgi support, mentioned in the thread, and they use FreeBSD jails with a fixed “realm” that they update every quarter or so. It’s a big bundle of software like Python, Ruby, and even Go and Rust compilers on FreeBSD. So that is not quite what I want either.
Also, although FastCGI is meant for front ends, it’s not a stretch to imagine it as a basis for a “FaaS” platform.
Also, this is post is very on target; the OP is saying a lot of things I want to address with Oil: https://news.ycombinator.com/item?id=25483270
Summary: