Live data from Hacker News

Taking PHP Seriously

slack.engineering

41–50 of 673 posts

Re: Taking PHP Seriously

#41
I've looked at some of the new PHP feature and was quite impressed. There are trait, multi-value return, pattern matching, and destructure.

Re: Taking PHP Seriously

#42
Hack is awesome, but we decided to go with PHP 7 and this choice was primarily made because of lack of tooling on the Hack side. Things like New Relic are not available and these type of things do matter a lot when it comes down to choosing the programming language.

I must say that PHP 7 is a great language nowadays. Most of the modern concepts are baked into a language or are about to be developed.

At some point, I wish Hack and PHP merge into a single language in the future, somewhat similar to what happened to Node and iojs. I'm not sure if Hack is going to be around in 5 years, but I'm pretty confident about PHP.

I'd definitely love to see more articles about Hack and people's experience with using it in production.

Re: Taking PHP Seriously

#43
post #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 framewor…

Unless you're writing in pure hand-optimized assembly language, 3 orders of magnitude in performance is way more than you could claim. PHP web requests commonly execute in hundreds of ms (of course, here I generalize mercilessly, but that covers most of cases I know of and that's what most sites aim for). So you say your non-PHP requests which would do the same thing would finish in hundreds of microseconds? I have very hard time believing it.

> And it’s the reason why even with PHP you use things as opcaches, cache database results in external daemons

You make it sound as if the idea of caching was invented by PHP programmers to address language deficiencies. Nothing can be further from the truth. Everybody uses caches, because it's faster. If you don't use DB cache, there's no way in the universe you can make you app fast under any significant load.

> And hacking those things on top of PHP make your program even worse to reason about

You have very strange view of performance design if you think using caches is "hacking something on top" and has to be avoided.

> than just using a daemonized system with actor framework.

This looks like a complete non-sequitur - you could use actor framework and still use all the things described above, and do it in PHP, and thousands of people do exactly that. On not in PHP, if you'd like - this pattern is completely orthogonal to the language used.

Re: Taking PHP Seriously

#44
post #33

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…

> "reasoning about" (boy do I hate that phrase...) A bit tangential, but I find myself disliking it too, for no good reason that I can think of. Perhaps it's something of a crutch in that it's really "I like it more, but 'reason' sounds better" ? Not sure that's quite it, either, as in the above case with a "new everything per request", it's certainly true that it's easier to think about what's happening.

I like the old hacker term for "reasoning about". Grok. It's much easier to grok a program when everything just runs from top to bottom and doesn't jump to a different third party library every 3 lines or have 15 layers of indirection and frameworks.

Re: Taking PHP Seriously

#45
Love the memes:

"PHP is garbage language!", "PHP is a shitty language!"

That is the antiquated view of course. The old days.

Now with Laravel and PHP7 it is a pleasure to use.

I'd go further.

Working in Laravel is BETTER than ROR IMHO.

Re: Taking PHP Seriously

#46

Hack is awesome, but we decided to go with PHP 7 and this choice was primarily made because of lack of tooling on the Hack side. Things like New Relic are not available and these type of things do matter a lot when it comes down to choosing the programming language. I must say that PHP 7 is a great language nowadays. Most of the modern concepts are baked into a language or are about to be developed. At some point, I…

With the changes in PHP 7.0/7.1 & the powerful frameworks (Laravel & Symfony), PHP has made a dramatic turn for the better in the past ~3 years. I work with Laravel daily and it is actually an enjoyable experience using PHP.

Most of the hate for PHP comes from the PHP 4 days, but we are well past that and charging ahead with featureful yearly releases.

Re: Taking PHP Seriously

#47
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).

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.

Y but it's so slow to evolve it's just sad. We've being using hacked on "traits solution" since 2006 (via build script) and PHP only got traits in 2012 and on and on. A lot of things that could make it more modern get shutdown.

Re: Taking PHP Seriously

#48
>I claim that PHP’s simpler “think; edit; reload the page” cycle makes developers more productive. Over the course of a long and complex software project’s life cycle, these productivity gains compound

this is certainly what got me started with PHP and what makes its so easy for beginners

Re: Taking PHP Seriously

#49
> Almost all languages these days let programmers compare, e.g., integers and floats with the >= operator; heck, even C allows this.

The implication that C is an especially strict language for type conversions is strange. C is actually one of the loosest languages for type conversions. It's even legal to do things like compare pointers to integers (though most compilers warn you)!

Re: Taking PHP Seriously

#50

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.

Yup, and it's pretty much a drop in upgrade from 5.6. I have seen/heard of many companies reducing their cpu load by ~40% just by switching to 7.
Post reply on HN