Hacker News Reader

Comment by jrockway | Hacker News Reader

If you want fast, why would you use PHP and then write a new VM, when you could just use Java or Common Lisp or Haskell or C? Those already exist and are already damn fast.

View on HN

You could also write your software in assembly and it'll be faster than all of those you mentioned. The point is to select a language that is feasible for a business. Facebook is not an academic exercise. PHP has a lower barrier to entry, which in practical terms reduces the wages that need to be paid. You then get a few guys who are great at C (PHP is written in C) and fix whatever parts are getting in the way of great performance. Which is exactly what Facebook is doing. Remember, Facebook is a business.

You're getting downvoted by people who disagree with you, not because you aren't contributing to the discussion. I just wanted to make it clear that they are wrong for doing that, and that your comment, whether I agree or not, is appreciated.

Fully agree, given the code base that exists the best ROI likely comes from improving execution speed of PHP rather than rewriting the codebase.

Maybe if it's a video decoder that uses special video decoding instructions. For real world code, though, a good JIT is going to make most code very fast, and you will actually be able to maintain it. I don't think Java is any harder to maintain than PHP, but it runs much faster. (I think Perl and Python are much easier to maintain, however, so if that was what we were arguing about, then it would make sense. PHP is objectively the worst "P" language.)

You're missing my point so completely that it becomes a fine example of why engineers make poor businessmen.

The best business solution is the one that accomplishes the task at hand with the least resources. By that metric, PHP is far superior to Java, regardless of the technical merits at hand.

It costs less to hire an army of PHP devs and a small team to optimize PHP, than it does to hire an army of Java developers.

http://www.payscale.com/research/US/Job=PHP_Developer/Salary

and

http://www.payscale.com/research/US/Job=Java_Developer/Salar...

The difference in pay is around $20K. If you have 500 developers, that's a difference of $10 mil per year. Over the span of a decade, you're talking about over $100 million in savings.

As I said, Facebook is a business, not a pet project or an academic exercise. Decisions on which platform to use and keep are made based on dollars and cents ... not on which is more elegant or technically superior.

> It costs less to hire an army of PHP devs and a small team to optimize PHP, than it does to hire an army of Java developers.

Is that what Facebook is doing? Everything I've read about interviewing and getting hired at Facebook leads me to believe that they are not hiring an army of cheap PHP developers.

Edit: to avoid a totally uninformative comment, as I see no links to previous discussions, this one: http://news.ycombinator.com/item?id=3335217

The 2 URLs in the parent show the limit at which adding ellipsis sometimes make the inner text of links longer instead of shorter.

My impression is that Facebook has plenty of people who would not find learning Haskell, OCaml or Lisp particularly difficult, and would thereafter be more productive than in PHP. In fact, I know for a fact that some of their internal tools are written in Haskell and some variant of ML.

If there is any company that should not be worried about a language's barrier to entry or trying to get cheap programmers, it's Facebook--my impression is that they have an engineering team more like Google than your favorite nameless corporation.

I think what Facebook is doing is working with a ton of legacy PHP code. In fact, from what I've heard, they're definitely open to using other languages in new projects; it's just that rewriting all the PHP code they already have would be horribly wasteful.

Facebook does use Java (entire Hadoop infrastructure, HBase deployments, likely more), Haskell (AST manipulation, afaik), OCaml (with a fairly interesting library for static analysis: https://github.com/facebook/pfff ), C++, and C (fairly self explanatory).

The explanation they seem to give is there are a lot of people who can write PHP, and can write PHP code very fast. So because PHP allows their engineers to iterate and prototype new features very quickly, any attempt to convert to a new language is thwarted when those writing in PHP are outproducing the conversion process that it'll never catch up.

I'm not saying it's a great explanation, but it is what it is.

If the people you find to write code aren't capable of learning something other than PHP, you should find new people. People who write code for Facebook should be good at programming, not just "good" at PHP.

But the language itself is conducive to writing a lot of code rather quickly. There is no memory management to worry about, there isn't a bunch of verbose boiler plate like in Java. You just write code and even if it's not perfect, you can iterate on it quickly.

That's not to say that's how I'd run Facebook given the opportunity, but from talking with people who have presented HipHop here, these are the reasons they give.

My understanding is that Facebook rarely hires PHP developers, it hires other developers and teaches them PHP.

This bases on a conversation from 2009 when they had just 200 programmers, so this is likely to no longer be true. However, I think it's highly likely that Facebook developers know a lot more than PHP.

Because you can get a web application up and running quickly in PHP, then tune it later if and when your application needs to scale to 500 million users (which it probably won't, because only a handful of sites reach that size).

There's also a far bigger pool of talent to draw from if you want developers. I don't think there are many people who know how to write web applications in Common Lisp or Haskell.

I believe this is a fallacious argument; performance inefficient introduces significant costs at lower scales, too.

>Because you can get a web application up and running quickly in PHP

You can get a web app up and running quickly in good languages too, and then you also don't have ongoing maintenance nightmares and the massively increased hardware and hosting costs that come with PHP.

I don't know where you're getting this "massively increased hardware and hosting costs" from - we run our trading platform on bog standard x86_64 hardware, as has every other PHP site I've worked on (some even run in VMs with 500MB of memory).

Because you are buying 10 times as many servers, and paying for power for 10 times as many servers. Where on earth did this "bog standard x86_64 hardware" business come from?

Facebook really doesn't care what languages new hires know. Only a small number of people I started with had any experience with PHP. Anyone who works here is capable of becoming proficient in the language during bootcamp (http://www.quora.com/How-does-Facebook-Engineerings-Bootcamp...).

Facebook already got started.

Let's be honest. 99% of the people that start a PHP project have it fail before it ever needs to scale. The people that do need to scale, though, are up a creek, because if you started your project with PHP, you probably don't know how to write a better VM for it. Consider, as proof, the fact that there is no better VM for PHP.

Yes, there is no gigantic pool of experienced Haskell or Common Lisp developers.

However, I suspect Facebook has a disproportionate amount of them. Additionally, anybody working at Facebook is very likely able to pick up Lisp or Haskell relatively easily even if they do not know it already.

Facebook is exactly the sort of company that does not look for developers of a particular language. I know a bunch of people who have interned there and several (ones a year or two ahead of me) who are going to work there full time. None of them had any PHP experience. Some of them still don't (the one I know best used C++ there, if I remember correctly).

I think the PHP at Facebook is nothing more than a legacy of how it started.

It's not like those requirements arose all at once; at first they wanted to get stuff done using tools they already knew. Then, somewhere north of a million LoC they were like "oh right, speed". At that point, it's no surprise that building a VM was cheaper than a full port.

Reply on news.ycombinator.com