I am a member of Facebook's HHVM team, a C++ and D pundit, and a Machine Learning guy. Ask me anything!

What do you think about Rust? (In the context of Rust vs D)

Rust has a great approach to safe regions. That's a hard problem, and Rust has had to expend a considerable amount of firepower on it (four kinds of pointers etc).

D does not offer safe regions; I believe the language design precludes that without at least an amount of discipline.

So Rust is better than D at safe regions. However, like in chess, good language design is to not sacrifice the whole for the beauty of the part. I think D is better than Rust at a lot of other things, because it has firepower it can afford to expend at problems that are also hard, and just as important.

What are your thoughts on the constraints vs static if debate on C++? D uses static if, and I remember seeing you championing it as the #1 feature you'd like seen in C++, but Stroustrup describes it as "a total abomination". Do you think that constraints do the job well? Possibly better than static if?

I knew this was gonna come :o). Virtually everyone in the D community has an appreciation for static if - I have yet to find even a naysayer who's mentioning it as an unsavory aspect of the language.

That isn't a proof, but it is evidence. There's also plenty of evidence that C++ is worse off without it by comparison.

Now, the more debatable aspect is the use of Boolean expressions as constraints. 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.

Now, in C++, there's no static if and C++14 is acquiring compile-time evaluation kicking and screaming. Within that language, I can totally understand how the context is less conducive to an appreciation of template constraints the way they're done in D.

The real question is: did you try llvm?

Good one! Yes, I and others are working on having clang compile our codebase.

Are there plans to use D in Facebook?

Not for the time being. However, since recently it's become part of my job description to explore integration of D at Facebook. This is the first time I'm mentioning it publicly. assert(cat !in bag); I have a well-defined plan that is difficult but executable. If things go well, we'll make an announcement in a few months. Otherwise, well, we won't :o).

Other than C++ and D, what other languages are interesting to you in both a professional and personal capacity?

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.

Generally I have a bias in favor of static types.

No love for rust?

Some of that is in the reply to amigaharry's question. Rust and D have close enough charters that I'd be interested in Rust if it was as good as (or better than) D at everything D is good at, plus better that D at things D is not good at. Far as I can tell Rust fails that litmus test. Reasonable people may of course disagree.

Do you plan on writing more C++ books? or did you pretty much give up on the language and your focus is now on D?

I have to admit my relationship with C++ has lost a fair amount of its romance. We know a lot about each other and we roll our eyes when witnessing once again each other's shenanigans.

I'd be hard pressed to write more books on C++. As a general rule the best driving force behind writing a book is "I feel I have something to say, that I believe is interesting and worth sharing." I do feel this in spades about D, but unfortunately not about C++.

I must add one note though. The C++ community has been very gracious and forgiving with my apostasy. I've continued to be bestowed respect from C++ programmers all over, and I am very appreciative and thankful for that.

I read Modern C++ Design a few years ago and really enjoyed it. It's been over a decade since it was published, however. How outdated do you think it is now, especially in light of the changes from C++11?

It has aged surprisingly well, and to a C++11 user some of its implementation arcana are obviously easier to realize. I think if it aimed at describing the same exact designs in C++11, Modern C++ Design could do it in 250 pages instead of 350.

what has been your happiest moment with programming?

OK, I think most people left the stadium but this has been bugging me so I feel compelled to reply.

"Happy" is frequent enough to make "happiest" very difficult. Probably some of the happiest moments have happened when I had just started. Coding is like heroin - we spend most of our time trying to relive that first high.

I remember moments when I'd run a little program again and again with slightly different inputs just to revel in the joy of having done the proper incantations that make the machine do this and that and the other, like a clumsy but loyal genie. I mentioned I wrote this floppy disk formatter - it gave me a lot of joy to be able to tell it the complicated sequence of things I wanted to get done, to see how it ended up carving magnetized trenches into the physical world.

(thinking about this as I'm answering other questions, will edit later)

When will we be able to use D to make shared libraries that can be called from C?

Good news: Martin Nowak, Walter Bright and others have done some wonderful, creative work on that. The next release of D (2.064) will include good support for dynamic and dynamically-loadable libraries from D itself, C, C++, and other languages.

The release is in the planning stages right now, so we're looking no longer than one month from now.

How much of FB's code is still plain PHP? How much is C++? Is HHVM really that much faster than ZEND? What are your other hobbies outside of programming / computers in general?

Keith Adams has been gracious enough to run a "wc -l" on our main codebases just now. Fresh data! 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. We've scaled up a lot since then, hence the increased emphasis on infrastructure.

As a follow up to that: PHP gets a bad rep these days for some poor language design. Is there any regret in using PHP or a desire to switch the code base to another language?

Edit: Thanks for doing the AMA! I enjoy watching your presentations.

"Regret" wouldn't quite be describing it, seeing as there is good evidence that our engineers are very productive with PHP. That said, few people if any would disagree with you. We have always been and still are working on a number of solutions to improve on PHP "the language" and also PHP "the platform".

What's the first thing you'd do if you were put in charge of creating PHP 7.0?

Better arrays.

Would you mind expanding on this please?

PHP arrays are very quirky and okay for a lot of things but best at none. They are used as straight contiguous vectors, tuples, singleton sets, maps, ..., you name it. To accommodate all these semantics PHP arrays have very complicated and non-obvious semantics. I think everybody would be happier if PHP had better-defined and more specialized types.

Software dev here. Facebook used to have a bit of a reputation for putting bugs into live (for example when all line returns on photo captions were replaced with "\n"), but it's my perception that things have improved vastly in the last couple of years. What sort of QA or other processes have you guys put in place?

I'm glad you are noticing what has been a years-long effort to improve our process.

First of all, if one at Facebook talks about "process" in the RUP/Agile/etc sense, they'll get a smack on the head. We don't care much about such formalisms. What we do care about is making talented people productive, and for that we have a vast array of automated and semi-automated aides that I'll get into a bit below.

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.

Clearly it's good to move fast, and one thing that virtually all new engineers remark is how astonishingly fast things are happening at Facebook Engineering. A complete n00b could implement a feature visible to Facebook's entire user base literally within a week of starting. The converse risk is that of breakage, and the conventional-wisdom response to that is to increase bureaucracy and slow things down. Facebook has consistently striving to improve tooling and automation that enables people to still move fast, without breaking things.

When things do break we don't reprimand people who make mistakes. Instead, we look at eliminating the causes of breakages at their root.

A facebook headhunter once contacted me and when they said Facebook didn't have QA my jaw dropped but after thinking about it it just made sense. That said, having worked with skilled QAs whose only job is to know how to break your shit in strange and weird ways and mitigate, to some extent, the problem that a reviewing your own stuff is one pair of eyes rather than millions of clueless users pressing buttons in odd ways I'm not entirely sure if one way is really "right" or they're just different solutions to the same problem.

Clearly there are pros and cons. I think no QA is very appropriate for Facebook because it has many users so it can leverage statistics.

D is a great language with a poor tooling. What are the plan to improve on the tooling part (and conquer the world) ?

I noticed that many languages are successful because good people have made it a point to work on them. At this point my focus is to foster good quality in the language proper that would make it attractive for others to join. If I play my cards right and get other proverbial penguins to jump off the equally proverbial iceberg in the water, tooling will definitely improve.

A little while ago, the creator of Go was complaining that C++ programmers don't switch to Go. And the general answer was: Go's advantages don't seem to be enough to make it worth learn it (if you already understand C++.) Python and Ruby programmers, OTOH, seem interested in Go, as a "simple" compiled language.

Would you say D is different? Is there a strong incentive for C++ programmers (and lovers) to have a good look at D?

For programmers already fluent in C++, there is resistance to switching to D. This is because C++ is more entrenched and the "easy to learn and use productively" argument sounds somewhat weaker to those for whom learning C++ is already a sunken cost. In fact I've noticed the strongest resistance from the best C++ programmers, which is psychologically justifiable given C++'s remarkable "knowledge market" - damn, I've been the king of C++ templates! Why the hell abdicate?

There is an increasing amount of programmers who have decided they need the amount of modeling power and efficiency that C++ offers. This is because of a variety of phenomena (no more frequency scaling, heat is becoming a limiting factor, dynamic analysis has its limits etc). For those, I venture to say D is a very attractive choice because it offers all C++ does and a lot more, at a lower cognitive cost and with build times faster by one order of magnitude.

[deleted]

Thank you very much!

I must admit I'm reluctant to switch to a garbage-collected language (which is, pretty much any language that's not C++.) Knowing that everything (objects, memory, files, etc.) will be released/destroyed automatically at a predictable moment is comfortable.

