5 ms·

Yes. And now Facebook is spending a ton of resource and man-hours programming around this. They had to write their own compiler! Also, I think they are trying

by tikhonj 14y ago

Yes. And now Facebook is spending a ton of resource and man-hours programming around this. They had to write their own compiler! Also, I think they are trying to move away from PHP as quickly as possible without rewriting the entire site. The new projects and tools are not in PHP; moreover, I think most of the new people they hire never have to use PHP at all. Finally, just because they managed to use PHP to run a bit site does not mean it is the best web language, or even a good web language. It just means it's adequate.

illumen 14y ago
The Face Book.
InclinedPlane 14y ago
You get the same issues almost no matter what you write a website in, whether it's PHP, C#, Rails, or node.js. When you get to the level of scale that Facebook is at you are in a realm that conventional web application tooling and frameworks don't cover. If anything the "best" and most trusted platform for what facebook is doing today would be java. Does that mean java is the "best" web platform? Not in the least. The central fallacy here is imagining that one size could or should fit all, whether it's php or rails or anything.
rimantas 14y ago
> Yes. And now Facebook is spending a ton of resource and > man-hours programming around this. They had to write > their own compiler! Is there a project of Facebook scale which does not have "their own" at the very core, no matter initial choice of technology? My understanding is that by solving problems no one had to solve before you are bound to create "your own" stuff. Even for desktop — didn't Excel have it's own compiler?
Kudos 14y ago
The same argument could be made of Ruby on Rails, just look at Twitter moving core infrastructure to the JVM.
- tikhonj 14y ago
  It could, and I think it should. I am no fan of Rails. But that is a different story for a different time.
notinfinland 14y ago
Do you have inside info on this? I've seen several people from Facebook comment that they are in fact using PHP. The fact that they're compiling to C++ is a consequence of the slowness of the programming language implementations of those languages that are used traditionally for web development. AFAIK Ruby was and still is the slowest of the bunch.
- tikhonj 14y ago
  A couple people I know well spent the summer there (I actually visited one at the old headquarters; it was pretty cool). One now works there full time (the other hasn't graduated yet). I also talked to some fulltime engineers who were not using PHP. Now, it's reasonable that I did not get the full picture, but the people I did talk did not use PHP themselves and claimed that new projects didn't either. Perhaps this varies per team. My impression was that existing code bases using PHP were still under active development (that is, getting new features) but new projects and new developers did not use PHP.
  - notinfinland 14y ago
    Interesting. What were they using, C++? I've heard about D...
    - tikhonj 14y ago
      The particular people I talked to were using C++. But I think there is even a team using Haskell for some internal tools :).
- charliesome 14y ago
  MRI Ruby is actually significantly faster than CPython these days.
  - irahul 14y ago
    Citation needed. Both CPython and MRI are slow - if you need computational speed, use something else. But when your are comparing them to each other, CPython is faster. I don't know where you are getting that significantly faster bit from. Since most benchmarks are unscientific, this one is as good as any. So here goes: http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=python3&lang2=yarv http://shootout.alioth.debian.org/u64q/benchmark.php?test=al...
