Of HHVM, Hack and the future of PHP
Anthony posted a very interesting opinion piece about the future of PHP. I want to specifically comment on the part about HHVM and Hack. I have of course published my own opinion on the topic fairly recently on my private blog. Fellow Liiper Chregu has also done a very popular post on this very blog showing some very significant performance improvements that can be achieved with HHVM. Infact the project Chregu is working on is looking to be one of the first large production users of HHVM outside of Facebook and he is making good progress on integrating HHVM with New Relic which we use quite a bit for performance analysis in larger projects. Facebook is also presenting their point of view on PHP and Hack and probably the most promiment was this presentation called "Taking PHP Seriously". So with having set the stage let me address some of the points raised by Anthony.
HHVM in production
While Anthony does not recommend running HHVM in production, we are obviously getting ready to do just that. I totally agree however with the risks he points out. We realize that while the current version of HHVM is open source, there is no telling what will be the case with future versions and if they will eventually no longer be compatible with PHP or simply no longer open source. We have an extensive test suite to ensure that we get the expected behavior. Furthermore we have a failover system in place leveraging Varnish to ensure that we can simply go back to plain PHP and we make sure that our application meets the minimal performance requirements of our client with good old PHP. But for now we like the improved latency we are getting thanks to HHVM in a few more complex parts of the application. So far so good.
Hack, trouble in paradise
Now Hack is more than a mixed bag for me. Lots of the things in there are interesting. But it shows how impatient Facebook is with the core of PHP. Maintaining HHVM to have a PHP and a Hack mode is certainly a burden for Facebook's development and if indeed all their code will eventually target Hack, the question becomes if they will one day decide that PHP mode is no longer worth the hassle.
Now since HHVM is open source of course the open source community can then fork and continue the development. The longer HHVM remains committed to PHP compatibility, and infact right now Facebook is doing a lot to continously improve the compatibility, the higher the chances of enough people becoming invested in HHVM and therefore potentially willing to keep HHVM PHP mode going even if Facebook might loose interest.
Making Facebook care
One of the big questions is why does Facebook even care about PHP mode if they are already moving their own code to Hack? To me one big reason for this could be that they actually want to use code produced in the community. I have not really seen any Facebook engineers sending code to PHP libraries but maybe right now they are not being so obvious about this. Despite the fact that last I checked (about a year ago) their Facebook PHP SDK had some hideous code, I am sure that this would be quite exciting and I have no doubts that they have some excellent PHP programmers that could boost adopted libraries quite significantly.
So maybe in the end the best way to ensure that PHP mode in HHVM remains a goal for Facebook is to keep churing out high quality PHP code?
Add a comment
Your email adress will never be published. Comment spam will be deleted!