Comment by jaytaylor | Hacker News Reader

Comment by jaytaylor | Hacker News Reader

Parent Full thread

Agreed, Hack appears to be a move to fork into a PHP-esque language that FB engineering feels will be better for their software lifecycle goals and needs:

- 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."

I.e. Why would you use a language with few open source libraries over a very similar language with exponentially more?

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!"

May not be that many Marke's out there.

Laravel, to name one, broke HHVM compatibility a while ago (or perhaps more accurately no longer included it as a target platform). In my experience, trying it out every year or so with an existing project, there were always compatibility issues with HHVM, most often in C modules but also a few odd corner cases in pure PHP.

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).

My company has 2 big projects running on HHVM.

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.

> Why would you use a language with few open source libraries over a very similar language with exponentially more?

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.

I see what you're saying, and question the assumption that a higher percentage of Hack libraries will be high quality.

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.

> Languages with fewer people writing code in them will have more opportunity for abandonment and neglect.

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.

Oh, there are plenty of people like this:

    Bob:
    "I'll do it in Hack because I long
    Time ago swore off PHP, and Hack
    sounds like an interesting language."

Agreed. I think there will be some genuine interest in a PHP-like language that drops some of the cruft and adds a few modern tweaks. Plus, having a large company that uses it everyday will help.

Reply on news.ycombinator.com