Taking PHP Seriously • Hacker News Board

Re: Taking PHP Seriously

#21

Post by tyingq » Thu, Oct 13, 2016, 9:17 PM UTC

Klathmon wrote: post #11

The article points out that arguably the best part of PHP is the "shared nothing lifecycle". That each request starts new, and the process dies at the end of the request. It's by far my favorite part, and I completely agree that it makes "reasoning about" (boy do I hate that phrase...) your program much easier. Why are there no other "competitors" in this space? Why do most other languages go with the alternative rou…

>>Why are there no other "competitors" in this space?

There are. Any language that supports either fastcgi, or runs as an apache plugin (or similar) functions in the "each request starts new" space. There's certainly others, but Python and Perl are both good examples.

Starting new with each request does, of course, mean lots of re-work that shouldn't have to be done with each request. It does initially keep complexity down, but at scale, the applications I've worked with have to use a shared cache (like acpu) to avoid that rework and meet performance goals.

Re: Taking PHP Seriously

#22

Post by hawkice » Thu, Oct 13, 2016, 9:18 PM UTC

The shared-nothing model works great... if either you're just one developer or you've got a semi-competent Ops/DevOps setup. My first job out of college used PHP with one of the Rails-a-likes PHP has. During our user onboarding process, we'd poll the server to see if a data import finished, but since the requests shared _nothing_ and the Ops guy didn't understand PHP, it would load/run millions of lines of framework code for every single tiny polling request. On launch our site crashed because two people used it at the same time. Bananas.

There's a way to make Apache fork after some code has already been run, but boy howdy if you don't do that and love those mega-frameworks.

Re: Taking PHP Seriously

#23

Post by wvenable » Thu, Oct 13, 2016, 9:19 PM UTC

Klathmon wrote: post #11

The article points out that arguably the best part of PHP is the "shared nothing lifecycle". That each request starts new, and the process dies at the end of the request. It's by far my favorite part, and I completely agree that it makes "reasoning about" (boy do I hate that phrase...) your program much easier. Why are there no other "competitors" in this space? Why do most other languages go with the alternative rou…

The startup time can be pretty extreme -- although you can mitigate much of this with various caching strategies but the typical PHP request involves reading dozens to maybe hundreds of files from disk, compiling them into byte code, and then executing that byte code, and then deallocating everything.

And even if you cache everything, you still have the code necessary to setup the runtime environment of you application which runs on every request and does the same thing.

But still, I do actually like that model and it does have many advantages for development. But it's really hard to work in PHP, the language, after using something better.

Re: Taking PHP Seriously

#24

Post by Siyo » Thu, Oct 13, 2016, 9:19 PM UTC

Klathmon wrote: post #11

The article points out that arguably the best part of PHP is the "shared nothing lifecycle". That each request starts new, and the process dies at the end of the request. It's by far my favorite part, and I completely agree that it makes "reasoning about" (boy do I hate that phrase...) your program much easier. Why are there no other "competitors" in this space? Why do most other languages go with the alternative rou…

There are plenty of competitors in this space, they just don't use the CGI model of spawning a new _OS_ process for every request. You have Erlang/Elixir that have their own lightweight processes that don't share memory and have independent GC. And you can build similar systems on Java/Go. The difference is that in those language you have a choice. There are certain types of applications that you just can't reasonably make in PHP.

Re: Taking PHP Seriously

#25

Post by sitharus » Thu, Oct 13, 2016, 9:19 PM UTC

Klathmon wrote: post #11

The article points out that arguably the best part of PHP is the "shared nothing lifecycle". That each request starts new, and the process dies at the end of the request. It's by far my favorite part, and I completely agree that it makes "reasoning about" (boy do I hate that phrase...) your program much easier. Why are there no other "competitors" in this space? Why do most other languages go with the alternative rou…

The catch is overhead. There are things you need at the start of each request - global configuration, database connections etc - that other systems do once at startup. PHP has to do this every request.

Re: Taking PHP Seriously

#26

Post by sfrailsdev » Thu, Oct 13, 2016, 9:19 PM UTC

Klathmon wrote: post #11

The article points out that arguably the best part of PHP is the "shared nothing lifecycle". That each request starts new, and the process dies at the end of the request. It's by far my favorite part, and I completely agree that it makes "reasoning about" (boy do I hate that phrase...) your program much easier. Why are there no other "competitors" in this space? Why do most other languages go with the alternative rou…

Probably because allocating a thread to every request is less efficient then a bunch of event loops with async. Ideally you do both, but a lot of languages choose to make concurrency something done at the process level and are event driven asynchronous web servers which are deployed as multiple processes, which adds a lot of overhead compared to threads. I think Golang has a nice balance with goroutines, as I understand things.

Re: Taking PHP Seriously

#27

Post by grok2 » Thu, Oct 13, 2016, 9:19 PM UTC

Klathmon wrote: post #11

The article points out that arguably the best part of PHP is the "shared nothing lifecycle". That each request starts new, and the process dies at the end of the request. It's by far my favorite part, and I completely agree that it makes "reasoning about" (boy do I hate that phrase...) your program much easier. Why are there no other "competitors" in this space? Why do most other languages go with the alternative rou…

Performance/scaling?

Re: Taking PHP Seriously

#28

Post by mtrn » Thu, Oct 13, 2016, 9:19 PM UTC

If people would focus more on usability, comprehensibility, clear algorithms and project structure and precise requirements we could probably skip debating over languages altogether, because programs would look beautiful in any language.

Re: Taking PHP Seriously

#29

Post by qaq » Thu, Oct 13, 2016, 9:20 PM UTC

kowdermeister wrote: post #15

qaq wrote: post #10

For greenfield project main question would be why? It's not horrible but what do you exactly gain? With so many options around it's actually hard to make a case for PHP (and I have being using it since 2000).

I'm currently hesitating between PHP and Node.js for a new side project and I'm leaning towards PHP simple because I could do it 50% faster due to my experience with it.

Node is actually one case where depending on the project it could be very easy to make a case for PHP :) if you need a simple API backend you can use PHP and not deal with whole async thing.

Re: Taking PHP Seriously

#30

Post by Kenji » Thu, Oct 13, 2016, 9:20 PM UTC

Klathmon wrote: post #11

The article points out that arguably the best part of PHP is the "shared nothing lifecycle". That each request starts new, and the process dies at the end of the request. It's by far my favorite part, and I completely agree that it makes "reasoning about" (boy do I hate that phrase...) your program much easier. Why are there no other "competitors" in this space? Why do most other languages go with the alternative rou…

Exactly. The "shared nothing lifecycle" really lets the programmer (knowingly or unknowingly) embrace RESTful design. Too bad the language doesn't have strict typing like Java. Otherwise it'd be even more convenient and safer in my eyes.