30 ms·

The Future of HHVM

265 points by mwpmaybe 9y ago

crescentfresh 9y ago
First I'm hearing of Hack! Didn't realize HHVM had under it's wing two languages.
merb 9y ago
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.
rrdharan 9y ago
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.
- wolco 9y ago
  I can't imagine any large framework spliting or supporting this in place of php 7. This is more of a new beginning with new hack frameworks.
- HugoDaniel 9y ago
  That and PATENTS: https://github.com/facebook/hhvm/blob/master/hphp/hack/PATENTS https://github.com/facebook/hhvm/blob/master/hphp/hack/PATEN...
  - zimbatm 9y ago
    If Facebook had released the code under BSD then nobody would have complained. But this basically gives a BSD plus patent grant, and reverts to BSD if there are any patent litigations. And now people are complaining.
    - deleted 9y ago
      [deleted]
    - s73ver_ 9y ago
      Because it is them saying, "We can take all of your patents, but if you sue us for it, then you don't get to use this."
      - jbergens 9y ago
        IANAL. I think that is a common misunderstanding of the clause. If you sue them for react patents you can still use HHVM, or vice versa. https://medium.com/@dwalsh.sdlr/react-facebook-and-the-revokable-patent-license-why-its-a-paper-25c40c50b562 https://medium.com/@dwalsh.sdlr/react-facebook-and-the-revok...
      - abritinthebay 9y ago
        Not even close to true
    - deleted 9y ago
      [deleted]
  - cstrasen 9y ago
    Woah. Its bad enough with react which many did not expect. Now also this BS. No thanks really.
  - dingdingdang 9y ago
    Exactly like React - means the language will be abandoned by wider community. The Facebook peeps are gradually building themselves into corporate self-invented mono-culture.
    - m00x 9y ago
      I'd like to see any concrete numbers on this. I'm seeing React getting stronger and stronger in my area, and patent worries are mostly accepted as crazy hypotheticals.
      - georgebarnett 9y ago
        Do you work with any lawyers in your company or peer group? I doubt they view the patent issue as "crazy hypotheticals".
        abritinthebay 9y ago
        The only lawyers I know with software patent experience consider the fuss absolutely rediculous. It gives you more rights. Full stop, end of story.
      - dreamfactored 9y ago
        Wordpress are just starting what could easily be a multi-year rewrite as a result and Drupal has specifically excluded React from evaluation - both on the basis of the patent issues
        true_religion 9y ago
        True, but PHP development has always been split from the rest of the web-dev community. React has managed to bring together people in C#, Python, Ruby, and Erlang to name a few languages... who all previously used different frameworks, or just jQuery.
        sneak 9y ago
        Yes, it is clearly in wordpress' best interests to spend all that time and money to preserve their very important right to sue facebook for violating wordpress' software patents in the future. /sarcasm
- fredemmott 9y ago
  Thanks; we don't feel that the framework authors have to make a choice here: - short-term, those of us working on HHVM - not the frameworks - need to make sure that HHVM can run the frameworks that Hack developers require - long-term, we expect Hack and HHVM to continue to diverge from PHP; it's unlikely that targeting both HHVM and PHP will be a practical long-term strategy
