Diverging from PHP was a good move as PHP 7 has largely caught up with HHVM in terms of speed. That's really neat that Facebook invented their own language to meet their needs. Will have to mess around with it further sometime.
- Handle numeric boundary cases in a more intuitive way.
- Is Typed.
- Replace reference parameters in favor of a new keyword, "inout".
- Change package management and testing framework to be less annoying and more streamlined. This will be yarn (from npm, as in the one written in Javascript), and their own custom flavor of testing framework, hh-test, to replace PHPUnit.
I wonder how many existing open-source PHP projects will remain compatible with HHVM? The post seems to indicate compatibility will not be a priority and that it's a fully breaking change. If this is true, it seems the "empty cocktail room" effect will be a major challenge and problem.
Jane:
"Hey, you can do this project in PHP or Hack."
Alice:
"Okay, I'll go with PHP because there's
already a shitton of good libraries that might
be useful to me or that I already know."
When I want types, I can already use Go, Java, or even Typescript, just to name a few terrific options. These days it seems like a no-brainer to me.
The effort seems like a lot of trouble to go to just to shave off some annoyances / "rogue hairs".
Curious if there's an angle I'm missing.
One argument for making it an open-source language / project and trying to eventually grow it could be so FB can more easily hire folks who are already know the Hack language.
Marke:
"I'll do it in Hack because my only dream is
to work at Facebook!"
Fewer unvetted libraries from a security and code quality angle.
Not saying it's good from a general engineering angle, but in an environment like Facebook which can afford to over-engineer, the third party dependency risk mitigation is a good side effect.
But my argument here is a pretty polarizing one as it implies security-through-obscurity. I promise I'm not; I'm just pragmatic about how many abandoned or poorly maintained open source libraries end up being relied-upon regardless of how that challenge is solved-for in CI/CD.
You raise a valid concern, and also this issue cuts both ways.
The FB libs have a good chance of being well-maintained. This will be true for PHP and Hack, alike.
The rate of library neglect will be approximately equal between the two languages.
The real question is: What does the data say about project / library neglect? I'd guess neglect rates may correspond inversely with language popularity.
Languages with fewer people writing code in them will have more opportunity for abandonment and neglect.
Who wrote and is relying on the library seems like a better candidate for predictor of proper future maintenance compared to language flavor.
This would be true in the public space.
I don't know if it holds when the language is internal to the company and people are incentivized effectively to keep them up to date.
As far as I know once PHP 7 came out HHVM fell much further behind (as far as the PHP language goes, no idea how Hack is doing).
Most of the library we used to start our projects (symfony, mongodb to name the biggest) dropped the HHVM compatibility in the middle of development, I can tell you this was a good lesson for me: never take a technology where big vendors drop compatibility.
Having to debug a production error with an HHVM library (which support was dropped), find a fix and then seing it was fixed in the official PHP library 6 months ago hurt a lot...
Another point not in favor of HHVM, it's maintained by them, the roadmap is only known to them and the number of HHVM alternatives to big libraries is near 0.
We are gradually moving away from HHVM (and PHP in general) in favor of NodeJS and TypeScript.
Bob:
"I'll do it in Hack because I long
Time ago swore off PHP, and Hack
sounds like an interesting language."