Comment by rafekett | Hacker News Reader

Comment by rafekett | Hacker News Reader

Parent Full thread

you're probably interested in the downsides of HHVM, not Hack. Hack is really just a PHP frontend built on top of HHVM. HHVM is the JIT.

- it runs really well on expensive, FB hardware. there's no consideration given to anything else (performance-wise) in development. that's not to say it's slow, but it works best on 64GB servers with fat SSDs.

- it's a huge moving target when it comes to php5 compatibility -- there are a few intentional inconsistencies and a lot of unintentional ones. fixes for zend incompatibilities have a whack-a-mole effect: the typical patch fixes one inconsistency and introduces a few more.

- bad documentation and bad code quality

- it is open-source, but only in the most superficial sense. it's really an FB internal project, so good luck making any changes that help you but don't help FB

it's still better than zend PHP, and, to be fair, most of the incompatibilities are in cases where zend behaves stupidly. source: i was an HHVM contributor. (edited to space out my ascii list)

I half disagree with the third point - the documentation is certainly lacking (I recently used Redis on an HHVM site, and the adaptor had no documentation that it even existed; just read the source to figure it out), but it's a new-ish, fast-moving project, so that's not too surprising.

The code quality, however, isn't 'bad' by any stretch of the imagination. The FB team managing it is very knowledgeable about PHP internals, and are appropriately strict about determining what zend-compatibility fixes to commit. Their code's overall quite well-written, which makes me care a whole lot less about how poorly it's documented.

depends on what you define as good quality. it's efficient code, but it's sparsely commented, and a style nightmare.

Odd. If I recall correctly, there was even a detailed FB PHP coding style guide in the HHVM Git repo; that was afterwards removed though - I don't know why.

    sparsely commented

I already like the sound of it :)

I'm sorry to hear about your experience contributing to HHVM. Which commit(s) were you talking about? I'd rather stop doing whatever got in your way so others don't have the same experience.

really, the big problem was that the HHVM team didn't use CMake, so there was no concern with how long the build took and it was frequently broken. I had two instances where I spent hours fixing bugs that were fixed internally at FB at the same time, but hadn't been pushed. I know there was an ongoing effort to move completely into the open, but it was frustrating. I don't think these are persistent problems with HHVM, just reasons why the project wasn't really ready for primetime in the OSS world (open academy, specifically).

the fact that no one who doesn't work at FB is allowed to merge code (correct me if I'm wrong) made me feel like I was helping FB more than the OSS community. I get that HHVM is business critical to FB, but if you want it to truly get community support it needs to be spun off from FB.

edit: and I will add that my language was way too harsh. it's not hard to get in a PR provided it doesn't break anything in an FB internal test suite which I can't see (which never was a problem for me, but I could see it being one) and didn't degrade FB performance.

From the github page it looks like external folks are submitting pull requests. It looks like they require external people to sign the CLA, but it doesn't look like it's a case of "good luck making any changes that help you but don't help FB" per your comment.

I've found the same as you - people are getting their PRs when needed. In the earlier days of the project, it may have been true that they were less accepting of any non-critical changes (as they were still getting the core together), but in my experience they're open and eager to get feedback from the public.

my language was too harsh. see my edit in response to ptarjan.

Reply on news.ycombinator.com