- chx 9y ago
  If I still were a Drupal core developer (and I was the #1 core contributor for 5, 6 and #4 for 7 and still #10 for 8 though I regret that) I would tell you there's no tough choice here, I would target PHP 7.x and forget the rest. Currently, others steers the core and they struggle mightily with just the transition to PHP 7.0 requirement. Check the issue queue. I filed https://www.drupal.org/node/2605226 https://www.drupal.org/node/2605226 in 2015 fall but it was voted down, the current open issue is https://www.drupal.org/node/2842431 https://www.drupal.org/node/2842431 HHVM is way too niche to bother with it, sorry.
- TazeTSchnitzel 9y ago
  PHP packages are dropping HHVM support right and left right now because HHVM has already been… lagging in its PHP support. So there's not really a choice to make. HHVM was tiny anyway.
- dabernathy89 9y ago
  Laravel dropped HHVM support a year ago, and i'm sure many other CMS's / frameworks have either followed suit (if they ever supported it) or will soon.
tiffanyh 9y ago
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;
- fredemmott 9y ago
  Function naming: We're moving towards functions_like_this(), instanceAndStaticMethodsLikeThis(), and async functions like foo_async() and methods like fooAsync(). We're unlikely to change the PHP builtins, but we're fairly likely to build replacements - for example, Hack Arrays are best used with https://github.com/hhvm/hsl https://github.com/hhvm/hsl instead of the PHP array functions, and this also provides replacements for common string operations that are consistent and fit well with the Hack type system (e.g. nullable or throw an exception instead of falseable). For return values, I'm not sure exactly what you mean - could you give a full example? If I take your example verbatim, it's a syntax error in both Hack and PHP - if I go for "5"*10, it's a Hack error (https://gist.github.com/fredemmott/90c5f8eca17d1d4e1204f0085cc120f5 https://gist.github.com/fredemmott/90c5f8eca17d1d4e1204f0085...)
  - the_duke 9y ago
    That naming convention seems quite confusing. Why not make all functions (standalone and methods) either snake or camel case?
    - takeda 9y ago
      I hope the previous post was a joke, because it felt like one. Edit: "We're moving towards functions_like_this(), instanceAndStaticMethodsLikeThis(), and async functions like foo_async() and methods like fooAsync()." C'mon. That doesn't sound like much improvement compared to the original PHP.
  - tiffanyh 9y ago
    From the blog post: HHVM will not aim to target PHP7 If you don't plan to support PHP5 anymore and HHVM is not targeted at PHP7 ... then my ask is to just make a better language and drop ALL of PHP baggage. When you say: We're unlikely to change the PHP builtins That concerns me. Because why even break support from PHP7 if you don't plan to change (fix) the builtins?
bepotts 9y ago
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?
- hobofan 9y ago
  I have worked on a somewhat large-ish backend that was built with Hack. In the end, we dropped it in favor of PHP7, due to all the small incompatibilities it had, and all the non-standard things we had to do to use it. With PHP7 the performance difference was negligible (our original reason for choosing it), and the type annotations of PHP7 were good enough for us. With switching, we were also able to use phan[0] and other tools that helped us write better PHP code that were previously unusable due to Hack. [0]: https://github.com/phan/phan https://github.com/phan/phan
- thinkindie 9y ago
  Laravel is probably not the best example in terms of improving PHP landscape in terms of code/architecture quality: Symfony is way more prominent in that. It's not a case that Laravel is using many components from Symfony.
  - akoncius 9y ago
    it is weird for me why Laravel is so popular now given that as far as I've read documentation, a lot of it is written in static class calls, which is opposite of OOP and all good pratices coming with OOP.. I understand that it's kind of rails and gives short-term productivity, but if you have complex project, it will become an issue if majority of project code is spaghetti code without DI, IoC and so on.
the_duke 9y ago
Has Hack actually gotten meaningful adoption outside of Facebook? I never hear about anyone using it...
- muglug 9y ago
  Slack does, and some (all?) of MediaWiki. Outside of that, I don't think it's enjoyed the sort of penetration of other OS projects from FB
  - connorshea 9y ago
    I don't think MediaWiki uses Hack, only PHP with HHVM (though I could be wrong).
    - mch82 9y ago
      Discussion on this topic a couple comments away on this parent post... still unanswered. https://news.ycombinator.com/item?id=15279456 https://news.ycombinator.com/item?id=15279456
  - smsm42 9y ago
    MediaWiki doesn't use Hack. Wikimedia Foundation servers (which run Wikipedias and other sites) do use HHVM, but the code is 100% PHP-compatible and still runs fine on standard PHP.
    - appleflaxen 9y ago
      this is a really helpful distinction that isn't made on the other comments that address HHVM and MW; thank you!
- deleted 9y ago
  [deleted]
TazeTSchnitzel 9y ago
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 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.
- muglug 9y ago
  It makes me sad that, as a Mac-based developer, installing & updating HHVM takes half an hour (via Homebrew). I imagine that has taken the wind out of many people's sails, when contemplating migrating/updating codebases to HHVM's (superior) syntax.
  - fredemmott 9y ago
    Sorry, I know this is a pain; I'm hoping to fix it by the end of the year (along with bringing back nightly debs, and supporting more recent versions of debian/ubuntu). For homebrew build times, there's https://github.com/hhvm/homebrew-hhvm/issues/5 https://github.com/hhvm/homebrew-hhvm/issues/5 In the short term, docker works rather nicely.
  - deleted 9y ago
    [deleted]
- Twirrim 9y ago
  It may be just my lack of familiarity with the PHP / Zend, but it seems like one of the most significant things that HHVM achieved was a wake-up call to Zend. It seemed like they suddenly started putting some serious effort in to PHP7's runtime, and publicising what they were doing. A bit of a wake-up call to a language that was languishing for performance.
maxpert 9y ago
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.
ankyth27 9y ago
Parse, react and now this. Why would I now learn any new Facebook tech?
- cdelsolar 9y ago
  what happened with React?
  - hibbelig 9y ago
    BSD+Patents license.
ohdrat 9y ago
Guess I'll mosey on back to OCaml then...
muglug 9y ago
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.
- jimktrains2 9y ago
  > 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 At what point do you stop using the hammer to put in a screw and just use a screwdriver?
  - muglug 9y ago
    When the cost of buying screwdrivers for your entire workforce would likely bankrupt the company.
    - jimktrains2 9y ago
      I'm not sure what you're analogy is here. You wouldn't switch every nail to a screw in the same moment.
      - muglug 9y ago
        Right, but you're still investing time in doing that switch. No matter which way you cut it, you're still replacing every single nail. "We'll just update as we go", you say. That's fine, but it means that some parts of the house – normally the oldest and most integral to the entire structure - will use nails for years to come. And your developers will need to be trained in both hammers and screwdrivers to be able to work on the house in totality.
sunseb 9y ago
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.
- dna_polymerase 9y ago
  Oh boy they really got you! Have a look at Python & Flask! There is nothing easier than that!
  - geofft 9y ago
    Flask is really good (and my preferred web framework, and full disclosure, I have forgotten how to write PHP), but it fails very badly at "no shared state," and depending on what GP meant by "a request" / "a response", it fails at that too. A Flask process handles an indefinite number of requests and responses; the built-in server handles them serially, and doing otherwise brings in either threads (and shared state) or multiple processes. The Slack article posted elsewhere in these comments https://slack.engineering/taking-php-seriously-cf7a60065329 https://slack.engineering/taking-php-seriously-cf7a60065329 has some excellent arguments about why PHP's approach is different in interesting ways.
  - sunseb 9y ago
    I have worked with Python/Flask, and I even built my own micro-framework on top of Ruby/Rack. It was nice, but I am far more productive with PHP, the workflow feels more natural than a cgi-like stack.
  - icelancer 9y ago
    >>Have a look at Python & Flask! There is nothing easier than that! What? PHP is significantly easier to roll out for your beginner/intermediate junior developer on a VPS. There isn't any comparison. This comes from someone who leans on Python hard for ML work / scraping / signal processing (what it was born to do) and PHP for web development (what IT was born to do).
dcgudeman 9y ago
I wonder what this means for wikipedia? Will they be migrating to a hack only stack now?
- mch82 9y ago
  Very interested to find out if anyone has an answer
- zeitg3ist 9y ago
  MediaWiki runs on more than 25k websites [1] other than Wikipedia, so I don't see them switching to Hack only. Also, I run a pretty big MediaWiki site and the last time I tried moving everything to HHVM (~6 months ago, I think) stuff appeared to be working initially but randomly broke from time to time (probably because of Scribunto or some other extension; couldn't manage to pinpoint the exact reason). PHP 7 didn't give me any problem at all; it's fast enough (way faster than PHP 5) and most pages are served by the Redis cache anyway. I suspect that Wikipedia will consider a move back to PHP, they're moving the most expensive logic to Lua modules anyway... [1] https://wikiapiary.com/wiki/Main_Page https://wikiapiary.com/wiki/Main_Page
- MrsRobot 9y ago
  Check out this: https://lists.wikimedia.org/pipermail/wikitech-l/2017-September/088784.html https://lists.wikimedia.org/pipermail/wikitech-l/2017-Septem...
ryangordon 9y ago
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.
- nkozyra 9y ago
  > HHVM is faster relative to PHP now While this is probably still true[1], it's certainly less of a concern now than it was with 5.x. Would (often negligible) performance boosts be enough for someone with a 5.x PHP codebase to choose Hack over PHP 7.x? I can't see that for most cases. https://kinsta.com/blog/the-definitive-php-7-final-version-hhvm-benchmark/ https://kinsta.com/blog/the-definitive-php-7-final-version-h...
pbiggar 9y ago
> 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 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.
- fredemmott 9y ago
  You'll also see a few of these on http://php.net/manual/en/migration70.incompatible.php http://php.net/manual/en/migration70.incompatible.php :p
- smsm42 9y ago
  I get why they want to get rid of references. If I would be designing PHP from scratch, that's probably the first thing I'd do - most hard to fix bugs in the engine and most security woes of features such as unserialize() stem from references. Unfortunately, TONS of code uses them, and there are some data structure things that would not work without it unless alternative solution is provided. So it could not happen in PHP. But it'd be interesting to see how it works for Hack.
  - fredemmott 9y ago
    we're currently leaning towards out/inout parameters, with copy semantics, not byref (and in most cases, we'll probably be able to optimize away the copy); not certain yet though.
    - smsm42 9y ago
      Would be nice to hear what comes out of it and how it works!
