5 ms·
It saddens me to see some of the (largely baseless and otherwise largely historical) hate for PHP. I use Hack in my day job, which has at this point diverged fr
by cletus 7y ago
It saddens me to see some of the (largely baseless and otherwise largely historical) hate for PHP. I use Hack in my day job, which has at this point diverged from PHP, and I like it for the most part.
The thing that PHP does right that so few languages do is having a stateless core in the webserver. This is an incredibly efficient approach to serving HTTP traffic. Consider the startup cost issues with Java, or Rails' single request at a time model or even Python's startup (and GIL).
The second thing PHP does right is it request scopes everything. Simply throw away everything you created when the request ends. No dangling references and memory leaks (pretty much) like you get with stateful Java services (eg whatever servlets is now).
And the third is no multithreading in the core API. Starting and synchronizing threads is incredibly difficult to get right and adds a huge overhead to everything with little gain when you're just servicing an HTTP request, almost all of the time.
Hack has 2 things PHP7 doesn't quite have that I'd miss:
1. A better type system; and
2. async/await for cooperative multi-tasking.
I still hate the backslash for namespaces though.
- spdionis 7y ago> The thing that PHP does right that so few languages do is having a stateless core in the webserver. I never understood why the HN crowd always ignored this massive benefit of PHP, in a world where it's becoming clearer everyday that keeping things stateless across the stack provides many benefits towards managing complex systems.
- q3k 7y agoBecause this is not always a benefit. Want to cache something in between requests? You have to use memcached/redis. Want to have some background or periodic processing? Set up cronjobs, and/or use an external job queue system. Sure, if you're writing a simple CRUD app with and RDBMS backend it can be just fine. But when you're dealing with more complex work just being able to start a goroutine or use an in-memory cache structure is so much nicer than having to deal with external systems.
- kstrauser 7y agoMost of the interesting things I’ve worked on would fall down if you couldn’t cache some stuff across requests, like database connections. If every request requires a new TCP connection, even if to something lightweight and fast like a local pgbouncer instance, requests are going to be a lot slower (and the time spent context switching from userspace to kernelspace and back a lot higher) than if you could reuse one from an in-memory pool. I love stateless stuff and have started moving a lot of things to Lambdas where appropriate, but I wouldn’t use a completely stateless setup for handling large numbers of requests per unit time.
- cweagans 7y agoYou can do that in PHP. The PHP database library has a persistent mode that you can use. See the last paragraph of example 3 + example 4 here: https://www.php.net/manual/en/pdo.connections.php https://www.php.net/manual/en/pdo.connections.php
- kstrauser 7y agoSure, but then it's no longer purely stateless, and honestly no more isolated than, say, a Django app (assuming it hasn't been deliberately broken to share state across requests).
- cweagans 7y agoIt's still completely stateless from the dev standpoint (even if it's not truly stateless under the hood). It's more like a caches connection if that makes sense.
- twhitmore 7y agoRequest processing in Java (or any other sane language) is Request-scoped. The Request is a variable, the Response is a variable, they're only in local scope? And any data the developer uses will also be local -- and thus stateless -- unless they go out of their way to share something. (Caches are a common example, but harder in PHP since nothing by default is shareable.) You don't need to deal with threads if you're seeking PHP-equivalent functionality. And if you did need to deal with threads, I find your claims about overheads & difficulty hard to read without a little skepticism. An idle thread is faster to start than spawning a process, an uncontended synchronization takes only 20-250 CPU cycles (ie. a modest number of nanoseconds), and a thread pool can be sensibly managed in 2-3 lines of code.
- ragnese 7y agoI think what the comment really means by "request scoped" is that the PHP process is totally torn down after each request. In Java you can mutate global state as its running. You can leak memory until you OOM.
- cletus 7y agoThis. One unfortunate side effect is PHP's choice to use the word "global" for what isn't really global but request scope. The "global variables are bad" folks look down on the PHP global scope just because of the name. Tearing down the entire request after processing is (IMHO) a remarkable effective approach.
- ragnese 7y agoI don't know. I think that global variables, even in PHP, are still poor software engineering. It still, very much, makes the code harder to reason about and debug. In fact, my understanding of the anti-global-vars rhetoric is that it's very much about understanding and debugging.
- luckylion 7y agoTbh, that's done in modern PHP frameworks as well. ReactPHP & Co rely on you not using global variables, Symfony's architecture is built for that as well. You don't want to incur the startup cost for every request, because it's very slow. This doesn't matter a lot in single requests of course, but once you're writing APIs that get considerable traffic, you'll want to cut out those 50ms and the load.