Does Facebook continue to use Hack with HipHop Virtual Machine?<p>Have there been considerations of using some open source langauge instead of internal built one?
Ex-Facebooker here.<p>Hack isn't going away. Ever.<p>It's actually quite pleasant to develop in. The tooling now revolves around VS Code, which I personally don't like. I wish they'd based this on a Jetbrains core.<p>One thing I learned to love with the Hack type system is that nullability is a distinct type (eg you can assign a T to a ?T but not a ?T to a T; ? here means "nullable"). The static type checking is smart enough to figure out here:<p><pre><code> function foo(?Foo $foo): void {
if ($foo is nonnull) {
bar(foo);
}
}
function bar(Foo $foo): void {
...
}
</code></pre>
that the null check changes the type from ?T to T within that block.<p>There's literally no reason to justify the massive investment a complete rewrite would be, like literally none. It's not even close.<p>HHVM and Hack at this point are extremely mature technologies.
All of the “www” code (backend which serves all the web apps and APIs) is Hack. And a lot of that code is generated via internal frameworks like Ent which is a graph abstraction over database access.<p>There doesn’t seem to be any incentive to switch www away from Hack: it wouldn’t reduce the learning curve very much due to all those internal frameworks, and would remove the opportunity to optimize the language for the www codebase.<p>There are open source languages used in the internal backends though (services behind www). Most of it is C++.
Migrating to Hack from PHP was huge undertaking requiring years to conclude, and that almost kept the same syntax and semantics where possible.<p>What would the benefit of spending thousands of engineer years (read: billions of dollars) on a rewrite be? Especially when it would nearly certainly come with a huge performance regression compared to continuing to use HHVM which has come with years of optimization for working especially with Facebook's web codebase.<p>In addition to the need to rewrite a gargantuan codebase and loss of the optimized runtime, it would mean throwing away a huge amount of expertise, tooling, and basically all of the source control history context.<p>There really isn't much to gain.<p>That said, the fraction of Facebook's code that is Hack continues to shrink, thanks to the continued growth of backend services and the clients being written in Hack (before there was server-rendered XHP, but now it's predominantly React).
HHVM is open source and seeing active development with weekly releases: <a href="https://hhvm.com/blog/" rel="nofollow">https://hhvm.com/blog/</a><p>My understanding is they're waiting on the language stabilizing before making a push to open it up to the broader software engineering community.<p>They're still heavily invested in Hack and releasing research papers like <a href="https://engineering.fb.com/2021/03/03/developer-tools/hhvm-jump-start/" rel="nofollow">https://engineering.fb.com/2021/03/03/developer-tools/hhvm-j...</a>.<p>Migrating to another language without an incremental adoption path likely isn't feasible for them
The answer to your first question is yes.<p>Your second question is based on an incorrect premise.
Hack is internally built, but it is also open source:<p><a href="https://github.com/facebook/hhvm" rel="nofollow">https://github.com/facebook/hhvm</a><p>I joined Facebook in 2019 and left this year.
Prior to FB, I worked mostly with python, javascript, and C++.
Even at FB, I worked mainly in python (instagram backend), but spent a lot of time in the Hack codebase.<p>My experience was that FB's Hack + HHVM stack is much easier to work with and felt more productive than any other backend stack I've used. It's important to consider that a huge portion of Facebook's backend is one giant HHVM monorepo (called www). The consistency and uniformity has allowed FB to build lots of tooling and developer productivity on top of this one stack. For example, when you add feature flags, the tooling will automatically create a diff (PR) to remove the feature flag once it has been fully rolled out for a few weeks.<p>There are rough edges and weirdnesses, but HHVM is pretty actively being improved. Old mutable builtins are being (or have been) removed, the type system has gotten better, better error and warning messages all the time. FB is very responsive to data on developer productivity.<p>EDIT:
Another anecdote, when I first joined I was working on both the Instagram python codebase and the Hack API codebase (some of Instagram's APIs are in Hack/HHVM). I constantly wondered why we didn't migrate the Hack code to python, and talked with various people about proposals and potential paths to do the migration for the APIs I worked on.<p>After a few months of working in both codebases, I completely flipped. After witnessing insane bugs and horrible architectural contortions designed to mitigate python performance issues, I wondered why we didn't just migrate the python codebase to Hack. Python (on cpython/cinder) is just not ready for large scale web services, and Hack is a much more productive environment than Java/C++/Rust for backend.<p>Typescript may be an even better option, but has some issues of its own.
Hack is open source.<p>My understanding from a talk back in 2014, is hack was developed because of frustrations with PHP evolution. Honestly I think it may have lit a fire under the PHP developers because php7 had significant speed improvements[4].<p>Talk:<p>"Facebook recently introduced and open-sourced Hack (<a href="https://code.facebook.com/posts/264544830379293/hack-a-new-programming-language-for-hhvm/" rel="nofollow">https://code.facebook.com/posts/264544830379293/hack-a-new-p...</a>), a gradually-typed programming language for HHVM that interoperates seamlessly with PHP. Hack builds the bridge between the dynamically and statically-typed worlds – providing code correctness while maintaining a fast feedback loop. Facebook is committed to working with the community to improve and refine the Hack language, to help interested developers convert to Hack (<a href="https://code.facebook.com/posts/264544830379293/hack-a-new-programming-language-for-hhvm/" rel="nofollow">https://code.facebook.com/posts/264544830379293/hack-a-new-p...</a>), and to narrow the HHVM compatibility gap with PHP5 and popular frameworks."<p><a href="https://www.meetup.com/bostonphp/events/184609542/" rel="nofollow">https://www.meetup.com/bostonphp/events/184609542/</a><p>Slidedeck on Hack (<a href="https://github.com/gabelevi/Boston-PHP-Meetup-Examples/blob/master/Boston%20PHP%20Meetup%20Hack%20Talk.pdf" rel="nofollow">https://github.com/gabelevi/Boston-PHP-Meetup-Examples/blob/...</a>)<p>[4] PHPs response to hack, phpng (php7):
<a href="https://www.sitepoint.com/php-fights-hhvm-zephir-phpng/" rel="nofollow">https://www.sitepoint.com/php-fights-hhvm-zephir-phpng/</a><p><a href="https://news-web.php.net/php.internals/73888" rel="nofollow">https://news-web.php.net/php.internals/73888</a>
Though it is internally-built, Hack is already open source at <a href="https://github.com/facebook/hhvm/" rel="nofollow">https://github.com/facebook/hhvm/</a>.<p>FB uses a pretty wide array of languages internally -- I don't know if they release statistics publicly, but you can filter/search their open-source projects by language at <a href="https://opensource.fb.com/projects/#filter" rel="nofollow">https://opensource.fb.com/projects/#filter</a>.
Over the last few years many contributions from Facebook have made it into PHP mainline 7 & 8, and we've seen respective performance gains.<p>Unsure how extensively they continue to use their PHP to C++ compiler internally.
the problem with php is not php. the problem with php is the troves of terrible wordpress code examples out there that people learn from, modify, and use
I don't work there and don't know anybody who works there, but I do know that they have been using proprietary dialects of PHP for some time. React's JSX was influenced by XHP, and XHP was released in 2010 but apparently was in use for years before then. So from an outsider's perspective, it seems like Facebook has been using proprietary extensions or entirely proprietary languages for over a decade.<p>The fact that Facebook is such a big company means that they can afford to have entire teams working on these proprietary languages, much in the same way Google had the ability to assign full-time engineers to maintaining their internal container infrastructure (Borg, the predecessor to Kubernetes). Because of this, I don't see why they would give up control of some of their stack to people outside their company, who may not share their values. This isn't exclusive to Facebook's PHP developers...they have their own libraries for C/C++, Swift, JavaScript, and much more. It's a big company, the developer tools are going to be a lot bigger than most other workplaces.<p>Again, this is pure speculation. But most of these big companies do the same or a similar thing. Both Apple and Google have invented their own languages, the difference is that Facebook doesn't have an app platform that requires you to use Hack/PHP, thus nobody is going to just pick it up for no reason unless it compels them in other ways (e.g. Go)
Yes www still uses hack. No we probably won't ever migrate to another language for www.<p>That being said, I don't think anything BUT www is written in hack.
Given the big investment, I don't know what they would use instead. They seem to now have a very high level language well suited for the web, but with most of the advantages of a typed-from-the-start language, and great performance for the tasks it's doing. It's hard to think of an existing language that wouldn't be a downgrade in some way (productivity, performance, re-work) for them now.<p>Ironically, the only thing I could see reasonably replacing Hack/HHVM for them is...PHP. Assuming PHP has some success adding all the typing, async, etc, features. They already addressed the performance differences vs Hack/HHVM.<p>Note: All in context of what it's used for, and the investments already made. I get you wouldn't choose Hack/HHVM as a new company.
I don't work at FB but can say with second hand experience that the company is "all in" on Hack/HHVM. The language has diverged far enough from PHP that moving back is simply not feasible.<p>As for "considerations of using some open source language", individual teams are mostly free to use whatever best fits their use case, similar to what you may expect at any company of that size. Pretty much every major language is in use at FB somewhere or the other. And HHVM is also open source.
Are there any large Hack codebases I can explore?<p>I am interested to see how different from straight PHP it is.<p>Does anyone know if FB tracks changes to PHP so Hack is
"up to date"?
At a high level think of Hack as Typescript for PHP. Although they completely replaced some data structures (i.e. arrays) that couldn't be made performant in their PHP implementation.
Just like their customized version of MySQL, Facebook is stuck with Hack. It's too ingrained.
Their customizations to MySQL became very specific to Facebook and they pretty much stopped open sourcing changes. Hack has taken the same path. They will never outsource Hack fully because some of the customization are only applicable to them.
VK has a nice PHP compiler
<a href="https://vkcom.github.io/kphp/various-topics/walk-through-php-kphp-cpp.html" rel="nofollow">https://vkcom.github.io/kphp/various-topics/walk-through-php...</a>
Has anyone used both Hack and the modern React workflow of Typescript and a mixture of client and server-side rendering? Interested to know how they compare