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.

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

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.

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.

Interesting. What were they using, C++? I've heard about D...

The particular people I talked to were using C++. But I think there is even a team using Haskell for some internal tools :).

MRI Ruby is actually significantly faster than CPython these days.

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

I suspect that parent was referring to the python 2.x branch, which has been catching up with ruby 1.9, but on most benchmarks started at ~ 3x slower and are now ~ 2x slower.

Since benchmarks are completely worthless, let's just stop this pissing match right now.

> I suspect that parent was referring to the python 2.x branch, which has been catching up with ruby 1.9, but on most benchmarks started at ~ 3x slower and are now ~ 2x slower.

Citation needed again. Ruby 1.9 is slower than Python 3, and Python 3 is slower or as fast as Python 2 on Python official benchmarks.

http://docs.python.org/release/3.0.1/whatsnew/3.0.html#perfo...

> Since benchmarks are completely worthless, let's just stop this pissing match right now.

Benchmarks are far from worthless. And pissing match? Asking for citations amounts to pissing match? The parent claimed something that isn't true(ruby 1.9 significantly faster than CPython - that has never been the case). And you are adding python 2.x was slower than 1.9, when 2.x is generally faster than 3.

I love ruby as much as the next guy. But when it comes to execution speed, ruby has always been the slowest among ruby, python, and perl.

Fib(36)

Python 2.7.2

    def fib(n):
        if n == 0 or n == 1:
           return n
        else:
           return fib(n-1) + fib(n-2)
     
     for i in range(36):
         print "n=%d => %d" % (i, fib(i))'

python -c 20.69s user 0.06s system 99% cpu 20.807 total

Ruby 1.9.3 def fib(n) if n == 0 || n == 1 n else fib(n-1) + fib(n-2) end end

    36.times do |i|
      puts "n=#{i} => #{fib(i)}"
    end

ruby 11.44s user 0.03s system 99% cpu 11.507 total

I guess since benchmarks are not completely worthless, we should conclude that ubuntu doesn't keep up on ruby and uses 2-3 year old versions.

I wasn't accusing you of starting the pissing match.

> I guess since benchmarks are not completely worthless,

The original keeps getting re-iterated: http://programmingzen.com/2007/11/28/holy-shmoly-ruby-19-smo...

The original author, on a basis of a fib benchmark, concludes ruby 1.9 is faster - that is as flawed as it gets.

Did you try running with Python 3? You will get around the same time as you get with Python 2.7. Pick anything from here http://shootout.alioth.debian.org/u64q/benchmark.php?test=al... and run it with Python 2.7 and ruby 1.9. The programs which are faster with Python 3 will be mostly faster with Python 2.7. 2.7 isn't slower than ruby 1.9; it is faster in most of the cases.

Regarding the fib example, when the original was doing the rounds, I didn't find any explanations from python or ruby implementors. I can't say why, but most likely python has a higher overhead with growing call stacks, and ruby does some optimizations.

Data is not dishonest and benchmarks are not dishonest. What is dishonest is this tendency to cherry-pick only the case which is convenient to you, as you have done here. If you want to talk about Ruby performance vs. Python then you will have to dig into something like the site linked previously, which has many different benchmarks run on a uniform testbed rather than a single cherry-picked case run in whatever way you felt like.

>>ubuntu doesn't keep up on ruby and uses 2-3 year old versions<<

Huh? Since 21 Apr 2012, the benchmarks game has shown - ruby 1.9.3p194 (2012-04-20 revision 35410).

If you're looking at measurements made on the quad core machine, then remember to check the "≈ CPU Load" column to see whether some programs are using multiple cores and some programs are only using one core.

When the comparison would be better without that complication, look at single core measurements -- http://shootout.alioth.debian.org/u64/benchmark.php?test=all...

>>Since most benchmarks are unscientific, this one is as good as any.<<

1) You seem to be using "unscientific" as a nothing more than an insult.

2) Your conclusion "this one is as good as any" doesn't follow from your premise that "most benchmarks are unscientific" -- "this one" might well be different from "most benchmarks".

3) If your conclusion was correct then that wouldn't mean that the benchmark was good, just that it was also bad.

>>Since most benchmarks are unscientific, this one is as good as any.<<

>1) You seem to be using "unscientific" as a nothing more than an insult.

More like preemptively declaring I don't want to deal with HN crowd replying with "but benchmarks are worthless".

> 2) Your conclusion "this one is as good as any" doesn't follow from your premise that "most benchmarks are unscientific" -- "this one" might well be different from "most benchmarks".

IMO shootout benchmarks are better than random benchmarks on the web as they detail the testing environment, provide the source code and can be re-created

>>More like preemptively declaring I don't want to deal with HN crowd replying with "but benchmarks are worthless"<<

It's a dirty job but it still has to be done ;-)

Let them reply and then answer them.

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.

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

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

The Face Book.