foxfired 9y ago
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".
- deleted 9y ago
  [deleted]
- VeejayRampay 9y ago
  In terms of language, jQuery didn't innovate in anything though. It was a great framework mind you, but there's nothing special about it that influenced the choices in design for the more recent versions of JS.
  - Kiro 9y ago
    Not even querySelector?
    - VeejayRampay 9y ago
      I think querySelector and querySelectorAll are simply more generic versions of the traditional approach of using getElementById and getElementsByTagName, but it's possible that the greater versatility of $ influenced the later design of querySelector, indeed. Then again, it was not a jab at jQuery, which proved to be a fantastic tool for a decade in the field of web development.
- wolco 9y ago
  More like coffeescript and es6.
memracom 9y ago
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.
- muglug 9y ago
  > This is evolution. Embrace it or face your personal extinction as a software developer. Woah there Mr Hyperbole. The reason PHP is still in use, and not dead or dying, is that it's one of the simplest languages to write server-side code in. That means it's remarkably easy to hack something together quickly, with no compilation step to get in the way. Unless that changes in a drastic fashion, projects will continue to get started in PHP, and PHP's user base will continue to grow, and (hopefully) the language will continue to improve to accommodate that growth.
- segmondy 9y ago
  If you believe this, then you are very bad at predicting the future. I'm very bad at that too. But I can assure you, "better languages" don't win the war. PHP has a lot of software out there and what's going to have it leading HHVM. You will have the "cutting edge" folks give HHVM a shot, but all the practical folks don't care. The only way HHVM will have a chance will be to be 100% backwards compatible.
