from Hacker News

The Future of HHVM

by mwpmaybe on 9/18/17, 6:12 PM with 158 comments

• by TazeTSchnitzel on 9/18/17, 7:05 PM

  Given HHVM is already being dropped from PHP packages because of its lagging compatibility, announcing that they're not targeting PHP compatibility any more might be the nail in the coffin for HHVM (and thus Hack) as a viable “upgrade” from PHP for existing codebases.

  I mean, it's great that Hack will work for new Hack code and existing Hack codebases, but there aren't a lot of those. It makes sense for Facebook — why waste your efforts on maintaining part of your runtime that you don't need? — but I wonder if this will consign HHVM to irrelevance in the long term. Maybe Hack is a compelling platform for new code, but then, why use this obscure proprietary Facebook thing that's a bit better than PHP when you could use any of the numerous other languages out there that are also better than PHP but have much better ecosystems?

  Personally this makes me sad because I wanted to see a standardised, multiple-implementation PHP language. Facebook did, even. They paid someone to write a spec: https://github.com/php/php-langspec

  Maybe someone will write a new PHP implementation to take that idea forward. Or maybe we'll be stuck with Zend forever.

  The future is strange.

• by muglug on 9/18/17, 7:39 PM

  HHVM & Hack solved two big problems that made PHP difficult for Facebook and other large companies with large existing PHP codebases: Speed, and the lack of type checking

  Now the PHP ecosystem is more mature – PHP 7 eliminated the speed differences between HHVM and PHP, and a bunch of static analysis tools find 95% of the bugs that HHVM's typechecker finds.

  It makes sense that this would be an inflection point for the future of HHVM.

  I hope that more features from HHVM make it into PHP core – especially property types and generics – because, whatever FB decides to do with HHVM, PHP is here for the long-haul.

• by rrdharan on 9/18/17, 6:37 PM

  This is fascinating. It's a well-written post and their plan makes sense to me, but I imagine there's a tough choice ahead for framework authors (the Laravels and Drupals of the world) about whether they want to fork their communities, stay with PHP7, or try to target both with the same codebase (in the near term or long term)?

  At any rate at least the fact that the HHVM folks are communicating the strategy effectively and transparently should help everyone involved make reasonable decisions.

• by bepotts on 9/18/17, 6:55 PM

  How is Hack? Has anyone built anything with it and would like to share their thoughts? How's the HHVM community?

  I've always thought that PHP was an underrated language that got a bad rep due to whacky design choices and PHP developers being seen as "less skilled" (a stereotype I know, but it is prominent) than others. Object Oriented PHP and frameworks like Laravel were a nice change of pace in my opinion, and there's plenty of good PHP coders out there if they had the right experience and stuck to a good coding guideline.

  Alas, I confess I stepped away from PHP due the stereotypes against it, but HHVM always seemed promising. I haven't heard much about it over the years though.

  What's the toolchain for HHVM?

• by ryangordon on 9/18/17, 9:14 PM

  Here's the interesting thing about all this; HHVM will always be developed because it's important to Facebook's bottom line and Open Source because it only benefits them to keep it out there and have other people testing it and improving on it.

  Now that they're getting rid of direct PHP support, HHVM is only going to get better. This will unlock a whole host of language improvements that HHVM couldn't otherwise make.

  HHVM is faster relative to PHP now, and it will only get faster with these changes. Typing is an important part of making JITed code fast and unless PHP ever decides to fully add it, it will never have the potential to catch up. This is important to PHP-based companies as they grow and want to optimize on cost and development efficiency.

  Undoubtedly, this split will be painful initially for those of us who are bought into the symbiosis of the HHVM and PHP ecosystem together. How painful it is to split will just be a question of where members of the PHP community want to go (or both). The nice thing is that converting something from PHP to HHVM isn't terribly hard; not anywhere near like converting from PHP to Golang. For HHVM, it's mostly just adding type annotations.

• by sunseb on 9/18/17, 8:44 PM

  I'm excited! :)

  PHP is IMHO the most productive and easiest platform for web development:

  - a request

  - a response

  - templating

  - no shared stated

  And that's it! But the language syntax has so many quirks. So it's cool if Hack redesign the language and make it more beautiful and consistent. Many developers switch to Ruby or Python because these languages are better designed. I think Hack could attract a lot of these developers who want more beauty in the tools they use.

• by ankyth27 on 9/18/17, 7:29 PM

  Parse, react and now this. Why would I now learn any new Facebook tech?

• by maxpert on 9/18/17, 7:24 PM

  I am way less sad about HHVM now (specially after React license debacle). I think Facebook now has opportunity to think about this fork as a fresh take on PHP and maybe make the language awesome both from syntax/performance perspective. I don't think living with a weird hybrid with current language landscape is an option.