What in C++ resource model is considered so bad that every single other language is garbage-collected? (Let's forget those where you have to do everything by hand, like C, ASM, and butterflies.)

The simple answer to your question that surprises many non-language-pundits is that garbage collection is mainly a tool for memory safety. One may opt for a complicated typed regions system to avoid tracing (Cyclone, Rust), or simply rely on a tracing collector.

I made more remarks on garbage collection in a different post.

garbage collection is mainly a tool for memory safety.

Sure, it's merely one possible tool.

---

 

I see two different programming models -- as in, two different ways to think when programming:

 

Everything is a value. "a=b" means "a is an independent copy of b." A function can return a value.

Static polymorphism (i.e. templates) is king here.

And there's a very simple rule for resource management: when a value gets out of scope, the associated resources are automatically deallocated.

 

Everything is an entity / a pointer. "a=b" means "a is another pointer to the entity pointed to by b." A function can return a pointer.

This is the realm of inheritance polymorphism (i.e. virtual functions). Typically, you have "Base b= new Derived", and of consequently, deep copy is cumbersome and thus, rare.

Of course, for such a model, you need a GC.

 

Both models have their limitations: Sometimes, in the "value" model, you actually need an "entity" object. And things get murky. OTOH, in the "entity" model, sometimes you actually need values. That's why Java has both int and Integer.

What surprises me is that the "value" model, despite working very well (as long as you don't want/need Java-style OOP), seems to have been implemented once (in C++), and was then completely abandonned. Why?

Excitement for "everything is a value" decreases considerably when one realizes all referential structures are precluded (lists, trees, graphs - and a lot of object models are graphs). That in turn locks one out of a vast application area. Having an object that just refers to another is pretty darn powerful.

What's the biggest lesson learned from D that you wish other languages would apply?

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.

Lisp's with-open-file

with-open-file is just a wrapper macro on unwind-protect (for, as the name indicates, performing scoped opening of files). It's not a deferred execution primitive in and of itself.

Sorry, yes, I meant unwind-protect but I had a lapse so I mentioned its cousin that I remembered. Both illustrate the same point.

Given that you are good at writing highly optimized, low-level code I wonder how you could support making D a GCed language. I, and countless other C/C++ programmers, rejected D outright because of the GC. It puts D in competition with C# and Go, not C/C++. I know you are passionate about making D a success and I think nothing sabotaged that more than the GC.

Rust (which has received a much more welcoming reception from the C/C++ crowd) has optional GC, you can choose to make an object GCed by choosing the GCed pointer type, but the standard library (in contrast to D's) is all about values/unique pointers/stack allocation and thus GC is really optional. Do you think D could adopt a similar model? I think this might be the only way to broad acceptance among the C/C++ people.

Getting back to D's GC, I want to point out that you made it extra unattractive by choosing an old clunky one, you just dropped in the ready made, generic Boehm GC. So D not only has GC, but a GC that is far from the state of the art.

If you started with a concurrent/incremental/soft real-time capable bleeding edge GC optimized for D maybe you could have succeeded with a GC too. You really need some impressive benchmarks if you want to sell GC to C/C++ programmers. But I hear nothing about D GC development, you still use the same GC most experimental/hobby languages use. High performance implementations (e.g. Java, .NET) all use custom GCs and for a reason.

Last but not least I have read a lot of horror stories about D's implementation quality, including in the official D forum which I occasionally read. Yet another major turn-off. I watched a video from that recent D conference where you also identified improving implementation quality as important. However, what has been done to achieve that? Simply saying "make it so" doesn't work. You need to change the process and/or the developers. Maybe a (larger) unit and regression test suite is in order, using static analysis tools on the code base, firing Walter ;P etc. Something needs to change for sure.

Tracing collectors are the bane of some applications and the savior of others. Rust's approach is nice but as expected the language has paid dearly for that in complexity, and has left less real estate for other concerns. I'm unclear whether winning that battle wins the war.

A good approach to reducing the effects of GC is to create less garbage in the first place, something that is quite easy in D. That said, garbage collection (even if it's really only litter collection) does have a pervasive nature and we can't have the library force its users into GC if they don't want to. I expect us to improve that in our APIs (e.g. the user should be able to pass an allocator, or even override the global one).

As I mentioned elsewhere on this page, languages succeed if good people decide to work on them. We have a couple of GC experts on "team" already, and things are getting better. The better the GC, the less trash in the streets.

Regarding quality of implementation, there's been a concerted year-long effort on improving it. Subjectively I can tell the impact is already visible - about a year ago there could be no discussion about D without people mentioning they tried something that didn't work but should have. The forums were also replete with frustrated remarks by bona fide users who had difficulty getting work done. (Two years ago everybody was talking about Phobos vs Tango!) Nowadays quality rants are seldom to be seen in spite of increased interest in the language, which tells me that we've turned a corner of sorts that allows people to be productive in D.

D is a very ambitious language; I think it has innovative solutions to some really hard and important problems. Being this ample, it has been difficult for us to follow through rendering the vision in all of detail. We do believe we are getting there though. The proverbial light at the end of the tunnel (you know, the other, incoming, train) can be seen.

How did you acquire such a mastery of the English language (written + spoken minus the accent ) even though it does not appear to be your mother tongue?

I must plead no-merit on that one. All of us get some good and bad inclinations upon birth, and it just so happens I inherited my Dad's inclination for foreign languages.

If I were to speculate it might have something to do with how thoughts are formed in the mind. Many people I ask tell me "I think in my mother tongue". For whatever reason, I don't think in a specific language. It's all that, abstract thoughts, and then the matter of rendering them in a language is simpler than translating them from one language into another.

Are we going to see a D book on range based programming?

I think ranges are really cool, and well deserving of a book treatment. Someone should write it. If you're asking whether I should be the one, I think I feel I have at least one book in me, but I hope to collect a bit more material.

I'm a big fan of your writing style (especially the phrase "hecatombs of code"). What are some of your favorite books?

Thanks, that's very kind of you! Alas, I feel I missed out on reading lately, so I must dig earlier into my youth, from where "Remembrance of Times Past" comes to mind. Recently I've really enjoyed books by David Foster Wallace, Cormac McCarthy, and Neal Stephenson.

In the technical realm, I really enjoy the style of Scott Meyers, who's been a major influencer and mentor. I also like the writing of Herb Sutter, Bjarne Stroustrup, and the late John Vlissides.

Have you read any Thomas Pynchon or John Barth? If you're a Foster Wallace fan I think you'd get a lot out of those two. John Barth's Lost in the Fun House is an amazing piece of metafiction, somewhat fitting reading for the master of metaprogramming.

Thanks for the recommendations!

A perfect question for the king of template metaprogramming:

With support for more things inside constexpr just around the bend, do you think we can now do metaprogramming in plain old C++? Wouldn't it be more natural and easier to debug?

I had asked about constexpr supporting more at GoingNative 2012 but I didn't make it clear why I thought it would be worth while.

Also, a second question if you don't mind: How do I go about making proposals for consideration by the ISO C++ committee? I would like to propose a make_shared where I can provide the allocator rather than it using new.

Thanks for everything you've done, Andrei!

Edit: GoingNative 2012, not 2013. "const_expr" -> "constexpr".

Thanks for the appreciation!

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.

For submitting proposals to to the ISO C++ committee, mosey to the relatively new and unknown http://isocpp.org.

I have been using D for a while now, and I absolutely love it. What are some improvements that are in the works that you personally are most excited about?

Glad to hear that! The most important three features right now are: quality, quality, and quality. We want to finalize the language's ideas to the ultimate detail.

That said, Walter and I are excited about directions like qualifier and attribute inference (more descriptive programs with less source code). Walter has some great insights regarding the relationship between purity and uniqueness, that could greatly improve expressiveness at no cost in complexity - e.g. a pure function returning mutable data must by necessity produce fresh data. Mind = blown.

Following the developement of D you get the feeling that way to many developement resources are spend on new features instead of finishing existing ones. For example a lot of work has been put into user defined attributes while other features are unfinished, unstable or not even usable (alias this, shared, export, structs). Whats your opinion on this?

I agree that we should focus more on completing, streamlining, and using what we've got. This is happening already - it's been a while since quality has been at the top of our list, and the positive PR has been visibly improving.

Now that we have more resources there is some amount of parallel work we could do, and the mixed blessing with volunteer work is people work on what they find interesting, not necessarily what's best to do at the moment. This has been a challenge, but at the same time a good problem to have.

In the D bugtracker there are tons of old bugs (1 year or more) that don't get any attention but concern pretty basic language features. What do you think about adding a "old bug of the month" voting to the D developement process to pick a old bug every month that definitely gets fixed?

I think that's a good idea. Even before that we should look at a "old pull request of the month". It is a shame that we are unable to accept valuable contributions at a faster rate.

First off, I've read a couple of your books and have watched many of your talks online - thanks for putting all of those up. Your easy-going style of presentation makes lectures more entertaining to watch for sure. So onto the questions...

1) Is D used internally at Facebook? I'll understand if you can't answer, but 'no comment' means yes. ;) (answered above)

2) In your recent dconf talk you harped on needing a professional face for D to be taken seriously - have you seen much/any change since the talk and what (IYHO) is the most important thing(s) left to be done?

3) It seems that the GC is largely pointed to as D's biggest drawback as a 'system language', especially since it is required for much of the std lib. Do you have a go to response or link to help allay concerns?