fiatjaf 9y ago
[removed language flame war]
- grzm 9y ago
  There are plenty of places where you can view arguments for and against PHP alone and in comparison to Python and Ruby on the internet. This submission is specifically about HHVM. Asking people to justify the use of PHP in such a context is just inviting a language flame war. Please don't.
- segmondy 9y ago
  Faster than Python and Ruby. PHP7 is actually a better OOP language than Python is. PHP is much easier to get started in and find "talent" for, tons of PHP developers out there. A lot of money has been made with PHP, the only reason many companies switched from PHP is that the developers wanted to "feel grown up" and switched to something else.
krapp 9y ago
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.
- emodendroket 9y ago
  There are a lot of choices to not write HTML by concatenating strings though.
  - krapp 9y ago
    Are there in PHP, though?
    - grzm 9y ago
      PHP does have a history of making this more explicit, given its origins as a templating language. If you go down far enough, isn't all HTML rendering string concatenation? There are plenty of libraries that handle this in many languages, including PHP.
      - krapp 9y ago
        I'm just annoyed that PHP doesn't handle HTML tags natively as their own distinct entities. Not having to quote HTML as strings or switch into and out the rendering context with PHP tags makes templates a lot easier to reason about and cleaner. With that, you can natively get features like auto-escaping, HTML tag validation, extending or creating custom tags, template inheretance, all of which you can do in PHP but only if you include the overhead of a framework.
        grzm 9y ago
        > I'm just annoyed that PHP doesn't handle HTML tags natively as their own distinct entities. I'm interested in things like this as well. Can you provide an example of what you're thinking of? Something like JSX? Other data structures that are transformed into HTML by a library? The latter seems to be counter to your argument about requiring the use of some framework or library, but I can't think of any alternatives off the top of my head.
ecesena 9y ago
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.
- fredemmott 9y ago
  https://github.com/hhvm/hack-router/ https://github.com/hhvm/hack-router/ and https://github.com/hhvm/hack-router-codegen/ https://github.com/hhvm/hack-router-codegen/ power docs.hhvm.com and some of our other users; they do have problems such as extremely lacking documentation, which I'm going to be addressing soon. This is definitely an area we're planning on working on - and this post is meant to be announcing the start of this work, not that it's ready :)
royge 9y ago
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.
- rurban 9y ago
  That's the plan. Break the old nonsense, like the one they mentioned: refs and refcount. Everybody should switch to Hack, it's a much better and safer language.
