Re:The Rise of Hybrid PHP: Blending PHP with Go and Rust
by dakiol on Saturday August 30, 2025 @05:04PM
(#45077990)
The one thing I don't like about PHP is that the whole application is bootstraped (and autoloading and the configuration is re-evaluated) in every single http request. Sure thing there's cache and all, but it just doesn't feel right (compared, to, for instance, an http server written in golang)
[ Parent
| on HN ]
Re:The Rise of Hybrid PHP: Blending PHP with Go and Rust
by PetahNZ on Saturday August 30, 2025 @08:10PM
(#45079157)
This is one of the best things about PHP IMO. It makes it very easy to scale out.
Re:The Rise of Hybrid PHP: Blending PHP with Go and Rust
by bornfreddy on Sunday August 31, 2025 @01:38AM
(#45080624)
Yup. No shared state by default.
Re:The Rise of Hybrid PHP: Blending PHP with Go and Rust
by const_cast on Sunday August 31, 2025 @02:52PM
(#45085892)
It also makes it much easier to debug and forces the complexity down.
Re:The Rise of Hybrid PHP: Blending PHP with Go and Rust
by klaussilveira on Saturday August 30, 2025 @05:10PM
(#45078039)
There are well documented and production-ready libraries that you can use to run your own servers with PHP alone, no need for fpm or mod_php. PHP's JIT is pretty impressive and you would be blown away by the results.
https://www.php.net/manual/en/book.ev.php
Re:The Rise of Hybrid PHP: Blending PHP with Go and Rust
by duskwuff on Saturday August 30, 2025 @05:36PM
(#45078202)
It doesn't have to be. Some PHP runtimes allow an application to run in a mode where a single script execution processes multiple HTTP requests:
Re:The Rise of Hybrid PHP: Blending PHP with Go and Rust
by mhsdef on Saturday August 30, 2025 @05:48PM
(#45078278)
This is one of the things I do like about PHP.
Intrinsically minimized state (to a certain degree).
Re:The Rise of Hybrid PHP: Blending PHP with Go and Rust
by creatonez on Saturday August 30, 2025 @10:57PM
(#45079955)
You're right. It's a completely asinine approach. Especially when PHP itself is used as a templating language.
And solutions that try to fix this (custom templating engines, runtimes that run the whole thing inside a continuous PHP process) are simply putting lipstick on a pig.
The solution is to use a language that wasn't originally called "Personal HomePage"