Live data from Hacker News

Taking PHP Seriously

slack.engineering

161–170 of 673 posts

Re: Taking PHP Seriously

#161
post #95

Earlier quoted context omitted.

Love this comment. I'm a PHP dev. I do care about my code though. I think you can write niceish code, even with a shitty language.

In your opinion, what does that look like for PHP? Most of the projects I've seen tend to go overboard on the java-like OOP declarations.

Take a look at phabricator's code. Great example of a good, well-designed application built on top of php.

Re: Taking PHP Seriously

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

> So you say your non-PHP requests which would do the same thing would finish in hundreds of microseconds?

I had a side project written in Elixir/Phoenix make it onto the front page of HN and it indeed was the case that the majority of requests were in hundreds of microseconds. The default log messages actually use "µs" which is kind of cute.

I wrote about it here[0] and extracted a random sample of my logs and you'll see that most of them were in the hundreds of microseconds.

[0] http://gabe.durazo.us/tech/ephemeral-p2p-project/

Re: Taking PHP Seriously

#163

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…

I may be waaay off base here, but wouldn't amazon's lambda function architecture sort of mirror the benefits of shared-nothing? It doesn't necessarily work like that under the hood, at least if I remember correctly your lambda function may live on past one request, but you must code as if that were the case

Re: Taking PHP Seriously

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

PHP isn't quick. It isn't faster than other languages. It's just a tool, and if you know how to use it well, it will be faster for you.

If you want fast, build a static site. If you're iterating on your builds and doing something non-trivial, pick your tools carefully but don't be afraid to try new things.

Re: Taking PHP Seriously

#165
post #51

Doesn't Slack use Java for its messaging system? That's not mentioned in the blog why they didn't use PHP for this.

PHP is great for HTTP requests. It's not that good for listening on sockets, running an event loop, etc, which is what you're likely going to do with real time messaging.

This really depends on your definition of "great".

Re: Taking PHP Seriously

#166
post #143

Earlier quoted context omitted.

I've gone one step further and created a template: Some companies are succeeding in spite of [insert language]. There are many, many users of [insert language], and we'd expect that there would be considerable variance, with some users doing awful (no traction, buggy sites, etc) and some hitting home runs (facebook). Because it's such a popular language, it will have users across this entire spectrum. It's easy to ch…

Your template is far less interesting than the original statement. PHP spent a pretty long time as basically the lingua franca outside the enterprise world (and even some places in it), and there are still domains where it holds that title (e.g. WordPress alone outweighs many languages' ecosystems), so the phenomenon the parent was describing applies more to PHP than to some arbitrary language you could insert into t…

I actually agree with the original statement. PHP, for quite a few years now certainly has NOT been the language of choice for most startups, yet we still see the majority of them fail.

"and miss all of the tremendous losers who picked php and got nothing for it"

certainly applies equally across all languages in my opinion.

Re: Taking PHP Seriously

#167
post #28

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.

No program will ever look beautiful in M4 or sed.

Re: Taking PHP Seriously

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

Agreed, barring an outside force, or other members with experience or a strong voice/drive, experience will be what drives most technology decisions, and should.

I'd say the opposite, I can get a node project up and running pretty quick these days... as to peer comments on APIs, I don't think it's hard at all to spin up a react + node api project once you've done it before... and starting with a boilerplate for react+redux and express is very straight forward as well.

Re: Taking PHP Seriously

#169

Earlier quoted context omitted.

I'll offer an alternate hypothesis. Some companies are succeeding in spite of php. There are many, many users of php, and we'd expect that there would be considerable variance, with some users doing awful (no traction, buggy sites, etc) and some hitting home runs (facebook). Because it's such a popular language, it will have users across this entire spectrum. It's easy to cherry-pick the winners and miss all of the t…

I've gone one step further and created a template: Some companies are succeeding in spite of [insert language]. There are many, many users of [insert language], and we'd expect that there would be considerable variance, with some users doing awful (no traction, buggy sites, etc) and some hitting home runs (facebook). Because it's such a popular language, it will have users across this entire spectrum. It's easy to ch…

I know you're making a parody, but I think I agree with your parody.

I mean, essentially all you're saying is "startup success is largely uncorrelated with the programming language used to implement those startups' products". That seems like not at all an unreasonable position.

(It's not, by the way, equivalent to the statement "choice of language doesn't matter".)

Re: Taking PHP Seriously

#170
>Asynchronously curl’ing to localhost (or even another web server) provides a shared-nothing, copy-in/copy-out way of exploiting parallelism

Wait, wait, wait, wait. Is he saying that to do async work he'll send a curl request to somewhere (spawning a thread for that request), not wait on the output and carry on? Last I used curl in php it was a synchronous action. Hell of a threading model there.

Post reply on HN