4) If you could change one thing about C++ (backwards compatibility be damned), what would it be?

Thanks!

2) Yes, things are improving; however the improvement will be visible to the public later. I'm very busy right now with my efforts of exploring D within Facebook, which is not directly related but definitely related strategically.

3) The best defense is a strong offense. We are adding precision to the GC and I'm working on an allocator framework that would integrate with the GC while offering a variety of alternatives with a spectrum of speed/safety tradeoffs.

4) I think binding rvalues to const references has been the small mistake that caused the rvalue references Hindenburg.

I think binding rvalues to const references has been the small mistake that caused the rvalue references Hindenburg.

Can you explain further? I'm not familiar with this mistake or the consequences.

It would be a long discussion. Binding rvalues to const& made sense when first introduced (no templates, few subtleties) but in the long term made it virtually impossible to distinguish rvalues from lvalues on the callee side. That in turn forced an overly complex solution (rvalue references) as an expensive fix.

A big improvement for the phobos thing would actually be to make more use of output ranges instead of necessarily returning strings, etc. Then the caller can preallocate memory or whatever they want.

Indeed! That's a sore point right there.

How much more productive do you think D can really be if adopted at C++ scale? Me and other enthusiasts I know are heavily biased by our positive solo experiences with it.

Productivity and its variations are difficult to measure. Build speeds alone, at one order of magnitude speedup, are dramatic enough to exert a change of paradigm. For example, many people say dynamic languages are productive because they have the "right" execution model - save file, hit Refresh. If actual times for a compiled language drop to the point of offering the same model, I think a whole category of perceptions would change.

One thing I noticed with D is its "plasticity". Once you have a body of code that works in C++, the natural tendency is to be conservative about changing it: unit testing is tenuous, subtle failure scenarios upon changes are legion, not to mention build times etc. In D, it's a lot easier to mold and remold designs are you go because you know you wont be penalized for it.

Loaded question. Erich from the Gang of Four admitted that "I'm in favor of dropping Singleton. Its use is almost always a design smell".

If there was anything you would today remove from your Modern C++ book what would it be and why?

[1] http://www.informit.com/articles/article.aspx?p=1404056