nbm 14y ago
I have only a year and a bit of context since starting at Facebook, but here's my viewpoint. Facebook isn't trying to move away from PHP as quickly as possible. For years, there have been PHP components (primarily web front-end rendering, aggregation/ranking of data from various sources) and C++ components (primarily high-performance back-end services) and other languages like Python (primarily non-production-path/operations back-end services) and Java (primarily Hadoop-related technologies like Hive and HBase, and services that are heavy users of such), and nothing groundbreaking has changed in this. New hires use PHP or C++ or whatever language (and often multiple languages) necessary to work on the team and projects they choose to work on. New projects use the languages that make the most sense. Almost all web front-end work involves PHP - the frameworks and libraries and runtime environment are well-developed, well-tested, well-documented, and well-known. In terms of HipHop for PHP, the question to ask is: What language could have allowed quick low-barrier-to-entry web-app-centric development in the early days while still delivering the sort of runtime efficiency demanded by the environment? Languages like Python and Ruby may arguably allow the first (but remember we're talking about early 2004 here, so Ruby on Rails was not out, and neither were Django, Flask, and so forth and WSGI had just come out), but would have required a "HipHop for PHP"-style solution as well. Languages like C, C++, and Java may have the runtime efficiency, but it would be a hard argument to say they're as developer-time-efficient as PHP (especially back then). That's a slightly different question to what one should do today if starting a new venture. And _that_ is also a different question to what Facebook should do today - HipHop for PHP exists, and is delivering performance/runtime efficiency that most languages people mention as an alternative do not. And, the PHP frameworks and libraries and runtime environment exist and allow rapid development of production code. It's actually reasonably pleasant to develop for with those in place. The HipHop for PHP team is small, but have huge leverage - this small team of reasonably hardcore low-level C++ programmers are making a whole bunch (hundreds?) of PHP developers way more productive (since they don't have to use a relatively slower-to-develop-in language/runtime like C++), and also makes the cost of operating the site go down by making that code more efficient and reducing the number of servers needed.

by tikhonj 14y ago

illumen 14y ago

The Face Book.

InclinedPlane 14y ago

You get the same issues almost no matter what you write a website in, whether it's PHP, C#, Rails, or node.js. When you get to the level of scale that Facebook is at you are in a realm that conventional web application tooling and frameworks don't cover. If anything the "best" and most trusted platform for what facebook is doing today would be java. Does that mean java is the "best" web platform? Not in the least. The central fallacy here is imagining that one size could or should fit all, whether it's php or rails or anything.

rimantas 14y ago

> Yes. And now Facebook is spending a ton of resource and > man-hours programming around this. They had to write > their own compiler! Is there a project of Facebook scale which does not have "their own" at the very core, no matter initial choice of technology? My understanding is that by solving problems no one had to solve before you are bound to create "your own" stuff. Even for desktop — didn't Excel have it's own compiler?

Kudos 14y ago

The same argument could be made of Ruby on Rails, just look at Twitter moving core infrastructure to the JVM.

tikhonj 14y ago
It could, and I think it should. I am no fan of Rails. But that is a different story for a different time.

notinfinland 14y ago

Do you have inside info on this? I've seen several people from Facebook comment that they are in fact using PHP. The fact that they're compiling to C++ is a consequence of the slowness of the programming language implementations of those languages that are used traditionally for web development. AFAIK Ruby was and still is the slowest of the bunch.

tikhonj 14y ago
A couple people I know well spent the summer there (I actually visited one at the old headquarters; it was pretty cool). One now works there full time (the other hasn't graduated yet). I also talked to some fulltime engineers who were not using PHP. Now, it's reasonable that I did not get the full picture, but the people I did talk did not use PHP themselves and claimed that new projects didn't either. Perhaps this varies per team. My impression was that existing code bases using PHP were still under active development (that is, getting new features) but new projects and new developers did not use PHP.
- notinfinland 14y ago
  Interesting. What were they using, C++? I've heard about D...
  - tikhonj 14y ago
    The particular people I talked to were using C++. But I think there is even a team using Haskell for some internal tools :).
charliesome 14y ago
MRI Ruby is actually significantly faster than CPython these days.
- irahul 14y ago
  Citation needed. Both CPython and MRI are slow - if you need computational speed, use something else. But when your are comparing them to each other, CPython is faster. I don't know where you are getting that significantly faster bit from. Since most benchmarks are unscientific, this one is as good as any. So here goes: http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=python3&lang2=yarv http://shootout.alioth.debian.org/u64q/benchmark.php?test=al...

nbm 14y ago

I have only a year and a bit of context since starting at Facebook, but here's my viewpoint. Facebook isn't trying to move away from PHP as quickly as possible. For years, there have been PHP components (primarily web front-end rendering, aggregation/ranking of data from various sources) and C++ components (primarily high-performance back-end services) and other languages like Python (primarily non-production-path/operations back-end services) and Java (primarily Hadoop-related technologies like Hive and HBase, and services that are heavy users of such), and nothing groundbreaking has changed in this. New hires use PHP or C++ or whatever language (and often multiple languages) necessary to work on the team and projects they choose to work on. New projects use the languages that make the most sense. Almost all web front-end work involves PHP - the frameworks and libraries and runtime environment are well-developed, well-tested, well-documented, and well-known. In terms of HipHop for PHP, the question to ask is: What language could have allowed quick low-barrier-to-entry web-app-centric development in the early days while still delivering the sort of runtime efficiency demanded by the environment? Languages like Python and Ruby may arguably allow the first (but remember we're talking about early 2004 here, so Ruby on Rails was not out, and neither were Django, Flask, and so forth and WSGI had just come out), but would have required a "HipHop for PHP"-style solution as well. Languages like C, C++, and Java may have the runtime efficiency, but it would be a hard argument to say they're as developer-time-efficient as PHP (especially back then). That's a slightly different question to what one should do today if starting a new venture. And _that_ is also a different question to what Facebook should do today - HipHop for PHP exists, and is delivering performance/runtime efficiency that most languages people mention as an alternative do not. And, the PHP frameworks and libraries and runtime environment exist and allow rapid development of production code. It's actually reasonably pleasant to develop for with those in place. The HipHop for PHP team is small, but have huge leverage - this small team of reasonably hardcore low-level C++ programmers are making a whole bunch (hundreds?) of PHP developers way more productive (since they don't have to use a relatively slower-to-develop-in language/runtime like C++), and also makes the cost of operating the site go down by making that code more efficient and reducing the number of servers needed.