Comment by kmavm | Hacker News Reader

Comment by kmavm | Hacker News Reader

Parent Full thread

This is a long and deep subject.

I wouldn't say that we've "continued on the PHP path." I'd say that we've refused to throw out the precious PHP parts of our application, while not being afraid to use more appropriate languages across Thrift boundaries when needed. Our search engine, newsfeed, and ad serving infrastructure, for instance, are in C++.

A drop-everything-and-rewrite of the PHP code is entirely out of the question, for all the reasons covered in Spolsky's 12-year-old classic on the subject: http://www.joelonsoftware.com/articles/fog0000000069.html. Those of us working on making PHP perform better are a tiny fraction of Facebook engineering as a whole; this small overhead cost is nothing compared to the risks inherent in a ground-up rewrite.

Most of PHP's language-level faults can be engineered around. For instance, we have a code-review-time script that parses (really parses) the code to warn engineers (and reviewers) about dangerous or deprecated idioms.

PHP also has some affirmative virtues. The programming model is more productive than that of compiled languages, and even many interpreted languages; save/reload the web page is just a better, tighter loop to get work done in than save/compile/restart my server/reload the web page. I'm actually a fan of PHP's concurrency model, which naifs often mistake as "no concurrency allowed"; PHP's concurrency primitive is curl[1], and if you wrap a tiny bit of library around it, you can make it behave like actors.

[1] Seriously. curl provides a shared-nothing way to asynchronously run code, and has the virtue of not caring what language the other side is written in to boot.

Right, I'm familiar with Spolsky's piece, but I think there are times when a rewrite is legitimate. I think that a situation where you must roll a completely custom in-house compiler that generates binaries which exceed 1 GB in size in order to get adequate performance of your app is a good candidate for a new architecture, despite Spolsky's claims. Spolsky's article discusses throwing out pages of code because the programmers "don't know what half of these API calls are for" and "[wanting] to build something grand" -- these are quite different impulses than the real-world problems staring Facebook in the face by its continued usage of PHP.

I think also that there is a difference between writing a new backend for something that is solid and in place and just throwing the whole product out the window and re-imagining it from the ground up, and I think the latter is the kind of rewrite that should be avoided and considered dangerous. When you could throw 4-5 guys on a real C# or C++ rewrite and tell them the final product has to behave identically to the PHP version, you have a much less volatile situation.

As for the PHP workflow, I agree it's nice not to have an intermediate step, but that intermediate step can usually be circumvented pretty rapidly by throwing a script or two (or just flipping a config option) into your development environment.

PHP is not such a bad language. Of course it has its quirks. However bad code is written by a bad developer, not by a bad language. You can write beautiful code in PHP too.

And the huge code base from Facebook is impossible to rewrite it in even a few years. Throwing away knowledge, tools, and tested code.

There is pretty much no way 4 to 5 guys could rewrite "www" in another language in parallel to continuing development from a hundred developers, no matter how long they had. However, 4 to 5 guys could write HipHop.

What real-world problems do you see staring Facebook in the face in its continued usage of PHP? I'm no PHP fan, but many of the common PHP problems are avoided or mitigated in the code base.

I think developing in PHP and compiling to C++/binary probably results in much higher developer productivity than developing in C++/C# directly. Developer salaries are undoubtedly their largest expense, by far, dwarfing those salaries of the people who make PHP performant and 1.5 gig binary updates sane.

I expect that running their datacenters is a larger expense than developer salaries.

"In 2011, $606 million was allocated towards total capital investment in data center infrastructure by Facebook, which includes the cost of servers, networking equipment, construction, and storage." - http://www.colocationamerica.com/blog/facebook-data-center-i...

The assumption that migrating the entire www stack to something like C++ would help with the datacenter costs is not supported by reality. Please remember that the bits that are in PHP are mostly front-end code. This handles the presentation of the data, but the actual heavy-lifting and data manipulation is done by the back-end infrastructure which is mostly C/C++ with some Java thrown in for the hadoop bits.

I would disagree here - every percent CPU saved for the same workload is a 1% reduction in the number of machines needed. The number of web machines is sufficiently large that savings of even 1% are praiseworthy. Quite a bit of effort is expended to keep this going down and to the right (at least some of the time).

Ah, good point, my estimate of their hardware spending wasn't that high. With 3000+ employees, depending on average total compensation, it might be close. That said, I would still guess that they'd choose greater developer productivity and agility over savings on server costs.

I wonder if there are any public benchmarks of compiled Hiphop vs. C++

Thanks for your insights, but this makes me wonder: how much PHP code is there to make a rewrite unfeasible? At least the public part shouldn't be so big, are there huge administrative interfaces that somehow can't be separated?

> Our search engine, newsfeed, and ad serving infrastructure, for instance, are in C++.

At one time the chat thing was supposedly done with Erlang - is that still true? Probably ejabberd hacked up, or something like that.

Reply on news.ycombinator.com