philippz 9y ago
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.
- COil 9y ago
  Agree, that's a pity. Instead of having one top language, we will have 2 "now-incompatible-great-languages".
thatonechad 9y ago
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.

265 points by mwpmaybe 9y ago

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

merb 9y ago

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.

rrdharan 9y ago

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.

wolco 9y ago
I can't imagine any large framework spliting or supporting this in place of php 7. This is more of a new beginning with new hack frameworks.
HugoDaniel 9y ago
That and PATENTS: https://github.com/facebook/hhvm/blob/master/hphp/hack/PATENTS https://github.com/facebook/hhvm/blob/master/hphp/hack/PATEN...
- zimbatm 9y ago
  If Facebook had released the code under BSD then nobody would have complained. But this basically gives a BSD plus patent grant, and reverts to BSD if there are any patent litigations. And now people are complaining.
  - deleted 9y ago
    [deleted]
  - s73ver_ 9y ago
    Because it is them saying, "We can take all of your patents, but if you sue us for it, then you don't get to use this."
    - jbergens 9y ago
      IANAL. I think that is a common misunderstanding of the clause. If you sue them for react patents you can still use HHVM, or vice versa. https://medium.com/@dwalsh.sdlr/react-facebook-and-the-revokable-patent-license-why-its-a-paper-25c40c50b562 https://medium.com/@dwalsh.sdlr/react-facebook-and-the-revok...
    - abritinthebay 9y ago
      Not even close to true
  - deleted 9y ago
    [deleted]
- cstrasen 9y ago
  Woah. Its bad enough with react which many did not expect. Now also this BS. No thanks really.
- dingdingdang 9y ago
  Exactly like React - means the language will be abandoned by wider community. The Facebook peeps are gradually building themselves into corporate self-invented mono-culture.
  - m00x 9y ago
    I'd like to see any concrete numbers on this. I'm seeing React getting stronger and stronger in my area, and patent worries are mostly accepted as crazy hypotheticals.
    - georgebarnett 9y ago
      Do you work with any lawyers in your company or peer group? I doubt they view the patent issue as "crazy hypotheticals".
      - abritinthebay 9y ago
        The only lawyers I know with software patent experience consider the fuss absolutely rediculous. It gives you more rights. Full stop, end of story.
    - dreamfactored 9y ago
      Wordpress are just starting what could easily be a multi-year rewrite as a result and Drupal has specifically excluded React from evaluation - both on the basis of the patent issues
      - true_religion 9y ago
        True, but PHP development has always been split from the rest of the web-dev community. React has managed to bring together people in C#, Python, Ruby, and Erlang to name a few languages... who all previously used different frameworks, or just jQuery.
      - sneak 9y ago
        Yes, it is clearly in wordpress' best interests to spend all that time and money to preserve their very important right to sue facebook for violating wordpress' software patents in the future. /sarcasm
