Drop HHVM support?

[nicolas-grekas]

I'm wondering if anyone is using HHVM to run Symfony apps? Travis only runs legacy HHVM, which means we do not verify that Symfony really works on current HHVM.

[Tobion]

We used to do that but just switched to PHP 7 recently.

[fabpot]

I think the main question is HHVM vs PHP7. Some projects switched to HHVM before PHP7 was announced but I haven't heard of any significant move since the announcement of the PHP7 speedup initiative.

Note that we don't spend too much time on HHVM support and we don't have too many hacks to support it either.

[linaori]

To me, HHVM was a nice start for php7, but that's about it. Hacklang is a completely different language now so someone using symfony will never be able to use the speed of HHVM to its full potential with Symfony. When supporting HHVM you might even be unable to use some newer php versions if the support is not backported to HHVM properly.

Making it work on HHVM takes a lot more effort and knowledge of what is and what is not support. To be honest, I'm not even looking at failures in HHVM anymore when contributing.

[Ocramius]

Sad truth indeed. We'll probably end up dropping HHVM support as well, unless it gets in sync with PHP 7 :-\

[Crell]

The question is what the level of effort is to be HHVM compatible. Obviously using HHVM-specific features is a no-go, at least in the core system, but if it's a marginal effort, great. If it's considerable effort, not so great, and probably not worth it now that the performance difference is basically a wash with PHP 7.

Why is Travis still running an old version? Could they be coaxed to upgrade?

[omansour]

in my point of view hhvm is not a thing in the community nor in the industry. Symfony can safely drop hhvm support like many others packages / components.

[derickr]

Travis runs an old HHVM (3.6.6!!!) because of dependencies with newer versions that are not available with their ancient Ubuntu version.

[theofidry]

The problem is that HHVM is not properly tested right now. If HHVM must be supported, it should be properly supported, i.e. against different versions of HHVM as it is done for PHP.

If someone is using Symfony with HHVM and needs something to be fixed at some point, unless it's a very ugly hack I hardly see a reason to fix it if it's reasonable, but it may not be worth to promise a real support either.

[mbabker]

Travis-CI did an update recently that allows using newer HHVM versions, see https://github.com/travis-ci/travis-build/pull/733 and https://docs.travis-ci.com/user/languages/php#HHVM-versions

Unfortunately it's not as straight forward to set up as the main PHP releases.

[rybakit]

Travis only runs legacy HHVM, which means we do not verify that Symfony really works on current HHVM.

You can run whatever hhvm version you like by using docker containers on Travis.

[fabpot]

@rybakit Of course, but we are trying to figure out if it's worth the effort.

[stof]

@mbabker but the container infrastructure (used by Symfony) still runs on Precise for now, meaning that newer versions of HHVM are not available (as Facebook dropped support for Precise a long time ago)

[npotier]

I would agree with @omansour. In our case hhvm is out of scope in our projects

[mbabker]

