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.
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.
Just wondering:
"numerous other languages out there that are also better than PHP but have much better ecosystems"
What languages are you thinking of?
I've used a lot of different languages, but I still think PHP is awesome for web developmemt. Being normally limited to "one request, one execution" might be an annoying limitation in some situations, but other than that I think PHP does the job quite well. So that's why I'm wondering what you think is a better existing alternative.
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.
If they are not going to specifically target the language compatibility, then the compatibility doesn't exist. My interpretation of this post basically speaks the death of HHVM support PHP, and start exclusively as runtime for Hack.
> 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.
They're dropping PHP5 support, but it sounds like they're not actively trying to be incompatible with PHP5, so I doubt that gets worse right away. There's no existing codebase that's PHP7 already that would consider Hack, is there?
I mean what problem does it really solve when PHP7 has much more robust typing? At this point I think it's only instance variables and inline variable declarations that can't be typed.
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.
It catches so much stuff, I've been using PHP since 2009 and it there was still stuff I was doing day to day it flagged me for, it's not only that it makes you write better code but it catches so much stuff that you no longer have to hold in your head (things like "Method throws an unhandled exception" etc).
In terms of "wow" (impact vs amount of effort required) it's second only to TypeScript in the last year or so for me.
Not a co-incidence that both tools add better type checking (amongst a lot of other useful stuff) to the languages I was stuck using.
> 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?
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.
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.
I'm chief architect at Slack, and we migrated to Hack from PHP 5 throughout 2016.
The toolchain for HHVM is all installed as a single big deliverable, which gives you the language engine and supporting runtime libraries itself, an in-address-space web server (Facebook's Proxygen), a debugger in the form of hhvm -a, and the Hacklang toolchain accessed via hh_client and appropriate editor/IDE integrations.
I share your intuition that there is actually a glittering core of "stuff-that-makes-you-successful" hiding in the incidental complexity of PHP, and we wrote this blog post trying to put some substance behind that intuition: https://slack.engineering/taking-php-seriously-cf7a60065329
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.
I'll leave the first part of your question for someone less close to the project.
For the toolchain, when using it: it's currently mostly the PHP toolchain (e.g. composer) with some additions:
- the typechecker: this is a fast (I usually get full results in well under a second) static analysis tool, fully integrated with Nuclide (our IDE), and with excellent support in VSCode via a third-party plugin. This is a massive improvement in developer experience, especially when refactoring. Usually the unit tests pass first try once I've fixed the problems that Hack finds.
- an autoloader that can handle any definition (e.g. functions, typedefs, constants), not just classes
- the built-in webserver isn't just for development - no need for fastcgi + apache etc, though that is supported
As for building/working on HHVM itself, it's basically modern C++ using CMake, and the Hack typechecker is OCaml.
I've worked on HyperPHP / HipHopPHP (HPHPc, known by a million different things in its lifespan) in the past doing a lot of documentation and edge case testing. I absolutely loved the compiler, turning PHP scripts into C++, and running it through its paces using ANN libraries. I have a lot of love for the project and was onboard very early in the lifecycle. I really, really miss it. I thought it was a great learning tool.
Anyway, it's proven that without competitors to Zend Engine, the PHP team simply doesn't care to pay much attention to performance. (Snide comments about performance from maintainers and internal PHP contributors can be found all over the Internet to prove this point.) I am afraid this will continue as HHVM splits from PHP and moves more towards a JVM-type future.
Hack will be the "serious" language while PHP7 will serve a solid niche, and one I'm continually proud to support and use in production.
Nuclide works well enough with Hack and the typechecker is really solid.
I'm excited to see the future of both projects, but again, it is important to note that HPHPc by Facebook pushed PHP's project team into caring about a lot of this stuff over the years. I hope it doesn't take that kind of disruption to continue development, as I think PHP is in a really good spot now and don't want it to stagnate.
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.
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.
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.
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.
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.
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.
> Eliminating references. PHP references have unusual semantics, where the function specifies the binding of parameters with no indication at the callsite.
> 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.
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.
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".
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.
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.
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.
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.
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.
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.
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.
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.
[+] [-] TazeTSchnitzel|8 years ago|reply
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.
[+] [-] Twirrim|8 years ago|reply
[+] [-] NightlyDev|8 years ago|reply
What languages are you thinking of?
I've used a lot of different languages, but I still think PHP is awesome for web developmemt. Being normally limited to "one request, one execution" might be an annoying limitation in some situations, but other than that I think PHP does the job quite well. So that's why I'm wondering what you think is a better existing alternative.
[+] [-] muglug|8 years ago|reply
[+] [-] tanilama|8 years ago|reply
[+] [-] cwyers|8 years ago|reply
They're dropping PHP5 support, but it sounds like they're not actively trying to be incompatible with PHP5, so I doubt that gets worse right away. There's no existing codebase that's PHP7 already that would consider Hack, is there?
[+] [-] emodendroket|8 years ago|reply
[+] [-] muglug|8 years ago|reply
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.
[+] [-] noir_lord|8 years ago|reply
It catches so much stuff, I've been using PHP since 2009 and it there was still stuff I was doing day to day it flagged me for, it's not only that it makes you write better code but it catches so much stuff that you no longer have to hold in your head (things like "Method throws an unhandled exception" etc).
In terms of "wow" (impact vs amount of effort required) it's second only to TypeScript in the last year or so for me.
Not a co-incidence that both tools add better type checking (amongst a lot of other useful stuff) to the languages I was stuck using.
[+] [-] jimktrains2|8 years ago|reply
At what point do you stop using the hammer to put in a screw and just use a screwdriver?
[+] [-] rrdharan|8 years ago|reply
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.
[+] [-] bepotts|8 years ago|reply
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?
[+] [-] kmavm|8 years ago|reply
The toolchain for HHVM is all installed as a single big deliverable, which gives you the language engine and supporting runtime libraries itself, an in-address-space web server (Facebook's Proxygen), a debugger in the form of hhvm -a, and the Hacklang toolchain accessed via hh_client and appropriate editor/IDE integrations.
I share your intuition that there is actually a glittering core of "stuff-that-makes-you-successful" hiding in the incidental complexity of PHP, and we wrote this blog post trying to put some substance behind that intuition: https://slack.engineering/taking-php-seriously-cf7a60065329
[+] [-] hobofan|8 years ago|reply
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
[+] [-] fredemmott|8 years ago|reply
For the toolchain, when using it: it's currently mostly the PHP toolchain (e.g. composer) with some additions:
- the typechecker: this is a fast (I usually get full results in well under a second) static analysis tool, fully integrated with Nuclide (our IDE), and with excellent support in VSCode via a third-party plugin. This is a massive improvement in developer experience, especially when refactoring. Usually the unit tests pass first try once I've fixed the problems that Hack finds.
- an autoloader that can handle any definition (e.g. functions, typedefs, constants), not just classes
- the built-in webserver isn't just for development - no need for fastcgi + apache etc, though that is supported
As for building/working on HHVM itself, it's basically modern C++ using CMake, and the Hack typechecker is OCaml.
[+] [-] icelancer|8 years ago|reply
Anyway, it's proven that without competitors to Zend Engine, the PHP team simply doesn't care to pay much attention to performance. (Snide comments about performance from maintainers and internal PHP contributors can be found all over the Internet to prove this point.) I am afraid this will continue as HHVM splits from PHP and moves more towards a JVM-type future.
Hack will be the "serious" language while PHP7 will serve a solid niche, and one I'm continually proud to support and use in production.
Nuclide works well enough with Hack and the typechecker is really solid.
I'm excited to see the future of both projects, but again, it is important to note that HPHPc by Facebook pushed PHP's project team into caring about a lot of this stuff over the years. I hope it doesn't take that kind of disruption to continue development, as I think PHP is in a really good spot now and don't want it to stagnate.
[+] [-] thinkindie|8 years ago|reply
[+] [-] VeejayRampay|8 years ago|reply
[+] [-] ryangordon|8 years ago|reply
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|8 years ago|reply
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-h...
[+] [-] sunseb|8 years ago|reply
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.
[+] [-] 0x4a42|8 years ago|reply
That's called the Web. :-/
[+] [-] dna_polymerase|8 years ago|reply
Have a look at Python & Flask! There is nothing easier than that!
[+] [-] ankyth27|8 years ago|reply
[+] [-] cdelsolar|8 years ago|reply
[+] [-] maxpert|8 years ago|reply
[+] [-] philippz|8 years ago|reply
[+] [-] COil|8 years ago|reply
[+] [-] pbiggar|8 years ago|reply
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.
[+] [-] smsm42|8 years ago|reply
[+] [-] fredemmott|8 years ago|reply
[+] [-] dcgudeman|8 years ago|reply
[+] [-] foxfired|8 years ago|reply
So if we get to a point where HHVM is completely irrelevant, it simply means "Mission Accomplished".
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] VeejayRampay|8 years ago|reply
[+] [-] wolco|8 years ago|reply
[+] [-] the_duke|8 years ago|reply
I never hear about anyone using it...
[+] [-] muglug|8 years ago|reply
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] krapp|8 years ago|reply
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.
[+] [-] tiffanyh|8 years ago|reply
E.g. FunctionName() vs function_name().
Or
E.g. return 5x20; vs return "5"x10;
[+] [-] thatonechad|8 years ago|reply
[+] [-] crescentfresh|8 years ago|reply
[+] [-] ecesena|8 years ago|reply
[+] [-] fredemmott|8 years ago|reply
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|8 years ago|reply
[+] [-] rurban|8 years ago|reply
[+] [-] fiatjaf|8 years ago|reply
[+] [-] grzm|8 years ago|reply
[+] [-] segmondy|8 years ago|reply
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.