C++ at Facebook

Andrei Alexandrescu said in a panel discussion last week that when he joined Facebook two years ago, maybe 90% of the programmers wrote PHP and 10% C++. Now there are roughly as many C++ programmers as PHP programmers.

One reason Facebook is shifting more work to C++ is to reduce operating costs such as power consumption per user.

Andrei’s remarks are about 24 minutes into this video. (link died)

12 thoughts on “C++ at Facebook

  1. Chris, I don’t think that’s the case, since Haskell means a more complex runtime, and the garbage collection isn’t cheap either. :) In C++ what you lose from massive builds you gain from the really powerful templating features that can lead to really good static optimization, ergo you get a more performance/power saving-aware runtime component.

    Plus I guess C++ is pretty much the reason why Andrei Alexandrescu is there. :)

  2. I’d wonder if they’d even consider moving off of C++ to Haskell or another language if that would offer reduced power consumption. Doing all those massive C++ builds can’t be cheap.

  3. Christopher Smith

    +1 what Johnathan said. In today’s world, compilers are a way to shift as much computation as possible from the runtime to the build time, and there are *very* few company’s where that trade-off ends up being a net loss. Even if you have a ton of developers and a massive code base, you likely have an even larger end customer base/use.

  4. For their sake, I hope they are not letting Andrei run wild with template metaprogramming. Otherwise they will be in a far worse hell than PHP.

  5. Corwin: Running wild with templates is definitely an anti-pattern. As someone told me of some highly templated code “You can’t just read it. You have to step through it with a debugger.”

  6. This is just as crazy as it is AWESOME! Way to go!

    Now, it is just a matter of days before a bunch of self proclaimed experts start explaining in boring, detailed long blogs why PHP sucks, why C++ should not be used, why Phyton, Cucumbers o Carrots should’ve been chosen. Yet, nothing else than the blog to support their views.

  7. Christopher Smith

    +John that at least two different problems. Generally, the kind code Andrei is famous for is declarative and policy based libraries, which tend to make application code very easy to read. Generally those who find it hard to read such application code haven’t learned what amounts to a new language, so it is understandably hard. Reading library code can be challenging, as *writing* such libraries well is quite daunting, and deficiencies manifest most painfully as unclear code. That is much bigger than templates or C++ though. There is some kind of conservation of developer productivity rule such that as code gets more generic thereby being useful to a broader set of developers, the narrower the set of developers who can write it well.

    Debugging can be a different matter though. Even compiler errors on templates are often difficult to decipher, though Andrei and others have found a few tricks that help and are advocating changes that would help a lot. Deciphering runtime errors that occur when you’ve got what amounts to emergent behaviour from mashing up a bunch of mixins can be daunting. I sometimes feel like we need a modern Cfront style compiler that shows you what the combined code looks like. ;-)

  8. Christopher Smith

    +John that at least two different problems. Generally, the kind code Andrei is famous for is declarative and policy based libraries, which tend to make application code very easy to read. Generally those who find it hard to read such application code haven’t learned what amounts to a new language, so it is understandably hard. Reading library code can be challenging, as *writing* such libraries well is quite daunting, and deficiencies manifest most painfully as unclear code (I suspect this is the “running wild” to which you refer). That is much bigger than templates or C++ though. There is some kind of conservation of developer productivity rule such that as code gets more generic thereby being useful to a broader set of developers, the narrower the set of developers who can write it well.

    Debugging can be a different matter though. Even compiler errors on templates are often difficult to decipher, though Andrei and others have found a few tricks that help and are advocating changes that would help a lot. Deciphering runtime errors that occur when you’ve got what amounts to emergent behaviour from mashing up a bunch of mixins can be daunting. I sometimes feel like we need a modern Cfront style compiler that shows you what the combined code looks like. ;-)

Comments are closed.