@stof Unless there are explicit dependencies on the Precise structure (I'm not well versed in the CI configs), you can specify the distro on a per-build basis so all existing tests would still run on Precise and HHVM tests could run on Trusty.

Personally I've got no opinion either way, but I've got a contributor on a project who has been doing work on HHVM compatibility so I'm aware of that change through his efforts only.

[nazar-pc]

Many third-party projects are using Symfony components. For instance, there is https://github.com/php-pm/php-pm with multiple dependencies on Symfony packages. https://github.com/reactphp/http, which is the base for PHP-PM truly shines under HHVM after some warmup comparing to PHP7. So removing HHVM compatibility would require such projects to move somewhere else, which is also a big effort.

I'd like HHVM implementation to be closer to PHP and I even contributed few patches, especially for Phar support. If there will be some push from community in terms of decreasing incompatibilities an effort to keep HHVM support might become much smaller.

At the end of the day, HHVM have already influenced PHP itself in a good way. If it will be around, even though diverged from PHP, it is better than having single PHP interpreter in the wild (I'm looking at Symfony as one of top projects in PHP ecosystem which this way or another influences everything else).

[janit]

I think maintaining HHVM is reasonable if it's not too much work. HHVM is going forward separately from PHP 7 and who knows what they manage to do in the future.

[stof]

it would be great if they could implement feature parity with PHP 7 though (they currently target PHP 5.6, with some differences).

[jjsaunier]

I think if we are not able to provide HHVM test suite without huge effort it's better to drop than say we support it BUT ....

[stof]

I have an idea to try something on Travis to get access to their new HHVM multi-version support. Will report back this evening whether it works

[ciaranmcnulty]

In my opinion as maintainer of a project that uses Symfony components, breaking changes on HHVM would lead to me dropping HHVM, not dropping Symfony components.

[fabpot]

@ciaranmcnulty well said

[ciaranmcnulty]

To be clear, Symfony keeping HHVM support is still the best option for lazy me but if you drop it it won't be a huge impact

[andrerom]

I would say we should push on travis to update trusty env (or maybe they will switch to 16.04 instead soon, who knows, they dont tell). So tests can run on lateste hhvm version, it is still relevant for some, and they might further improve its performance as well.

[taueres]

HHVM supports the new features of PHP7 since version 3.11. Backward incompatible changes can be activated via special php.ini parameters.

http://hhvm.com/blog/10859/php-7-support

[tgabi333]

We use hhvm with symfony on production. However we still testing for 5.6 and 7.0 too and hhvm 3.6.6

[linaori]

It could always be an option to add the HHVM matrix to the list of allowed failures, but that means that not everyone will fix it. It could be an incentive for other people to contribute HHVM specific PRs to symfony if they want to get it to work. If this doesn't happen, support can be 'safely' dropped.

[d4r5c0d3]

HHVM parity with PHP Developers have clearly stated that they want HHVM to run regular php. They want it to deliver the same functionality even if it is quirky at times. Their idea is that HHVM will have same functionality but only differs in implementation. There are only few inconsistencies, most of them are well documented everything else that does not work the same as PHP is considered a bug.

HHVM vs PHP7 As @taueres mentioned HHVM already has majority of the PHP7 features and is working to get full compatibility . With this said I think the question is more when is symfony going default to PHP7 so we can use all those new features until then we pretty much limited to writing php 5.* code.

HHVM speed and hacklang Using HHVM to run your regular php ( 5.* ) code does give you performance increase. Using hacklang would benefit it even more but symfony is a PHP framework not a hacklang framework so this is totally outside the scope.

I would say it is worth keeping HHVM support for symfony for the following reasons:

1. HHVM has already proven it has it place.There are some websites ( wikipedia, baidu) that did a study on how to improve their performance and ended up lower cost too by switching to HHVM. I would say there is need for a good framework like symfony in this range.
2. Supporting HHVM will only require little bit more effort than making symfony PHP7 ready
3. This is more of a personal thing but, I consider symfony quality software and dus I would crawl in a dark corner and cry. If I would be able to run wordpress in hhvm and not symfony.

Things that might be or become problem.

1. Testing on multiple platforms continuously
2. Deciding what to do when HHVM has a bug that is not yet fixed that is blocking some core functionality.

[soullivaneuh]

Nice comment @DaRamirezSoto.

Agree for PHP 5.* vs HHVM performance. But PHP 7? For some articles I saw, The performance looks like to be the same or maybe better for PHP 7, maybe I'm wrong.

In a more personal case, I do not use HHMV at all.

@fabpot I also launch a poll on Sonata for HHVM usage. This could give you more information: https://github.com/sonata-project/dev-kit/issues/126

For the moment, it seems to not be used.

[linaori]

@DaRamirezSoto Wordpress is still supporting (and has to support) php 5.2, so I don't think it would be using that many features which could be or are bugged in HHVM, or under-performing for that matter.

[taueres]

Bear in mind that Hacklang and Php can be used together at the same time. In a well-designed system, you can decouple business logic components and write them in Hacklang strict mode. When needed, you can use Hacklang partial mode or Php to interact directly with the Symfony framework.

Code written in Hacklang strict mode gains performance boost and powerful static typechecking.

[d4r5c0d3]

@Soullivaneuh I don't think that decision should be based on which of the the 2 preforms best. Both preform well enough to be used and both have their merits.

Even though the adaptation of HHVM might seem low at current time. I do feel that it is going to shine more in enterprise realm for the obvious reasons. Facebook needed to develop it to help them cope with issues which they where having at much larger scale. Would Symfony not benefit from being able to be used on such platforms?

@iltar Yes wordpress can be used on 5.2 but nobody in their right mind would do this since php 5.5 nearing EOL. So it pretty much only gives strength to my argument that symfony code quality is higher and should be able to be run in HHVM.

[stof]

Given that I managed to use the uptodate HHVM version on Travis (see the PR referenced just above this comment), I vote for keeping the HHVM support.

[soullivaneuh]

'm wondering if anyone is using HHVM to run Symfony apps?

@nicolas-grekas @fabpot Maybe start a Twitter/GitHub poll to have a clearer view?

[nicolas-grekas]

Thanks to @stof we're now testing the latest HHVM and it's green. Since it doesn't "cost" us much (except waiting for a 8'30 matrix line), let's keep HHVM. Closing. Thank you all for the feedback.