I agree that Singleton is a bad pattern. That said, it is ubiquitously known - probably the best known of all. It does deserve treatment, even if only to emphasize its dangers.

I'll tell you what I'd change in Modern C++ Design: the chapters on Allocators. Policy-based design can do wonders at creating layered allocators, see HeapLayers. I just missed that obvious idea, and I regret it.

I've played around with Thrift, and I loved it. What other facebook library do you suggest I play with?

Try folly. I think you'll like it, and find good uses for the techniques in it.

Lots of functional programming features are now available in languages such as C++ and D - what do you think are some of the functional features that we'll see incorporated in languages such as those over the next decade or two?

There's talk about purity in C++, but beyond that I'm not sure whether there are plans for major FP-related additions.

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.

How do you think about some standard package manager for D, like npm for Node.js and RubyGems for Ruby? Are there any plans yet?

Yep, code.dlang.org is the main candidate.

Andralex,

No question to ask, but the comment that I carry the D language book with me at all times, and re-read it like it is a novel; I love every line of code I write in D, and the language and its design choices make me a better programmer the more I understand them. D simply makes sense, and it is a shame that it does not have more traction... I am an seasoned C/C++/Perl programmer, and D is in many ways the epitome of the history of languages, in my opinion.

Thank you! No worry, we'll figure out the traction issue :o).

Are you working on or thinking about any new books for D? Something like a D patterns or best practices, or whatever?

Not trying to seed anything, just really enjoyed your D Programming Language book for an overview and its style, and am interested in reading more on your thought on how to approach using D.

I feel I have one book in me. I'll need to figure when to write it. Thank you for your appreciation!

I don't like the separation between Structs and Classes in D. I think that having to avoid classes if you don't want to use the GC could force people to have implemented the same artifact as a Class and as a Struct. Also don't get why a value type / stack object is simply not allowed to use runtime polymorfism. It feels more natural when you can do such distinction when defining a variable type, as you can do in Rust. Could you defend the D approach over the C++ aproach or the Rust approach?

Thanks in advance Andrei, I'm following your work since I've discovered your book Modern C++ Design!

class vs. struct comes up occasionally as a minority opinion. Walter's basic insight was that polymorphism and value semantics rarely mix, and when they do, they rarely mix well: there are about a million ways to declare a data type handling value vs. reference semantics incorrectly in C++. Clearly there are a few legit cases (like allocating a polymorphic type on the stack and aliasing its address), and people feel robbed of that possibility. The matter of fact is that such ambiguous-gender types and their uses are rare enough, and their converse troubles are frequent enough, to warrant designing them away (you can still allocate polymorphic objects on the stack in D, it's just not dead simple, you need to use emplace).

For Rust it makes more sense to tackle the problem differently because it gets to tap into its already sophisticated pointer/region paraphernalia. For D, the decision to split struct and class is, I think, a winner. We're very pleased with it.

What does your typical day at Facebook look like? How much of it involves coding?

Aside from reading reddit you mean? :o)

Here are a few scattered tidbits.

I use the shuttle to/from San Francisco, and I get to read or get work done on it.

A lot of what I do is coding. I need to wait long times for building and performance testing, which I try to fill by tending email, reading papers, or trying new ideas (most Facebook engineers have multiple parallel git trees so they can work on several things simultaneously.)

We don't have many meetings, and those we do have are actually interesting.

Chats every so often with coworkers.

Reviewing code, perusing internal forums.

But most of it coding.

The first few chapters of "Modern C++ Design" helped me a lot in understanding templates (and functional programming in general.)

A chunk of the book, OTOH, left me skeptical. Did you really think people would start using those techniques in everyday C++ programming, or was it an exercise to see how far you could go into template metaprogramming?

In the former case, has your opinion changed, twelve years later?

