Hacker News Reader

Comment by TekMol | Hacker News Reader

I actually love the approach to tear down everything after each request.

It makes reasoning about the system much easier.

I first came across the term 'shared nothing' in... 2000 or 2001? (John Lim from adodb project, but I'm sure he didn't coin it). There is a difference in thinking required for shared nothing, but as you say, it does typically make reasoning easier - fewer moving parts to potentially complicate your processing.

What I love about this approach is that if I fuck up somewhere specific and a user triggers that part then the whole app doesn't go down.

This actually reminds me a bit of CGI ( https://en.wikipedia.org/wiki/Common_Gateway_Interface ) or its later variants.

Personally, i think that PHP's request-response workflow is infinitely easier to deal with than that of servlets in Java or whatever abstractions other technologies out there have, even if only when scaling isn't a concern (which is perfectly passable for some systems out there).

My ideal language for getting things out the door would be something a bit like PHP, but with the standard library of .NET/Java (LINQ or Streams in particular), the wider ecosystem of Python, simplicity of Go and a decent type system on the top of it all, that'd process requests much like PHP does (or at least would only make you think it does, though abstractions that are leaky are arguably worse than none at all).

PHP's programming model definitely should remind you of CGI, because it was a CGI module: https://en.wikipedia.org/wiki/PHP#Early_history

Until you need to talk to db, where you may want to have a persistent connection, so hacks required in php-fpm to support it.

PHP with Java std lib is called JSP, with .NET it's called ASP; the request model is similar and the packaging can be quite minimal, even if the good practice favor complexity.

Also I don't think that you can have a simple language like Go and a decent type system like Typescript, to me those properties are in opposition.

> would be something a bit like PHP, but with the standard library of .NET

Try the PeachPie compiler then ;)

Indeed. But the difference between modern Perl/Ruby/Python/Java/Whathewer frameworks that use some kind of application container and PHP is that in the first case you know what is shared and work in the world with shared things, while for PHP there is shared nothing except for implementation defined shared random things that you have no idea that might be shared state.

To do this in Python, couldn't you just fork the Python process after initializing the web framework etc. and handle the request in the forked process? Optionally keep a pool of pre-forked worker processes so that the request doesn't have to wait for the forking. Sort of like Android's zygote process.

In principle, yes. But forking an application server gets tricky -- some resources (like database connections) aren't fork-safe, and need to be recreated after forking.

Fork is kind of expensive in most OS, even it's relative cheap compared to start a new process from scratch, but still much slower than few function calls.

Well, yes, but the point was to get a process per request just like PHP, so you'll have to start those processes one way or another.

Anyway, it appears uwsgi can be configured to do this, using fork-server[1] and maybe max-requests[2], although it only works with Perl at the moment.

[1] https://uwsgi-docs.readthedocs.io/en/latest/ForkServer.html

[2] https://uwsgi-docs.readthedocs.io/en/latest/Options.html#max...

The whole PHP opcache hack works reliably only on platforms that have fork(2).

Me too, it's amazingly simple. It's a radically different language but if you really like that, you should check out Elixir/Phoenix.

Reply on news.ycombinator.com