Facebook Engineering

I disagree. I think it was entirely related. Facebook could likely put up with a few dissenters here and there, but a major defector such as Wordpress is a canary: they likely feared that this would be the first domino to topple React's supremacy.

FB: "...we know that many teams went through the process of selecting an alternative library to React. We're sorry for the churn. We don't expect to win these teams back by making this change, but we do want to leave the door open."

This can seem like a response to the community at large, but can also be read as a direct response to Wordpress' comments:

WP: Automattic will also use whatever we choose for Gutenberg to rewrite Calypso — that will take a lot longer, and Automattic still has no issue with the patents clause, but the long-term consistency with core is worth more than a short-term hit to Automattic’s business from a rewrite. Core WordPress updates go out to over a quarter of all websites, having them all inherit the patents clause isn’t something I’m comfortable with.

Now if someone (i.e. an Actual, Impartial Lawyer) can explain if changing to MIT actually changes anything.

EDIT:

As others have pointed out, FB reaffirmed its decision to maintain the patents clause on Aug 18th (33 days ago): We recognize that we may lose some React community members because of this decision. [1] But they change their minds 8 days after the Matt published the On React and Wordpress article.

This pretty much proves that the decision…

Gabriel (as well as the others on the team) have definitely looked at these areas - if things were left out/not "featurized" it was likely done via an ablation test, or showed improvement over benchmarks, or maybe just to set a baseline, as he is quoted in the main article. I don't know what techniques they used here, but I am excited to find out!

On the specific issue of encoding time-dependent behaviors in models, I think it is related to a broader issue that shows up in many application areas. To me the critical factor is that these models are ruthlessly good at exploiting local dependencies and totally forgetting long-term global dependencies or respecting required structure in control/generation.

This basically means it is very difficult to train long-term, time dependent behavior without tricks (early/mid/late game models, extensive handcrafting of the inputs, or using high level "macro actions"). Indeed, FAIR's recent mini-RTS engine ELF directly gives macro actions, in part to look closer at how well global strategies are really handled and remove one factor of complexity [0].

Gabriel's PhD thesis was entirely on Bayesian models for RTS AI, applied to SC:BW [1], so I am sure he is well aware of the "classic/rules based" approaches for this.

[0] https://code.facebook.com/posts/132985767285406/introducing-elf-an-extensive-lightweight-and-flexible-platform-for-game-research/

[1] http://emotion.inrialpes.fr/people/synnaeve/phdthesis/phdthesis.html

I've just finished reading https://code.facebook.com/posts/1716776591680069/react-16-a-look-inside-an-api-compatible-rewrite-of-our-frontend-ui-library/ and it provided lots of good insights into how you managed to roll out the new release. Thanks for the interesting write-up!

That blog post mentions your featureFlag approach, the initial dogfooding and then the gradual rollout. I'd be very interested to hear on top of that:

1. How did you approach the rewrite on the coding side? What I mean is: Did you just say "Okay, let's start from scratch and use the lessons learned from v1?" Or did you use a specific approach along along the lines of: "Let's structure our code based on these principles and ...?"

2. When you started the rewrite, how did you know in advance and make sure that the rewrite would be faster and have a smaller code-size?

3. Was your focus during the rewrite on a cleaner code base (and the performance improvements followed automatically) or was your focus on speed right from the start?

4. Any other lessons learned during the rewrite? Patterns and approaches that helped/didn't help during the coding?

No, not really. Apart from the reply above about bitkeeper, I'm not aware of any new or old (d)vcs that does "sub-modules" well.

There's AFAIK been some orgs working on mercurial in order to support large mono-repos - I don't know if it's better or worse than git today. I see that Illumos (opensolaris) have shifted from mercurial to git, for example:

https://wiki.illumos.org/display/illumos/Mercurial+Workflow

(Solaris/Sun was a somewhat early adopter of "big" mercurial repos).

Working with big mono repos are not without challenges:
https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/

FWIW I tried using sub-modules for mercurial some years ago - in the end I realized it was probably not worth it. I'm also skeptical about go's use of "vendoring" dependencies for a similar reason.

From https://code.facebook.com/posts/112130496157735/explaining-react-s-license/

> As our business has become successful, we've become a larger target for meritless patent litigation. This type of litigation can be extremely costly in terms of both resources and attention. It would have been easy for us to stop contributing to open source, or to do what some other large companies do and only release software that isn't used in our most successful products, but we decided to take a different approach.

Never heard Facebook answer: why didn't they just follow Red Hat's model and make a "Patent Promise"[1]?

Then accumulation of software patents would help deter meritless litigation while staying out of the way of FLOSS developers getting their work done.

[1] https://www.redhat.com/en/about/patent-promise

So curious what the other hardware is/does.

Dan Luu wrote that Intel's cache allocation tech particularly helped Google, so they could run multiple workloads on one machine without totally trashing the larger caches at every context switch: http://danluu.com/intel-cat/

The Xeon D chips, which provide cheap low-clocked big cores and integrated NICs for small servers, were requested by Facebook: https://code.facebook.com/posts/1711485769063510/facebook-s-new-front-end-server-design-delivers-on-performance-without-sucking-up-power/

Someone who follows server chips (maybe AnandTech?) called Xeon D's one of Intel's coolest product lines to come out recently. They're also arguably a smart way for Intel to seal off the lower end of the market against approaches with tons of cheap ARM or AMD cores.