Good question [I am the 'Pieter' on that blog post]. There will be a talk at PyCon that covers parts of this. It comes down to two reasons:
1) Performance. We needed something that would consistently work quickly on Instagram's server codebase (currently at several million lines).
2) We are building deeper semantic static analysis tools on top of Pyre. We've built some of these tools for Hack/PHP already, so following the Hack type checker's architecture is the best way for us to achieve this.
> 1) Performance. We needed something that would consistently work quickly on Instagram's server codebase (currently at several million lines).
That's not really an answer to why you didn't work on mypy, at least to an outsider to the decision making process. Are you saying that you discovered it's just not possible to scale mypy (or at least not without extensive work / more work than building your own solution?)
I think (2) is the overriding concern: we're getting really great results with the static analysis tools we've built internally on top of the Hack type checker. Building a similar tool on top of mypy would've required fairly invasive changes; we decided to use the Hack type checker infra instead.
Full disclosure: I worked on the Hack type checker briefly, a long time ago :)
The same reason everyone has a deep learning platform. It’s about developer mindshare and industry dominance rather than honestly thinking they’ll make a better framework starting from scratch rather than improving someone else’s.
Apple actually sort of does have a backend framework: WebObjects. They just seem to have deprecated it in favor of other solutions. Still, I've noticed at least iTunes Connect is still using it. And for what it's worth, Swift is going to have more server related stuff coming to the standard library (https://swift.org/server-apis/), and I wouldn't be surprised if Apple starts adopting this eventually as well as it continues to improve.
