We started working on HHVM compatibility on December 2013. On July 2015, we proudly announced full support for HHVM. Symfony 2.3 and all other maintained Symfony branches were compatible. It was a long journey and it took us a lot of time to get there. We also got support from the HHVM team as they fixed bugs we weren't able to work around in Symfony.
Back then, the most attractive selling point of HHVM compared to PHP was performance. HHVM was way faster than PHP. But soon enough, the PHP team embarked on a quest to find ways to drastically improve the performance of PHP. PHP 7 was born. Nowadays, the performance difference between HHVM and PHP is not significant anymore.
After a poll on Twitter, we have decided to drop support for HHVM as of Symfony 4.0. Results show that HHVM adoption is very low in the Symfony community (less than 4% said they were using HHVM and wanted it to be supported by Symfony).
But if Symfony supports HHVM today, why do we want to remove it in 4.0? If HHVM
and PHP were equivalent (same features, same bugs, same behaviors, ...), that
would not be a problem. But the reality is very different. Some PHP 7+ features
are not (yet) available in HHVM. Symfony's code has quite a few workarounds for
HHMV. Nobody in the extended core team uses HHVM. But more importantly, when we
decided to bump the minimum PHP version to 7+ in composer.json, we realized
that there were no way to make our tests pass. The first blocker is that even
Composer is not compatible with
HHVM when using PHP 7. And the issue was created about a year ago. I knew it as
I tried to make it work back when I was about to release Twig 2.0 about 6
months ago. Nothing changed. It looks like PHP compatibility is not much of a
priority anymore for the HHVM team.
Given the low adoption, compatibility issues, insignificant performance differences, we had no choices but to officially drop support for Symfony 4.
We will keep HHVM workarounds in Symfony 3.4 though, which means that projects using HHVM will still be able to use HHVM with Symfony until November 2020 (three years from now as 3.4 is a LTS version). That gives plenty of time to migrate away from HHVM or Symfony.
Symfony is not the first PHP project to drop HHVM support. Doctrine, CakePHP, and MongoDB dropped or will soon drop HHVM support (as commented on the Twitter poll). Laravel also dropped support as of version 5.3 (released 9 months ago). I can imagine that more PHP libraries will drop support as they will face the same issues as Symfony when requiring PHP 7.
That's also why I have decided to drop HHVM support for all my other significant projects like Twig (as of version 2), Silex, and Swiftmailer.
I have also created a pull request on the HHVM repository to remove my projects from the HHVM compatibility test matrix as we don't want people to think that Symfony is still compatible with HHVM while it's not properly tested. It is even more important as tests run on an old and unmaintained Symfony version (2.4.8). I think other projects should do the same to avoid confusion.
Sounds not too bad for me - and I can imagine it`s a lot of extra work to keep symfony compatible with HVVM when "they" do not keep track of compatibility with PHP7. When starting a new project, we had looked into HVVM some time ago. However, as the performance benefit is minimal compared to PHP7, we decided to stick with PHP7. I hope, the community will understand and support your decision.
It is a bit sad that so many project dropped HHVM support. I do understand the reasons and I think that they are all valid.
We must, however, appreciate HHVM and the role it played the last few years. I believe that HHVM gave us PHP7. Without a strong competitor (both performance and community) we would not have PHP7 as we know it today.
Also dropped support for HHVM in the packages my company has open-sourced. HHVM was a nice push to get php7 going, I'm still very thankful for that.
@Tobias you're right about what HHVM brought to the PHP ecosystem, the problem is that HHVM is not following the path as fast as PHP does. It might be quite normal, because HHVM is a bit harder to setup and implement, and is something new to learn for devs (because it's "PHP but not entirely like PHP"), that's why developers didn't replace PHP with HHVM when PHP7 was released.
If the HHVM team made the projet grow faster and follow PHP7 compatibility, maybe HHVM support wouldn't have had to be dropped :/
Fully supporting this. It will bring much more energy to improving current features and code.