Live data from Hacker News

Taking PHP Seriously

slack.engineering

381–390 of 673 posts

Re: Taking PHP Seriously

#381
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 have very hard time believing it.

Yes, they do. Phoenix/Elixir is a nice way to get below the millisecond, and even with Java you can for most requests go below a few milliseconds.

And you can obviously handle far more requests at once, as you have all the code already loaded in RAM, and just need to jump into it, instead of reparsing it, or copying it back from a cache.

Re: Taking PHP Seriously

#382
post #346
post #301

Earlier quoted context omitted.

Refactoring without a proper tool is like shooting at your own feet.

Indeed, which is why it's nice to have a compiler catching things that you would have to write tests to catch in PHP.

PHPStorm, highly recommended.

Re: Taking PHP Seriously

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

The problem with your argument is that most php sites fail when I/We use them(throwing exceptions on the site - really?!), they've the worst security on average and php is also a slow and hardly maintainable development platform. Yeah, you can create crap fast but that's all. With this "fast iteration" bs you'll live in an illusion that you make money for the company but actually it's the opposite and you're contributing to the deterioration of IT - if there would be only php, the internet would be far worse and we'd have the same technology level as in the 90s.

Edit: guess why everyone will need to rewrite their stack in another language when they've bigger traffic on a php platform

Re: Taking PHP Seriously

#384

Earlier quoted context omitted.

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.

>PHP isn't quick. As of PHP7... it actually is quicker than other languages in it's domain.

Evidence? I'm pretty sure it's far slower then the average jvm app. It also doesn't have parallelism...

Re: Taking PHP Seriously

#385

There have been huge improvements made with PHP over the past few years. PHP 7 is great and I would choose it over Hack. Modern PHP using autoloading (Packagist & Composer) and an MVC structure allows for rapid development. With frameworks such as Laravel, you can get something up quickly or just pull in Packagist libraries you need if you don't want the bloat of a framework. I recently finished up a fairly complex w…

It's hard to believe that a REAL "fairly complex web app" can be finished in two weeks. What kinds of libraries do you use?

Re: Taking PHP Seriously

#386

Write an API for my client app which returns user's data as JSON (or render HTML page for profile); You: { mysql_connect("host", "pass"); mysql_select_db("users"); $uid = $_GET[ "uid" ]; $res = mysql_query( "select * from users where uid = $uid" ); $ar = mysql_fetch_assoc( $res ); echo "name: " . $ar["name"] . ","; echo "location: " . $ar["location"]; ?> } Just call it http://domain.com/api.php?uid=USER_ID ( Yeah I k…

Maybe we are from different universe. Nowadays it's fairly common to use ORM in PHP.

Re: Taking PHP Seriously

#387
post #74

I find the virtues quite uncompelling, take for example >First, state. Every web request starts from a completely blank slate. Except for, you know, when you don't want to reinitialize everything everytime someone makes a new request. There are tons of things that you only need to run once. >I claim that PHP’s simpler “think; edit; reload the page” cycle makes developers more productive. Over the course of a long and…

More importantly, said virtues don't have anything to do with PHP as a language, and everything with request handling in the server and the framework. Yes, in case of PHP, the latter is basically built-in, but you can (and we do) have equivalent functionality with all other languages out there. So if these are virtues, they also apply to Python, Ruby etc. And then - again - why PHP?

Re: Taking PHP Seriously

#388
post #361

Earlier quoted context omitted.

Yeah, but you also have to fork a whole process per request to do it. Process fork, CoW overhead every time you mutate a page, and a full OS thread per request. Oh, and let's not forget negotiating a new database connection per request. I think by the time you've added up all those overheads, you're not off to a scalable start. It's possible to work around the limitations, but it's not easy.

It is easy if you are just willing to spend more money on servers. Often it's worth it.

Its also a problem that has been solved a long time ago and is well understood. Unlike trendy microservice architectures....

Re: Taking PHP Seriously

#389
post #334
post #314

Earlier quoted context omitted.

Traction and Team. Luck is not a factor.

why is luck not a factor? I'd imagine it's the biggest factor that you can't control!

I completely agree with this. There were a host of similar services when Facebook appeared in my radar, I was signed up to a couple of them. Its only because more friends signed up for facebook that it seemed to have a snowballing effect. It didn't seem in any way superior (well except compared to myspace).

Re: Taking PHP Seriously

#390

Earlier quoted context omitted.

An easier way to avoid those warts would be to pick a different language

PHP devs aren't expensive. Even good ones. It's easier to reroll in another language and retrain or recruit? No. So you probably mean for a new project. So now you've more maintenance and learning curve unless you just happen to have enough skilled in $NEWTHING. Not really easier. PHP is an inconsistent mess, everyone knows that, but it's cheap, widely understood, and it's perfectly possible to write decent maintaina…

True, I have seen one startup fail early because he couldn't find any (cheap) Django devs. He might have stayed around another year with the funding he had if he had gone PHP.
Post reply on HN