Прямо сейчас, на Reddit:
http://www.reddit.com/r/IAmA/comments/1nl9at/i_am_a_member_of_facebooks_hhvm_team_a_c_and_d/

Кидайте ему свои вопросы!

Что уже есть интересного:

The simple story behind that is that Walter Bright and I were looking at a simple means to constrain instantiation of templates. We had static if, we had compile-time function evaluation, so template constraints were a wonderfully simple and integrated solution within that context — a great "aha!" moment. People love it.

Q: Are there plans to use D in Facebook?
A: Not for the time being.

I think Scala and C# are two fine languages. Haskell is a factory of good programming languages research. I've seen a talk on F# and it's been quite impressive — it's amazing what can be done with them reified types.

Q: How much of FB's code is still plain PHP? How much is C++?
A: We're roughly in the 70/30 area for PHP/C++. Both codebases have grown a lot in absolute numbers since I joined, and most interestingly the ratio was somewhere like 90/10 four years ago.

Of the usual suspects present in FP languages, D notably misses pattern matching. It is in tension with OOP-style (first match vs. best match), and I'm not sure whether or not it's a fundamental feature of functional style. There are no plans to add such at this time.

I am glad that C++14 has increased the power of constexpr significantly. We have had an incredible time with compile-time evaluation in D for years, and I'm glad C++ "stole" that idea. I predict that constexpr-based programming will become a major idiom in C++14.

The scope statement. It's rare that I enjoy bragging about something, but I do like to brag that I invented a new control flow statement (which is awesome because they're so few!).
I think many languages implement some form of deferred execution, but most miss the point — Lisp's with-open-file, Java's try/finally, Go's defer, C#'s using are all sorely wanting.

Facebook famously does not have a QA department. Engineers are responsible for testing their own code. The way that works is holistic, which checks and balances at each major bottleneck: (a) a sophisticated lint — all code must past linting; (b) then there's unittesting — all code must pass existing unittests; (c) code review — not one line of code makes it into our code repos without having been reviewed by at least one other engineer, who in particular looks for unittests added for new code; (d) various sandbox and production testing means.

You will always get what you always got
  If you always do  what you always did