Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Taking PHP Seriously

slack.engineering

Post reply on HN
Print view View original

61–70 of 673 posts

Re: Taking PHP Seriously

#61

Post by pcwalton »

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…

> You wouldn't need much of a GC when the process is killed every time

Yes, you do. You'd be surprised how easily memory balloons out of control unless you regularly run a GC. Log minor collections sometime in Java or JS engines if you don't believe me…

Even worse, if you don't run GC regularly, you will suffer terrible locality as execution continually grows the heap (not to mention the overhead of continually requesting free pages from the OS).

Re: Taking PHP Seriously

#62

Post by leeoniya »

anarazel wrote: post #18
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…

This is my least favorite part. As soon as your program gets more complicated the amount of repeated parsing, compilation and setup you need to do for every request causes massive speed and structural issues.

> the amount of repeated parsing

Which should be near 0 if you can be bothered to enable OPcache in php.ini. Not only parsing/disk reading but also bytecode generation are bypassed.

Re: Taking PHP Seriously

#63

Post by berntb »

ken47 wrote: post #36
swalsh wrote: post #16

I work on PHP at my day job (in a public company), before this, I came from Ruby, and .NET before that. I'm convinced the reason so many successful projects use PHP, is not because of any inherent nature of the language. I think it's the people who use it. They just don't care. A successful project needs to be started by someone that cares just enough, but not too much. If you're programming in PHP, you're not runnin…

Or because it had first mover advantage in its cohort.

It didn't really, AFAIK (not a PHP guy, but old) it got traction because it was easier to get started with than the alternatives.

That said, all environments will be one of three:

1 Have warts. 2 Not be used. 3 Be in denial and claim to be perfect.

The GP had a point, perfection is the enemy of good. Something delivered is better than nothing.

Re: Taking PHP Seriously

#64

Post by alessioalex »

kowdermeister wrote: post #40
qaq wrote: post #29

Earlier quoted context omitted.

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.

Actually for that project Node would have an advantage over PHP with job handling and realtime functionality. But currently I only care about a fast MVP.

Use whatever you are most confortable with then, be it Node, PHP, Perl or others. For an MVP what matters is creating it as fast as possible.

Re: Taking PHP Seriously

#65

Post by alessioalex »

kowdermeister wrote: post #40
qaq wrote: post #29

Earlier quoted context omitted.

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.

Actually for that project Node would have an advantage over PHP with job handling and realtime functionality. But currently I only care about a fast MVP.

Use whatever you are most confortable with then, be it Node, PHP, Perl or others. For an MVP what matters is creating it as fast as possible.

Re: Taking PHP Seriously

#66

Post by ryanlm »

swalsh wrote: post #16

I work on PHP at my day job (in a public company), before this, I came from Ruby, and .NET before that. I'm convinced the reason so many successful projects use PHP, is not because of any inherent nature of the language. I think it's the people who use it. They just don't care. A successful project needs to be started by someone that cares just enough, but not too much. If you're programming in PHP, you're not runnin…

> It's a garbage language.

I'm overwhelmed by how rich of a statement that is.

Re: Taking PHP Seriously

#67

Post by alaaibrahim »

wvenable wrote: post #23
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 applicati…

> 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.

For the conversion to bytecode, that is what apc is for.

Re: Taking PHP Seriously

#68

Post by sciurus »

Siyo wrote: post #24
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 reasonabl…

"they just don't use the CGI model of spawning a new _OS_ process for every request"

Which isn't what PHP does, fwiw.

Re: Taking PHP Seriously

#69

Post by throwanem »

hawkice wrote: post #22

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…

That doesn't sound like an ops problem.

Re: Taking PHP Seriously

#70

Post by qaq »

tomschlick wrote: post #53
abritinthebay wrote: post #37

Earlier quoted context omitted.

It's extremely mature, stable, reliable, and easy to reason about. Personally I wouldn't choose it but, for a larger company, if you already have engineers that know it - and trust me many will - it's not a bad choice. This is especially true if you are just serving a simple website for a product or service, even basic e-commerce. 90% of websites out there don't need Rails, or Python, or Go, or Node.

Laravel is a pretty solid alternative in PHP vs Rails.

Y but if I have a choice I'd rather not use either :)
Post reply on HN