Live data from Hacker News

Taking PHP Seriously

slack.engineering

111–120 of 673 posts

Re: Taking PHP Seriously

#111
post #43
post #19

Earlier quoted context omitted.

> 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 v…

I think his main issue is that the cache has to operate outside of the application process, adding overhead. Languages with shared state can have much simpler and more efficient caching, no io, no de/serialisation.

Re: Taking PHP Seriously

#112
post #33

Earlier quoted context omitted.

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

"Grok" is good. Perhaps it's that it sounds less pretentious, somehow?

Re: Taking PHP Seriously

#113

> Virtues of PHP > First, state. Every web request starts from a completely blank slate. > Second, concurrency. An individual web request runs in a single PHP thread. > Finally, the fact that PHP programs operate at a request level Isn't this just "virtues of Apache modules"? There's mod_python, mod_perl, and mod_ruby. Are state, concurrency, and global requests virtues of these languages too? --- Even if you do some…

> The real programmers will say "Yeah it works but you're leaking memory everywhere. Perhaps we should fix that." I’ll just restart Apache every 10 requests.

They're cattle not pets. (/semi-sarcastic)

Re: Taking PHP Seriously

#114

Earlier quoted context omitted.

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.

Sure. But that doesn't really address the problem, just makes it smaller. You still need to reinstantiate a lot of runtime state.

Re: Taking PHP Seriously

#115
post #36
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.

[deleted]

Re: Taking PHP Seriously

#116
I think there is a needless air of elitism especially here that can only come when people take themselves too seriously, seek validation for their choices, and are always on 'display'. This is also now fuelling a full scale culture of complexity as nobody wants to do things simply lest they be judged as 'unsophisticated' and lose career and other opportunities.

This cannot lead to real conversations or good software. There are far too many naysayers always eager to jump in with their 2 bits of negativity with the same cliched talk points and links most of whom I am sure would never be seen near php and may not even have used it.

The criticism goes silent when HN favourites like Slack show up on discussion. Ignoring the sheer number of high traffic websites and successful startups using PHP is just another way to deny it its due.

Most PHP apps are a breeze to install and use compared to just about any Ruby or Node app. Try installing Discourse to understand just how user hostile it has become. The respect for users and simplicity comes through in PHP. NPM and Ruby with their dependency hell expect a full dev environment even on user machines and nobody thinks this is ridiculous. There is no denying PHP warts but Node, Ruby and Python I think have their fair share of issues.

I really do like Python but for a web project that needs to scale and not get mired in other issues I would choose PHP every single time. For a library or SAAS app maybe, but for an installable app I would never expose users to the Ruby or Node ecosystem.

Re: Taking PHP Seriously

#117
post #71

Does anyone know how the types in PHP7 compare to what's offered by Hack? It looks like generics aren't yet in the core language ( https://wiki.php.net/rfc/generics ), but I believe return type hints work. I think we're also still missing property/field type hints ( https://wiki.php.net/rfc/property_type_hints ).

FWIW PhpStorm handles property type hints via docblock annotations and it works quite well, I've found myself not truly caring if the language enforces it as long as my IDE does.

Re: Taking PHP Seriously

#118

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…

Starting new, regardless of caching data/bytecode, still means you have to spend time bootstrapping the application.

Other languages, whether directly or indirectly manage cleanup via GC or recycle processes, like UWSGI for Python.

I also don't find any particular benefits over other languages with "reasoning about". As a PHP application grows and a team restructures it into something more mature it ends up looking the same minus the event loop (which just lives somewhere else).

Re: Taking PHP Seriously

#119

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…

We decided to go with PHP7 too instead of Hack. This is a blog post that explain our migration : http://engineering.dailymotion.com/php-7-deployment-at-daily...

Re: Taking PHP Seriously

#120
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…

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

This is exactly right. The right philosophy for PHP is to embrace the garbage. When you're done with a request, and have spit out all the HTML to the client, the server is going to throw everything away. So don't build a beautiful object tree to describe everything, just do the minimum amount of work to take the garbage input and generate the garbage output, and be done. Don't worry too much about your code being beautiful, because it lives in a dump.

This may sound negative, but working in a dump means you don't have to worry about appearances while you do what you came to do. You can always take a shower on the way out :)

Post reply on HN