(I'm thinking especially about typelists, actually.)

I approached Modern C++ Design with a very pragmatic mindset: I wanted to create good designs, and the next step was what steps to take to realize them in C++. There is no artifact there that's not actually used. I think it was a major misunderstanding that people subsequently dubbed me as a "templates guy". I was aiming for a "design guy" title!

I stay with the same opinion now. If you want to do a generic Factory, this and that is what it takes in C++.

Fortunately typelists are made considerably easier by C++11.

I was always enthusiastic about D and wanted to learn it for a long time. However when I finally got around to reading your book, I found that D just has too many features, trying to accommodate everyone and every situation and corner case. I had to drop D eventually because the number of keywords and special-case keywords just seemed to impractical. (Sidenote: C++ seems to be heading in the same direction, adding new features to an already fairly overloaded language). In stark contrast to this we have Go, which is often praised for its rather small, orthogonal featureset.

1. What's your opinion as a language designer about this feature-richness/simpleness trade-off?

2. Are there any features in D 2.0 that, in hindsight, you would want to drop?

3. Any ones you wished you had incorporated but didn't?

Related reply.

1. As there are languages all over the spectrum, clearly this is a matter in which reasonable people may disagree. Probably a good judge is "power offered per cubic inch of complexity" or something like that. Languages like D, Scala, or Haskell do well at that metric. Go is simple but in my opinion not the right kind of simple; in many ways it's a sort of a collective bummer that a language like it has emerged in this day and age. However, as I said, languages succeed because good people work on them, and there are good people working on Go.

2. I'd drop the postblit this(this). It doesn't work well with qualifiers.

3. If I could have added a means for transparent reference counting without adding complexity to the language, I would have.

I've read that at Microsoft a great number of programmers are Romanian. Is the same true for Facebook?

Yes. Allowing for exceptions (a large Israeli company acquired), Romania is the foreign country most represented per capita (or at least in top 3 since I last measured) at Facebook.

Why does facebook use PHP?

The simple answer is because it started with PHP and there's never been enough reason and opportunity to replace it. Our engineers manage to be productive in it and compensate many of its weaknesses by tooling.

That said, the cost of tooling itself comes to mind. A lot of effort of our best engineers has been expended on e.g. improving the speed of PHP code, which in other languages comes by design, and in others is easier to achieve.

At any rate, if any other language is to supplant or replace PHP at Facebook, it would have to interface nice with PHP.

If you had all the time and resources in the world for a new (that is: not D) project, what would it be?

Have you played Empire?

Heavy! I think I'd work on some heavy AI project - I have this dream that cell phones become assistants more useful than, and almost indistinguishable from, humans.

Never played Empire. Let's hope Walter doesn't see this. Please downvote.

How do you debug PHP code running under HHVM? There didn't seem to be any way to connect using XDebug or Zend debugger protocols. How do Facebook engineers debug their code?

A couple months ago I set up an Ubuntu VM with HHVM and tried to get Drupal running on it, and searched for any debugging info that could give me some hints as to where it was failing and came up empty.

Keith Adams has created a nice screenshot of our debugger in action. It's an in-house project. It is a young project though, so I'm not sure when it'll be opened to a wider distribution.

Keith Adams here. Slight correction: hphpd is part of the HipHop project, and as such has been part of the open source project since the beginning. Hie thee to github: https://github.com/facebook/hiphop-php

I stand corrected. Thanks!!

What aspects or features of the D programming language do you think are most underappreciated -- respectively, by newcomers and by experienced D developers?

For one reason or another Contract Programming is underused, even though we've spent significant effort defining and implementing it. But then I don't think it's essential - many people do Contract Programming organically with assert and scope without calling it a specific way.

I don't have major bitterness about any one feature. It seems to me that D doesn't push n00bs too hard one way or another, so they get to use the language as it's meant - holistically and pick the right tool for the job. That said, I think the amazingly powerful opDispatch is far, far from having really been discovered.

At going native this year, you mentioned that C++ is closely tied in with the von neumann architecture architecture. Is this true of D as well? Does it mean that if the von neumann architecture were to be replaced by something shinier, C++ (and D) might vanish into oblivion?

Also, do you think functional languages are better in that sense that their abstractions are not tightly dependent on the von neumann architecture?

Notwithstanding, I'd like to hear what you have to say about functional languages and what you believe is their role in the coming years.

Yes, both C++ and D build on the same fundamental computing model: data has addresses, you know where it is and you know how it lies. But I'm not worried - if von Neumann is fundamentally replaced a lot of languages will need to adapt, and probably the best breed will be new ones that use the new model organically.

I'm not too good at predictions, but I did predict the next two paragraphs were to follow after seeing the first :o). There's clearly a lot of good in functional programming, and I think it's undeniable that features once considered hardcore FP are making it into the mainstream.

Betting the farm on FP as the universal computational model would, however, take matters too far in my opinion. FP is doing okay today if the likes of 2-3x in performance is no matter to you. (I know, I know, there is this benchmark and the other etc.) It's possible that FP will be doing okay but just as mediocre on a new computing substrate. Also, it shouldn't be forgotten that FP offers, simply put, just crappy solutions to a variety of simple problems. It is nice in the sense that it's mathematically motivated, but there's plenty today that is also mathematically motivated. Formalisms have made good progress in the past two decades.

What do you see in the future of Generic Programming and D. Also, do you see any value in concepts and could you possible see their implementation in D?

I hope Generic Programming evolves to the point where D (which is now probably the best champion of) will be considered a horribly outdated way of doing it.

I'm not so sure about concepts, and in particular the net value they add. I honestly have difficulty distinguishing their genuine value from the "Emperor's clothes" phenomenon surrounding them. ("Concept" is a great word, and words have power.) Problem is, many uses of concepts have been straight aimed at programmers who'd be willing to deploy software without having ever unittested it or even tried it, ever. I'm not sure that's a good category to cater for.

Has languages like Haskell and ML influenced you as a language designer? Are there things that you would want to implement from these languages in your own compiler?

Absolutely! (Haskell is in a way its own universe because a lot of what it does derives from two simple axioms - non-strict, pure.) I think the main two things D stole from the FP community have been purity and data immutability. D adds a really useful relaxation of purity that allows one to define e.g. pure factorial with private mutation.

Why did Facebook decide to implement HHVM, instead of using LLVM in a manner similar to Julia?

I think facebookllvm's information is quite outdated. We look at LLVM with obvious interest, are well aware of what it does well, and are keeping it in mind for future developments. Our current assessment is that our own specialized toolchain would be better at meeting our demanding performance needs. I think we've got good confirmation of that.

That said, never say never. It is quite possible we'll start using LLVM in a significant capacity in the future.

Is there any hope to add something like Grand Central Dispatch into C++ standard?

I don't know of any work on that.

What D's: * worst weakness? * design decision you would like to change? edit: Removed questions skeksis268 link answered

From a pure language standpoint, D's worst weakness is too little control over escaping of addresses. From a larger ecosystem standpoint, D's worst weakness has been quality of implementation.

In Going Native, most of the panel seemed to agree that you should pass by value now rather than by const reference.

I did some ad-hoc measuring with the idea and found that when you pass temporaries it's indeed noticeably faster, if by a small margin. Of course, for cases like you talk about where there's a loop that can take advantage of repeated use of the same allocation space it's slower. That's a rather obvious case though.

I have some concerns with the pass by value policy even if it's faster. For functions that do not make copies of the parameter, but only refer to it as constant input, it's possible and probably likely, for client code to move from making a quick call with a temporary, to making a slow call with an lvalue. This is a silent switch from something generally faster, to something generally slower, that can easily be done during maintenance without warning or clue that's what happened.

I'm not sure you agreed with the recommended policy, it seemed maybe you did not, but my attempt to contact Abrahams (the author of the cited paper) to ask this question failed. I wonder if you might have input on this or perhaps ideas to alleviate my concern and make it a non-issue. Or reasons why it might be a cost worth paying of course.

It's a good point. On the API side there's an issue as well - functions change back and forth between taking fun(const T&) <-> fun(T) depending on internal implementation details (i.e. whether the function needs internally a copy or not). The signatures are similar enough, but not identical, and may cause issues.

It seems like whichever way you choose you hurt "half" of the cases. It does seem to me that passing by value if the callee needs a copy is the most natural way to go.

Hi Andrei,

I feel like C++ is a language that can be used very well by people who really mastered the language. However it is extremely hard for novices to pick up. Even "good" programmers make mistakes, because in there exist a multitude of ways to do something, and for them its next to impossible to know which one is the "right one". If you take a class from an above average programmer, you'd still find tons of things to improve: const correctness, exception safety, copying not handled properly, parameters not passed at maximum efficiency, RAII not used and so on.. Often their classes even work in the current usage patterns, yet are in fact incorrect and lead to bugs when used differently.

Do you think there is anything that can be done against this issue? I feel like teaching does not really solve this, because there is simply too much to learn about the language right now. Not ever breaking backwards compatibility makes the language perpetually grow and even intensifies this issue. Is C++ becoming a language of just a few experts...? (if this isn't already the case oftentimes...)

I don't think there is a simple solution to solve this problem. To wit, Herb Sutter gave a great keynote part of which illustrated how easy it is to write C++. The rub? One of his "easy" programs had a bug.

Hey Andrei. Do you get a chance to apply your Machine Learning skills at this job?

Yes, see this response. To the extent I've switched to systems work it's been by choice. I think I'll do more ML work in the future. We have great infrastructure for ML.

Hi Andrei,

That's awesome to have you here! Here are 2 quick questions I did not see:

• What do you think about the Go language ? Which kind of feature would you borrow from it ?
• What do you think about having more threading aware semantics in the languages instead of threading libraries ? (I'm thinking for example to the "synchronized" keyword in Java, or the Go, etc).

Thanks !

1. (I assume there's understanding that I'm horribly biased.) I have a dim view of Go; I find it an unremarkable "me too" language that would be nowhere fast if Google weren't behind it. That said, it is executed beautifully and Google's engineers are true to form in delivering world-class server-oriented libraries for it. Go will probably never supplant C/C++/D for systems needs because it requires GC for core operations (fact understood by its proponents who rewrote the marketing message shortly after the initial launch). From Go I'd borrow the engineers who wrote its networking libraries.

2. There is no way around having the language understand concurrency at its core (unless it designs around it entirely, like PHP). The exact distribution of capabilities across language and library becomes a matter of taste. I'm a minimalistic guy who prefers "few axioms, many theorems" which applied to this would put few primitives in the language that allow for rich libraries.

What do you think of the future of the Perl language and related career options? I really love Perl but I'm not sure what I think about it as a long-term path.

I dabble in machine learning myself - mostly Kriging with a PSO optimizer written in good old FORTRAN.

I've used Perl a fair amount during grad school. Unfortunately it seems to me Perl has outgrown its own capacity to manage itself. Perl 5 is wanting (no named function parameters...) and Perl 6 has timed out. I'd probably advise to not use Perl. It pains me to say this because I know some good hackers have put solid work into and with it.

[deleted]

I use emacs, but I've been a Visual C++/Studio programmer for years and I appreciate its power as well. I keep on considering installing Eclipse.

Do you like PHP?

I do not appreciate PHP from a programming language design viewpoint. That said, it is undeniable that good people can be incredibly productive in it, and that it has nailed the basic request/response HTTP flow quite nicely.

What are the modern C++ template metaprogramming idioms that you think are the worst, and how would you go about replacing them (with standard changes, for example)?

Disregard anything solved by static if since that's too obvious given your feelings on the matter.

After static if and friends, I think the awkward manipulation of template variadics is a real bummer. I would have designed the entire feature very differently (closer to the way they're done in D, which pleases me).

What's the layman's TLDR of your job? Thanks.

Until recently it's been simple: make HHVM (our VM interpreter of PHP) faster. It saves everyone a bunch of heat, power, and money, and it's very fun and instructive.

I'm transitioning to a position in which I'm looking at a broad spectrum of approaches to improving the productivity of our engineers. That includes most notably exploring the use and integration of D within Facebook, but also "simpler" things such as the build system, libraries, configuration management, and such.

Before all this I've been working on Graph-Based Machine Learning on the social graph for a variety of tasks related to ads and Graph Search. Probably I'll return to that in the future. I also took a few months to help launch folly, of which I wrote most of the initial code.

I don't have a question, but just wanted to thank you for all of the great writing / speaking you've done about software design and best practices. Also, IMO you're famous enough to have put your name in the title!

Thanks very much!

I'm a computer scientist just about to graduate college and enter the professional world. Any tips for a young professional that you wish you knew coming out of school?

Congrats. I wish I'd known how bad it is to be the best guy in the room. It is enjoyable in the short term, but toxic in the long term. See also this.

It seems a lot of programming languages are shaped by the early adopters and domain they are applied to.

Have there been any significant production users of D so far? If so in what domains and how has the feedback loop worked in terms of shaping the language?

Sociomantic has been our first major user, and Remedy is another. Both are players in industries where efficiency is an important concern, and it's become crystal-clear to all involved that we can't afford to sacrifice efficiency for pretty much anything else.

Facebook has a similar outlook - if interested in D, they'd be only as a language that is as efficient as C++ while also better in other dimensions.

Lambdas are a good example of design that has been influenced by these concerns. In the olden times lambdas used indirect calls (like in most other languages, C++ excepted). Before long we figured that's not going to cut the mustard so we allowed lambdas as alias parameters (i.e. no indirections).

So, can you write D2 code without worrying about const if you don't want to bother with it yet?

Will we ever see tuples as native syntactic constructs that automatically distribute over function calls? Like DIP32 (or Neat)?

Is D ever gonna have named parameters? Like foo(a => 3);?

Is it ever gonna get function declarations without required {}? It lets you do nifty things like void foo(Class cl) with cl { }. (Yes, I'm just going through the shopping list of "syntax features in Neat" :)

Will we ... oh screw phrasing it as a question. You should totally support automatic binding generation of C/C++ libraries (via a reserved import namespace, like "import cpp.headername;"). It is insanely useful, in my experience.

So, can you write D2 code without worrying about const if you don't want to bother with it yet?

Absolutely. To wit, there's plenty of fine code in other languages that don't even support immutability. It's nice that D gives you the option, but that doesn't mean you need to take it.

Will we ever see tuples as native syntactic constructs that automatically distribute over function calls? Like DIP32[1] (or Neat)?

I think we need a little syntactic help for tuples. I'm not a fan of automatic expansion, I prefer t.expand for expansion and t to preserve tuple's identity.

Is D ever gonna have named parameters? Like foo(a => 3);?

The topic comes up in a while. I've seen code in Python that makes good use of the feature. So... possibly?

Is it ever gonna get function declarations without required {}? It lets you do nifty things like void foo(Class cl) with cl { }. (Yes, I'm just going through the shopping list of "syntax features in Neat" :)

Probably not.

Will we ... oh screw phrasing it as a question. You should totally support automatic binding generation of C/C++ libraries (via a reserved import namespace, like "import cpp.headername;"). It is insanely useful, in my experience.

It sure is. Trouble is what to do with C++ templates.

How well do you feel version control at Facebook is working?

What is a good workflow for you to put code out in the open?

And: Git/Mercurial? vi/emacs? cats/dogs?

Related: this reply.

I have to say giving and receiving code reviews are among the most enjoyable aspects of my work at Facebook.

We're switching from git to mercurial for scale reasons. I'm fine with anything that works, and love the concept. I give a ton of credit to Linus for having created git back in the day.

emacs

dogs

We're switching from git to mercurial for scale reasons.

Could you tell us more about that point?

dogs

What‽ Get off my Reddit!

We're switching from git to mercurial for scale reasons. Could you tell us more about that point?

Git takes long times with our front-end source tree (which is enormous). The matter of customizing git came up and people looked at the code and decided it's pretty convoluted when compared to the Mercurial code.

From your last name, I assume you are of Romanian origin. Romania today is a historic example of Soviet control and domination of every aspect of life.

Do you feel that your work at Facebook is enabling those that want to automatize a similar system of control and domination of the internet?

I remember some funny "control and domination" aspects of Communist Romania. One was, for example, that copiers in offices were under police control (underlying a fear of copying subversive pamphlets). At a point, frequency-meters had also been put under police control. You know, those devices that measure the 60 Hertz (or 50 in Europe) of your power lines around the house.

What's the deal with controlling frequency-meters? Well, the government wanted people to consume less electricity. So for a while they'd cut power for 1-2 hours a day. Then they figured this actually costs more in destroyed heavy-duty transformers and relays (they don't like that transitory regime). So then they reduced the frequency of power supply from 50 Hz to 47 Hz. But they didn't want to admit to it, so they'd put all frequency-measuring devices under police control.

Why am I telling this, and what's the connection with the question at hand? For perspective and contrast. A controlling state does its best to hide and conceal information. In contrast, today's social networks have openness and connectedness as a core value, in stark opposition to the atmosphere in a totalitarian regime.

Why work at FB rather than at a smaller company? Possibly consulting jobs, where you would be THE code expert / guru / professor / reference, rather than 'just one more engineer' (no criticism here). You could surely make more money and have more 'impact'? Especially if you've been at FB for 4 years, the financial incentive there is disappearing...

"comnovember" stole some of my thunder here: I planned to mention "If you are the smartest guy in the room, then you are in the wrong room". There's another one, maybe more insightful: "If you study alone, you learn from a fool."

Following Modern C++ Design I have considered a consulting career. But I dislike being a guru. I'm happy instead I pursued things that have consistently kept me below the 50th percentile in the room: a doctorate and a job at a company famous for hiring very good people. I would recommend that to anyone.

Facebook has been a good employer to me in many ways. (And by the way damn it I'm a Research Scientist, not a Software Engineer!) People are incredible (talk about impostor's syndrome), and I got to do and learn a bunch of interesting things, some of which literally cannot be had elsewhere. That, as opposed to dispensing "gurudom".

You're one of the computer scientists I respect a whole lot in the industry right now (the others including Bjarne, Scott Meyers, et al) because you have a really great amount of practical experience and theoretical knowledge, and combine them in such a way that is really informative and shows in your talks on C++.

The computer scientists in my university have really no appreciation for the many practical applications and can barely code to save their life, and I'm only kept sane by books like yours, Herb's, Scott's and Bjarne's. Any thoughts on how computer scientists can be as balanced like you with respect to theory and practice?

My question is: Any thoughts on how computer scientists can be as balanced like you/Bjarne/Scott with respect to theory and practice?

(For what it's worth I'm on the other side - I can barely do research to save my life. So there's two sides to the coin. Bjarne is unique in more than one way, he's been producing very good research on top of all his other contributions, which is very remarkable.)

I know quite a few researchers who are also good engineers, but in a way that's beside the point. In my opinion research and industrial work need similar but distinct skill sets, and this is a large enough domain for us to allow for specialization. We wouldn't expect a good compiler guy to write great Web frameworks, so we shouldn't expect that researchers are good at engineering their code.

Do you think AGIs (Artificial General Intelligence) in the level of a living being are feasible? Do you believe in the technological singularity?

I see no reason in principle for which AGI can't be attained (unlike antigravity or time travel). If we don't achieve it, we may as well be in trouble because we seem to create mess at a slightly faster pace than we can fix it. So in a way we're in a timed race - we need to get with the resources we have right now, create enough intelligence to figure out what to do when they're dwindling...

Singularity is an interesting concept. It has appeal to me, but it has a few tenuous premises: never-plateauing exponential progress, and a few imponderables of human nature.

I see no reason in principle for which AGI can't be attained (unlike antigravity or time travel)

I just came out of a seminar on antimatter containment and cooling. It's actually quite feasible that antimatter anti-gravitates! Some of the more senior theorists in the particle physics world are on board with the idea (although by no means all). Experiments are currently being designed to test it.

Thanks for the info! Time to eat my hat :o).

There are a lot of C++11 implementations of ScopedGuard, however there's no guarantee that they are correct. Do you know of/made a correct and tested implementation of this feature? I have seen your presentation, but I can't find the code. ( ScopedGuard11 )

folly has a reasonable implementation of C++11 ScopeGuard. I plan to update it soon.

Boost has ScopeExit library - I think it should be well tested. It works on old compilers, with C++98. Also it supports C++11 lambdas when they are available, but unfortunately that case is not optimally implemented - because it stores lambda in boost::function which may cause costly allocation due to type erasure. Folly's ScopeGuard uses type deduction as Andrei described in his talk.

I have made platform-specific implementation of uncaught_exception_count function year ago. It works on many versions of major compilers(actually on all versions that I have tested) and allows to determine whenever destructor was called due to stack-unwinding or due to "normal" scope leaving.

It is possible to implement scope(failure/success) features from D language based on top of such unwinding indicator. scope(failure/success) is basically scope guard without need to dismiss/commit manually at each exit point of scope.

Here is proof-of-concept implementation of scope(exit/success/failure) in C++11, example of usage at the bottom. Syntax is very close to D language.

Thanks! You should know I still have your email in my inbox :o).

What is your opinion on language change which would break existing user's code? Mainly I mean change which remove or improve some part of language which was not well designed for the first time.

There's been a great discussion about that at DConf 2013, started by Don Clugston. His thesis was that there's good breakage (i.e. that breaks code that was bad anyway) and there's bad breakage (gratuitous name shuffling etc).

That said, experience has taught us that any breakage you effect, someone out there will boo you for it. The goal then becomes to only introduce breakages that maximize cheers and minimize boos. Not a simple problem.

Hey there, thanks for the AMA!

I am a Statistics PhD student interested in Machine Learning.

Do you know what the job outlook is like for people with advanced degrees in the field?

I think Machine Learning is the applied math of the future, and Statistics is its algebra. I think you're in as good a place as one could hope for. I'd highly recommend an intership, Facebook and many other companies are offering such.

C++11 introduces strongly typed enums, a preferable and safer alternative in most cases to unscoped enums. Unfortunately providing operators for strongly typed enums is tedious, and conversion operators cannot be defined. If more control over the provided operators was allowed, it would allow strongly typed enums not just to be used as a way of enumerating value's, but instead as a strongly typed integral. It improves the usability, allowing for bitmasks, units, and any other abstraction to preform some subset of operations safely.

Essentially it would function similarly to the proposed opaque typedefs, except strictly on integral types. Obviously there are benefits to being allowed to represent values as strongly typed integral constants. It can be used as a template overload as both a value parameter and as a type parameter (std::integral_type) and forward declared enums are complete types.

You would by default get the same type safety guarantees as strongly typed enumerations except for where you explicitly specify otherwise. Since the compiler knows exactly how to preform any of the default operators on a strongly typed enum, why not just ask it? I propose an extension that allows operators to defaulted.

For example:

enum class A
{
    zero,
    one,

    // Tell compiler to use the built-in operator
    A operator+=(A) = default; 

    // Option 2: Less ambious to parse, makes it clear that this is not a member function
    // But could conflict with an external definition
    friend A operator+=(A, A) = default;

    // enumerator definitions can be mixed in
    two
};

note: operators cannot be declared, or defined unless by default

It believe that the modification to the grammar would be reasonable. Especially if parser look-ahead is not a concern. but am entirely ignorant to the realities of implementing this.

Along with the unary and binary arithmetic and bitwise operators, other operators should be considered as well; including increment and decrements, as well as operator bool and operator underlying_type.

If it is possible to use the built-in operator semantics, that would be preferable, It would be even better if you could default an arbitrary integral type on the right hand side.

While I think this alone would be a huge step forward, allowing for users to declare and define friend functions within the enum class would be very useful as well. While we are at it, why not typedefs and string conversions!

I think it's late to think of improving enum as a language feature, but I think C++14 would make it palatable to define user-defined enums that get close enough to what you want.

And I agree with you good categorical types are great!

Thanks for the response. What advice would you give to somebody who wants to become involved in C++ language evolution? ( also do you know what paper contains the proposed changes for C++ 14. I haven't been able to find it )

See Gary's excellent reply.

I will probably gain a lot of downvotes for this, but:

Twitter migrated from Ruby to Java to Javascript on the server side.

Have you considered Java?

Facebook already uses Java intensively in a number of projects.

I've seen progress in usage and implementation of CSP, green-threads, actors etc in several languages (rust, go, scala, erlang). Experimenting with CSP implementation of go, I find it a particularly powerful and easy model for leveraging concurrency power and managing latency. I've seen attempts of including higher level models for concurrency like async in c++ (almost deprecated?), I've also looked over the executors proposal, and sorry, dunno about D in that area. What you think about these higher level models? I find them quite useful, but for C++ for example, I see no light of having something as easy as in Go. I've seen, e.g. lambdas added and it's quite usable... but I ponder whether C++, dubbed a language that fosters performance, would have these kind of utilities added in the short term. Sorry for the ignorance, does D have easy to use implementations of such models too?

D uses the Actor model, which some consider a dual of CSP. In CSP streams are objectified, in Actor endpoints are objectified. One can be realized in the other.

The entire chapter on concurrency in D is available freely. In addition to Actor, D offers controlled data sharing by means of the shared keyword.

I think such models are great, and they are realizable in C++ as much as anything else. Sharing by communication is relatively easy. Unfortunately, on occasion direct data sharing is still needed (mostly for performance reasons). Here languages such as C++ and D are at an advantage because they can afford it.

What advances do you see machine learning making in the near future? Are there plans to use it more extensively with facebook, and how so? (If you can tell us)

And what is one interesting thing about your job that nobody has asked you yet?

I think ML is very strongly poised for advance nowadays. Serial speed of computing has stalled but people find ways to express kernel algorithms in parallel ways, and most importantly data has grown unabated (bandwith has effectively increased exponentially).

More data means better ML even with simple algorithms, and it's not impossible we'll witness a new phase change soon. (I think Siri has been such a phase change - an essentially clunky research artifact has been elegantly productized.)

Facebook does a lot of work on ML. To answer your second question, you've just asked it! I've personally done a good amount of good ML work at Facebook, unfortunately most of which is not publishable soon.

So what do you think about neural networks? I think it's fascinating, since they seem to show the possibility of hybrid serial/parallel communications between nodes, much like the human brain can string single or multiple neurons together. Do you think that technology could remove that limitation?

And you speak of phase changes - do you think a significant ML advance could hail a paradigm shift in our society, and the way we interact with technology?

And thank you for patiently answering my questions! I think what you do is very fascinating.

So what do you think about neural networks? I think it's fascinating, since they seem to show the possibility of hybrid serial/parallel communications between nodes, much like the human brain can string single or multiple neurons together. Do you think that technology could remove that limitation?

I've used conventional neural networks for my research, with good results. Neural nets couldn't have been used for such tasks only 15 years ago, computers were too small and slow. Right now the use of neural nets is on the rise. A new paradigm called deep learning seems to do even better.

And you speak of phase changes - do you think a significant ML advance could hail a paradigm shift in our society, and the way we interact with technology?

Yes, I believe so. ML is already changing the society, but probably the connections are not obvious yet.

How much skill is needed to code Facebook? Also what is it like working for Facebook?

Some of the best coders I know I've met here. Coding is an essential skill for a Facebook engineer.

I enjoy working at Facebook a lot, well beyond the "free meals, cellphone, laptop, and perks" mantra. It's a place where I get to work on hard, interesting problems. One thing that Facebook has that's rare at a company of its size is flexibility: people are encouraged to switch jobs roughly every year (though that's totally opt-in). In contrast, most of my friends who work at <this other company> would say it's a great employer, it's just that they're stuck in this crappy project for the past two years and a half.

Are there books, literatures, talks, source codes that you recommend I look at in order to get better at C++ optimizations and performance engineering?

I don't know of many C++-specific materials for performance engineering. But a surprising ingredient is math. Take a look at Hacker's Delight. It's a bunch of bit twiddling hacks derived from immutable mathematical truths.

A lot of good optimizations stem from a good understanding of the computing fabric combined with an ability to formalize abstractions that mesh well with it.

What was your first application you wrote? What was your second? Also languages.

My first application was a keyboard driver in assembler. It used only 782 bytes of memory as opposed to the default of 4KB. I wrote it because I only had little RAM available.

My second application was a floppy disk formatter written in C++. It formatted 5.25'' floppies to 1.6 MB. Floppies were expensive and I couldn't afford many. Of course, they didn't retain information very well, but long-term retention wasn't at the top of my list :o).

What systems (database, operating system, distributed) other than language and compilers are you interested in? Are there projects that you would want to work on?

I am interested in distributed graph computing infrastructures (we have a large installation of Giraph) because it's related to my Machine Learning research interests.

What is your opinion about C#?

I think C# is a fine language with a lot of power.

How much D is different from C++ or C#?

It's difficult to give a short reply to this without background and many qualifications. In brief I'd say D offers a lot more "power per cubic inch" than C++ (in addition to much fewer tail smokes). Comparison with C# is more difficult because there are more dimensions (Microsoft/not, native/VM, etc). I think D does better than C# in the generic/generative areas and C# does better (restricting discussion to the language proper) at dynamic introspection and async/await.

How painful is it to work with Paul?

I know an ouroboros when I see one!

Array indexes start at?

...whatever your policy prescribes?

how often does facebook update or create a new layout? And is advertisement on your pages the only way you make money?

how often does facebook update or create a new layout?

I wouldn't know, I don't work in front end. I can tell we deploy the VM engine twice a day.

And is advertisement on your pages the only way you make money?

No, but it is the most prominent.

Don't you think it's time to improve your english accent?

also you look like this guy

I wanted to go to one of those accent improvement schools, but never got around to it.

I think that guy wouldn't be flattered.