4 ms·

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 a

by kmavm 15y ago

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

mrich 15y ago
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?
cookiecaper 15y ago
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.
- TeeWEE 15y ago
  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.
- nbm 15y ago
  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.
- ericd 15y ago
  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.
  - sciurus 15y ago
    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-infrastructure-expenditures-a-quick-analysis.htm http://www.colocationamerica.com/blog/facebook-data-center-i...
    - evgen 15y ago
      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.
davidw 15y ago
> 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.

by kmavm 15y ago

mrich 15y ago

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?

cookiecaper 15y ago

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.

TeeWEE 15y ago
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.
nbm 15y ago
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.
ericd 15y ago
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.
- sciurus 15y ago
  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-infrastructure-expenditures-a-quick-analysis.htm http://www.colocationamerica.com/blog/facebook-data-center-i...
  - evgen 15y ago
    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.

davidw 15y ago

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