fredemmott 9y ago
Thanks; we don't feel that the framework authors have to make a choice here: - short-term, those of us working on HHVM - not the frameworks - need to make sure that HHVM can run the frameworks that Hack developers require - long-term, we expect Hack and HHVM to continue to diverge from PHP; it's unlikely that targeting both HHVM and PHP will be a practical long-term strategy
chx 9y ago
If I still were a Drupal core developer (and I was the #1 core contributor for 5, 6 and #4 for 7 and still #10 for 8 though I regret that) I would tell you there's no tough choice here, I would target PHP 7.x and forget the rest. Currently, others steers the core and they struggle mightily with just the transition to PHP 7.0 requirement. Check the issue queue. I filed https://www.drupal.org/node/2605226 https://www.drupal.org/node/2605226 in 2015 fall but it was voted down, the current open issue is https://www.drupal.org/node/2842431 https://www.drupal.org/node/2842431 HHVM is way too niche to bother with it, sorry.
TazeTSchnitzel 9y ago
PHP packages are dropping HHVM support right and left right now because HHVM has already been… lagging in its PHP support. So there's not really a choice to make. HHVM was tiny anyway.
dabernathy89 9y ago
Laravel dropped HHVM support a year ago, and i'm sure many other CMS's / frameworks have either followed suit (if they ever supported it) or will soon.

tiffanyh 9y ago

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;

fredemmott 9y ago
Function naming: We're moving towards functions_like_this(), instanceAndStaticMethodsLikeThis(), and async functions like foo_async() and methods like fooAsync(). We're unlikely to change the PHP builtins, but we're fairly likely to build replacements - for example, Hack Arrays are best used with https://github.com/hhvm/hsl https://github.com/hhvm/hsl instead of the PHP array functions, and this also provides replacements for common string operations that are consistent and fit well with the Hack type system (e.g. nullable or throw an exception instead of falseable). For return values, I'm not sure exactly what you mean - could you give a full example? If I take your example verbatim, it's a syntax error in both Hack and PHP - if I go for "5"*10, it's a Hack error (https://gist.github.com/fredemmott/90c5f8eca17d1d4e1204f0085cc120f5 https://gist.github.com/fredemmott/90c5f8eca17d1d4e1204f0085...)
- the_duke 9y ago
  That naming convention seems quite confusing. Why not make all functions (standalone and methods) either snake or camel case?
  - takeda 9y ago
    I hope the previous post was a joke, because it felt like one. Edit: "We're moving towards functions_like_this(), instanceAndStaticMethodsLikeThis(), and async functions like foo_async() and methods like fooAsync()." C'mon. That doesn't sound like much improvement compared to the original PHP.
- tiffanyh 9y ago
  From the blog post: HHVM will not aim to target PHP7 If you don't plan to support PHP5 anymore and HHVM is not targeted at PHP7 ... then my ask is to just make a better language and drop ALL of PHP baggage. When you say: We're unlikely to change the PHP builtins That concerns me. Because why even break support from PHP7 if you don't plan to change (fix) the builtins?

bepotts 9y ago

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?

hobofan 9y ago
I have worked on a somewhat large-ish backend that was built with Hack. In the end, we dropped it in favor of PHP7, due to all the small incompatibilities it had, and all the non-standard things we had to do to use it. With PHP7 the performance difference was negligible (our original reason for choosing it), and the type annotations of PHP7 were good enough for us. With switching, we were also able to use phan[0] and other tools that helped us write better PHP code that were previously unusable due to Hack. [0]: https://github.com/phan/phan https://github.com/phan/phan
thinkindie 9y ago
Laravel is probably not the best example in terms of improving PHP landscape in terms of code/architecture quality: Symfony is way more prominent in that. It's not a case that Laravel is using many components from Symfony.
- akoncius 9y ago
  it is weird for me why Laravel is so popular now given that as far as I've read documentation, a lot of it is written in static class calls, which is opposite of OOP and all good pratices coming with OOP.. I understand that it's kind of rails and gives short-term productivity, but if you have complex project, it will become an issue if majority of project code is spaghetti code without DI, IoC and so on.

the_duke 9y ago

Has Hack actually gotten meaningful adoption outside of Facebook? I never hear about anyone using it...

muglug 9y ago
Slack does, and some (all?) of MediaWiki. Outside of that, I don't think it's enjoyed the sort of penetration of other OS projects from FB
- connorshea 9y ago
  I don't think MediaWiki uses Hack, only PHP with HHVM (though I could be wrong).
  - mch82 9y ago
    Discussion on this topic a couple comments away on this parent post... still unanswered. https://news.ycombinator.com/item?id=15279456 https://news.ycombinator.com/item?id=15279456
- smsm42 9y ago
  MediaWiki doesn't use Hack. Wikimedia Foundation servers (which run Wikipedias and other sites) do use HHVM, but the code is 100% PHP-compatible and still runs fine on standard PHP.
  - appleflaxen 9y ago
    this is a really helpful distinction that isn't made on the other comments that address HHVM and MW; thank you!
deleted 9y ago
[deleted]

TazeTSchnitzel 9y ago

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

muglug 9y ago
It makes me sad that, as a Mac-based developer, installing & updating HHVM takes half an hour (via Homebrew). I imagine that has taken the wind out of many people's sails, when contemplating migrating/updating codebases to HHVM's (superior) syntax.
- fredemmott 9y ago
  Sorry, I know this is a pain; I'm hoping to fix it by the end of the year (along with bringing back nightly debs, and supporting more recent versions of debian/ubuntu). For homebrew build times, there's https://github.com/hhvm/homebrew-hhvm/issues/5 https://github.com/hhvm/homebrew-hhvm/issues/5 In the short term, docker works rather nicely.
- deleted 9y ago
  [deleted]
Twirrim 9y ago
It may be just my lack of familiarity with the PHP / Zend, but it seems like one of the most significant things that HHVM achieved was a wake-up call to Zend. It seemed like they suddenly started putting some serious effort in to PHP7's runtime, and publicising what they were doing. A bit of a wake-up call to a language that was languishing for performance.

maxpert 9y ago

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.

ankyth27 9y ago

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

cdelsolar 9y ago
what happened with React?
- hibbelig 9y ago
  BSD+Patents license.

ohdrat 9y ago

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

muglug 9y ago

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.

jimktrains2 9y ago
> 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 At what point do you stop using the hammer to put in a screw and just use a screwdriver?
- muglug 9y ago
  When the cost of buying screwdrivers for your entire workforce would likely bankrupt the company.
  - jimktrains2 9y ago
    I'm not sure what you're analogy is here. You wouldn't switch every nail to a screw in the same moment.
    - muglug 9y ago
      Right, but you're still investing time in doing that switch. No matter which way you cut it, you're still replacing every single nail. "We'll just update as we go", you say. That's fine, but it means that some parts of the house – normally the oldest and most integral to the entire structure - will use nails for years to come. And your developers will need to be trained in both hammers and screwdrivers to be able to work on the house in totality.

sunseb 9y ago

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.

dna_polymerase 9y ago
Oh boy they really got you! Have a look at Python & Flask! There is nothing easier than that!
- geofft 9y ago
  Flask is really good (and my preferred web framework, and full disclosure, I have forgotten how to write PHP), but it fails very badly at "no shared state," and depending on what GP meant by "a request" / "a response", it fails at that too. A Flask process handles an indefinite number of requests and responses; the built-in server handles them serially, and doing otherwise brings in either threads (and shared state) or multiple processes. The Slack article posted elsewhere in these comments https://slack.engineering/taking-php-seriously-cf7a60065329 https://slack.engineering/taking-php-seriously-cf7a60065329 has some excellent arguments about why PHP's approach is different in interesting ways.
- sunseb 9y ago
  I have worked with Python/Flask, and I even built my own micro-framework on top of Ruby/Rack. It was nice, but I am far more productive with PHP, the workflow feels more natural than a cgi-like stack.
- icelancer 9y ago
  >>Have a look at Python & Flask! There is nothing easier than that! What? PHP is significantly easier to roll out for your beginner/intermediate junior developer on a VPS. There isn't any comparison. This comes from someone who leans on Python hard for ML work / scraping / signal processing (what it was born to do) and PHP for web development (what IT was born to do).

dcgudeman 9y ago

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

mch82 9y ago
Very interested to find out if anyone has an answer
zeitg3ist 9y ago
MediaWiki runs on more than 25k websites [1] other than Wikipedia, so I don't see them switching to Hack only. Also, I run a pretty big MediaWiki site and the last time I tried moving everything to HHVM (~6 months ago, I think) stuff appeared to be working initially but randomly broke from time to time (probably because of Scribunto or some other extension; couldn't manage to pinpoint the exact reason). PHP 7 didn't give me any problem at all; it's fast enough (way faster than PHP 5) and most pages are served by the Redis cache anyway. I suspect that Wikipedia will consider a move back to PHP, they're moving the most expensive logic to Lua modules anyway... [1] https://wikiapiary.com/wiki/Main_Page https://wikiapiary.com/wiki/Main_Page
MrsRobot 9y ago
Check out this: https://lists.wikimedia.org/pipermail/wikitech-l/2017-September/088784.html https://lists.wikimedia.org/pipermail/wikitech-l/2017-Septem...

ryangordon 9y ago

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.

nkozyra 9y ago
> HHVM is faster relative to PHP now While this is probably still true[1], it's certainly less of a concern now than it was with 5.x. Would (often negligible) performance boosts be enough for someone with a 5.x PHP codebase to choose Hack over PHP 7.x? I can't see that for most cases. https://kinsta.com/blog/the-definitive-php-7-final-version-hhvm-benchmark/ https://kinsta.com/blog/the-definitive-php-7-final-version-h...

pbiggar 9y ago

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

fredemmott 9y ago
You'll also see a few of these on http://php.net/manual/en/migration70.incompatible.php http://php.net/manual/en/migration70.incompatible.php :p
smsm42 9y ago
I get why they want to get rid of references. If I would be designing PHP from scratch, that's probably the first thing I'd do - most hard to fix bugs in the engine and most security woes of features such as unserialize() stem from references. Unfortunately, TONS of code uses them, and there are some data structure things that would not work without it unless alternative solution is provided. So it could not happen in PHP. But it'd be interesting to see how it works for Hack.
- fredemmott 9y ago
  we're currently leaning towards out/inout parameters, with copy semantics, not byref (and in most cases, we'll probably be able to optimize away the copy); not certain yet though.
  - smsm42 9y ago
    Would be nice to hear what comes out of it and how it works!

