Hacker News Reader

Comment by Zababa | Hacker News Reader

I have a few questions:

- Is the "your app gets initialized and torn down for every request" true for frameworks like Laravel and Symfony?

- Does this model uses OS threads? Does it uses green threads?

And then a few remarks about the language:

- I feel like the Go model is a way better model for server software than async. Since PHP is mostly used for server software, I feel like they shouldn't go with async. Python is currently going through the transition and it's painful and long.

- It feels a bit weird to see how full of objects PHP is. Modern languages (Go, Swift, Rust, TypeScript) tend to use less objects, and more plain imperative code or slightly functional code in my experience.

View on HN

> Is the "your app gets initialized and torn down for every request" true for frameworks like Laravel and Symfony?

Yes, though heavy optimization in opcode caching and JIT keeps it fast and the primary process manager today (php-fpm) generally keeps a pool of PHP processes persistent. Each request is initialized from scratch but there's no disk nor interpreter hit after the first.

There are, of course, frameworks that simply handle HTTP requests directly (amphp, swoole) that operate as persistent application servers, so state is maintained.

> Does this model uses OS threads? Does it uses green threads?

No. PHP webserver backends are generally a long-lived forking model.

> I feel like the Go model is a way better model for server software than async

Swoole [1] offers a coroutine and channel model. It's incredibly fast and the techempower benchmarks [2] attest to the raw speed.

> It feels a bit weird to see how full of objects PHP is

Agreed. It's often way over the top with Java-esque OOP complexity. It does depend on the libraries in question but the popular ones are very heavy (Symfony). You can of course write very simple imperative code just fine too.

[1] https://www.swoole.co.uk/

[2] https://www.techempower.com/benchmarks/

I don't agree with Symfony being inherently "very heavy". As set of framework components, you can any part you find useful, and wire to together yourself, if necessary. e.g.

https://symfony.com/doc/current/configuration/micro_kernel_t...

Many other PHP projects, such as Laravel and Drupal pick-and-choose Symfony framework components in this way.

Sorry, I should have clarified "heavy" in terms of the level of OOP [1] insanity but yeah Symfony is very modular.

[1] e.g. "Symfony\Component\DependencyInjection\Loader\Configurator\ContainerConfigurator"

> in terms of the level of OOP [1] insanity

I would have to question how relevant a piece of core plumbing is to a regular user of the framework, as a regular user of the framework would likely never come across this class.

Also if you're working in the domain as a Symfony core developer, the idea of a ContainerConfigurator is not so insane, if you're developing a dependency injection container.

Look at what I was replying to. The guy commented about the amount of OOP in PHP.

That"your app gets initialized and torn down for every request" is _the_ best feature of PHP. This may sound strange first, but it's true. With web applications written in any other language you have a stateful server running all the time with the following "problems":

* If you have a memory leak your complete server will get killed some time later when running out of memory * If you have a bug which crashes your web server every running request is killed * You get all the hard-to-find concurrency bugs when multiple requests concurrently can access some objects.

With PHP's model of (1) initializing and destroying all the state on every request and (2) every request running in it's completely isolated virtual space you don't have any of these problems.

And if you really want to have a long-running server with shared space you can have that too, take a look at Laravel Octane.

Reply on news.ycombinator.com