• by philippz on 9/19/17, 6:05 AM

  Sad. Facebooks involvement by utilizing PHP and pushing the language by extending it was a good sign for the PHP community. Would have loved to see that they align with PHP7 or even further, push their engineers into improving PHP itself. PHP has such a huge ecosystem. I wouldn't risk to bet on Hacks future.

• by pbiggar on 9/18/17, 9:46 PM

  > Eliminating references. PHP references have unusual semantics, where the function specifies the binding of parameters with no indication at the callsite.

  I feel like I called this one in https://circleci.com/blog/critiquing-facebooks-new-php-spec:

  > This is interesting because they’re changing the definition of the language through a sort of back-channel. They’re allowing breaking changes by effectively deciding that other implementation choices are equally valid.

  > I’ll give you an example, which I’ll get into more below. There’s a little known bug in the Zend engine around copying arrays that contain references. IBM wrote a paper about this bug in 2009. Basically, this bug was necessary in Zend to make copying arrays fast, and IBM figured out a way to do it in a way that was actually correct, for only a 10% performance penalty.

• by dcgudeman on 9/18/17, 8:53 PM

  I wonder what this means for wikipedia? Will they be migrating to a hack only stack now?

• by foxfired on 9/18/17, 10:14 PM

  I think HHVM was equivalent to what jQuery was to JavaScript. jQuery forced JavaScript to be better, and the better JavaScript becomes, the less jQuery is needed.

  So if we get to a point where HHVM is completely irrelevant, it simply means "Mission Accomplished".

• by the_duke on 9/18/17, 7:03 PM

  Has Hack actually gotten meaningful adoption outside of Facebook?

  I never hear about anyone using it...

• by krapp on 9/18/17, 11:17 PM

  Well, this is disappointing. I really like Hack and I was hoping it would take off, but judging from this thread it seems unlikely the language is going anywhere worth following. I guess it's lucky that I only have one project written in it...that I now have to convert back to PHP.

  I'm really going to miss XHP. Native XML support has ruined me for templating frameworks. I never want to write HTML as concatenated strings ever again.

• by tiffanyh on 9/18/17, 6:47 PM

  This is pure syntax sugar but will Hack now clean up the PHP inconsistency with function naming and return values?

  E.g. FunctionName() vs function_name().

  Or

  E.g. return 5x20; vs return "5"x10;

• by thatonechad on 9/19/17, 2:36 PM

  I tried out Hacklang a bit and I really enjoyed it. However I could not get xdebug or any type of debugging to work with it. Also the lack of an editor on the calibre of PHPStorm (atom is not great at all) made me give up. I am just hoping for PHP7 to move in the right direction.

• by crescentfresh on 9/18/17, 7:54 PM

  First I'm hearing of Hack! Didn't realize HHVM had under it's wing two languages.

• by ecesena on 9/19/17, 1:12 AM

  What are the best framework for web dev on top of hack/hhvm? Last time I used PHP I was using yii (yes-it-is). Wondering what framework can someone use today if she has to start from scratch on hack.

• by royge on 9/19/17, 2:45 AM

  If HHVM(Hack) will drop all the inconsistencies and weirdness of PHP in their implementation the better since it's no longer be compatible with PHP anyway.

• by fiatjaf on 9/18/17, 10:32 PM

  [removed language flame war]

• by ohdrat on 9/18/17, 7:38 PM

  Guess I'll mosey on back to OCaml then...

• by merb on 9/18/17, 8:07 PM

  I wonder why they just don't deprecate HHVM altogether and maybe create a HACK version on top of GraalVM. This would probably be way more performant and probably might be better for integration into other systems.

• by memracom on 9/18/17, 10:15 PM

  I think that these changes mean the death knell for PHP in any version, for small companies. There is still a place for Hack or PHP7 in very large operations, but startups, and businesses that run at smaller scale, really should walk away from PHP entirely as soon as possible.

  Two reasonable directions to choose are Python Three with a framework like Flask (lighweight) or Django (heavy duty). Or go to the JVM with something like Grails framework (heavy duty) on the Groovy language. Ratpack is a lightweight framework for Groovy and there is also an interesting option to use Vaadin 8 which lets you put your GUI code into the main app rather than writing separate Javascript code.

  When making your decision, be sure to consider the huge JVM ecosystem that integrates quite easily with Groovy including development tools like Jenkins and SOAPUI that can be scripted with Groovy. And the Python side also has a fairly extensive ecosystem of libraries as well.

  The skill level of Python and Java/Groovy developers tends to be higher than PHP which has always attracted people who would learn just enought to get by.

  The software dev community has gone through an explosion of diversity in the past 2 decades and that has enabled a lot of experimentation with new ways of doing this. There is a lot of good in this. But now we are in a period of contraction. Some of this is manifested in the spread of functional capabilities via libraries such as reactive extensions and functional features being added to languages like Java and Javascript. Another manifestation is the fading of PERL from prominence, and this is now happening to PHP as well as Ruby.

  This is evolution. Embrace it or face your personal extinction as a software developer.