foxfired 9y ago

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

deleted 9y ago
[deleted]
VeejayRampay 9y ago
In terms of language, jQuery didn't innovate in anything though. It was a great framework mind you, but there's nothing special about it that influenced the choices in design for the more recent versions of JS.
- Kiro 9y ago
  Not even querySelector?
  - VeejayRampay 9y ago
    I think querySelector and querySelectorAll are simply more generic versions of the traditional approach of using getElementById and getElementsByTagName, but it's possible that the greater versatility of $ influenced the later design of querySelector, indeed. Then again, it was not a jab at jQuery, which proved to be a fantastic tool for a decade in the field of web development.
wolco 9y ago
More like coffeescript and es6.

memracom 9y ago

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.

muglug 9y ago
> This is evolution. Embrace it or face your personal extinction as a software developer. Woah there Mr Hyperbole. The reason PHP is still in use, and not dead or dying, is that it's one of the simplest languages to write server-side code in. That means it's remarkably easy to hack something together quickly, with no compilation step to get in the way. Unless that changes in a drastic fashion, projects will continue to get started in PHP, and PHP's user base will continue to grow, and (hopefully) the language will continue to improve to accommodate that growth.
segmondy 9y ago
If you believe this, then you are very bad at predicting the future. I'm very bad at that too. But I can assure you, "better languages" don't win the war. PHP has a lot of software out there and what's going to have it leading HHVM. You will have the "cutting edge" folks give HHVM a shot, but all the practical folks don't care. The only way HHVM will have a chance will be to be 100% backwards compatible.

