Live data from Hacker News

Taking PHP Seriously

slack.engineering

11–20 of 673 posts

Re: Taking PHP Seriously

#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 route of using an event loop or daemonizing your "server" to serve up requests? I can understand why Node.js does it (otherwise the async nature would just be an annoyance for no gain), but why haven't there been any other server-side languages that not only work well like this, but actively target it?

It seems like it would be easier for everyone involved. You wouldn't need much of a GC when the process is killed every time, you don't need to worry about async IO or multi-threading or catching errors or any of the other annoyances that come with most of the traditional "event loop" way of doing things.

So what's the catch?

Re: Taking PHP Seriously

#12
That example of "Surprise type conversions" is crazy. Did not know that.

While i do not think PHP is a perfect programing language. There is one think i LOVE about PHP, it is that the PHP "community's" default way of documenting code behavior is to make a small example.

When i read most other languages documentation i read it. Then i need to make a small test to verify that i understood it.

All those tests takes a long time to make and i have to make them over and over again, every time i forget the way a function behaves.

Re: Taking PHP Seriously

#13
It is interesting that author does not mention the performance improvements of PHP 7. I have read with PHP 7, HHVM does not have the performances any more. I wonder author cared to test that in their codebase.

Re: Taking PHP Seriously

#14
I worked in PHP at Box for about 3 years. This article does a great job of reflecting my sentiments on the language. In particular, I'm glad to see that the author recognizes that there are some glaring issues with PHP that aren't tradeoffs in favor of something else - they're just warts.

That said, PHP is really good at what it does - providing a framework and environment for serving web requests efficiently and easily. I find developing in it very fluid once you know how to avoid the warts. A lot of the flak that PHP receives as a language revolves around the fact that it doesn't actively discourage developers from doing bad things, and sometimes the language itself does some crazy stuff (as shown in the article with the divide-by-zero behavior). I think this is a huge shortcoming of the language, especially as code bases and teams grow and your organization needs to depend on the language more and more for safety. That said, I still don't hate working with it. Sometimes I rather enjoy how quickly I can develop in PHP, and how reliable it can be if you know how to operate it.

I think in all, it was a bit of a slog to get to the point where I am with PHP today - to the point where I understand its strengths and flaws, but ultimately I think it does have a place in modern webapp development. I think Hack and HHVM are excellent spiritual successors to what PHP tried to (is trying to?) accomplish, and that they do a great job of hiding or eliminating some of the warts of their parent language.

Kudos to the Slack team for being pragmatic about their approach to the technology, and hey again to all of my former colleagues working there!

Re: Taking PHP Seriously

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

Re: Taking PHP Seriously

#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 running around talking about "convention over configuration" giving talks, or trying to make your code beautiful. It's a garbage language, and you know it. But it allows you to get something up and running, so dang quick. You're failing while the other guy is still updating his gem file. You're advertising while the other guy is trying out some fancy new deploy script. You're incorporating feedback while the other guy is just starting to get to work. When he finally fails, he's used up half his runway, whereas you, the guy who didn't give a fuck about your code has gotten past that first failure, and are finally getting some traction.

Hopefully, the next guy to join the company will clean up your shit. The other guys code may not look like shit, but it doesn't solve any useful problems... so they never got the chance to hire that next guy.

Re: Taking PHP Seriously

#17

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…

Elixir and the Phoenix framework work like this, with a process spawned per request.

Re: Taking PHP Seriously

#18

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.

Re: Taking PHP Seriously

#19

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…

> So what's the catch?

About 2-3 orders of magnitude in performance. That’s the catch.

And it’s the reason why even with PHP you use things as opcaches, cache database results in external daemons, you use process pools with fastcgi instead of actually creating new processes, etc.

And hacking those things on top of PHP make your program even worse to reason about than just using a daemonized system with actor framework.

Re: Taking PHP Seriously

#20
post #8

Well this is seriously making me rethink my opinion on the PHP workflow, if Hack is as much of a game changer as the article claims? Could anyone here comment on their experiences with it, and its pitfalls?

Well HHVM is quickly losing ground to PHP v7 in terms of speed. I'm not sure which is "fastest" any more, but IIRC it's close enough that if you want to switch for the "speed boost" I'd argue it's not worth it.

In terms of Hack as a language, it's very similar to the JavaScript->TypeScript relationship. It's still mostly PHP, but it doesn't quite get the new PHP features as quickly, and there is the chance that there could be incompatibilities in the future which could cause new PHP code to start looking and acting differently than Hack code.

Post reply on HN