fiatjaf 9y ago

[removed language flame war]

grzm 9y ago
There are plenty of places where you can view arguments for and against PHP alone and in comparison to Python and Ruby on the internet. This submission is specifically about HHVM. Asking people to justify the use of PHP in such a context is just inviting a language flame war. Please don't.
segmondy 9y ago
Faster than Python and Ruby. PHP7 is actually a better OOP language than Python is. PHP is much easier to get started in and find "talent" for, tons of PHP developers out there. A lot of money has been made with PHP, the only reason many companies switched from PHP is that the developers wanted to "feel grown up" and switched to something else.

krapp 9y ago

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.

emodendroket 9y ago
There are a lot of choices to not write HTML by concatenating strings though.
- krapp 9y ago
  Are there in PHP, though?
  - grzm 9y ago
    PHP does have a history of making this more explicit, given its origins as a templating language. If you go down far enough, isn't all HTML rendering string concatenation? There are plenty of libraries that handle this in many languages, including PHP.
    - krapp 9y ago
      I'm just annoyed that PHP doesn't handle HTML tags natively as their own distinct entities. Not having to quote HTML as strings or switch into and out the rendering context with PHP tags makes templates a lot easier to reason about and cleaner. With that, you can natively get features like auto-escaping, HTML tag validation, extending or creating custom tags, template inheretance, all of which you can do in PHP but only if you include the overhead of a framework.
      - grzm 9y ago
        > I'm just annoyed that PHP doesn't handle HTML tags natively as their own distinct entities. I'm interested in things like this as well. Can you provide an example of what you're thinking of? Something like JSX? Other data structures that are transformed into HTML by a library? The latter seems to be counter to your argument about requiring the use of some framework or library, but I can't think of any alternatives off the top of my head.

ecesena 9y ago

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.

fredemmott 9y ago
https://github.com/hhvm/hack-router/ https://github.com/hhvm/hack-router/ and https://github.com/hhvm/hack-router-codegen/ https://github.com/hhvm/hack-router-codegen/ power docs.hhvm.com and some of our other users; they do have problems such as extremely lacking documentation, which I'm going to be addressing soon. This is definitely an area we're planning on working on - and this post is meant to be announcing the start of this work, not that it's ready :)

royge 9y ago

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.

rurban 9y ago
That's the plan. Break the old nonsense, like the one they mentioned: refs and refcount. Everybody should switch to Hack, it's a much better and safer language.

philippz 9y ago

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.

COil 9y ago
Agree, that's a pity. Instead of having one top language, we will have 2 "now-incompatible-great-languages".

thatonechad 9y ago

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.