Over the last few weeks, there’s been a slew of HHVM related news from the “We are the 98.5%” post from the HHVM team to the Our HHVM Roadmap from the Doctrine team. With the increasing excitement around HHVM, it’s becoming clear that the project is going to play an important role in the evolution of the PHP ecosystem. Even though it’s in it’s early stages, what influences will the HHVM project have on the PHP ecosystem as a whole?
Force the creation of a language spec
In contrast with other languages like Python or JavaScript, PHP has no formal language specification. There’s some extended discussion on this StackOverflow thread with links to PHP internals posts but the final consensus is that there isn’t a defined EBNF grammar for PHP or a “specification” for how things should work. Instead of a spec, the behavior of PHP has become defined by how the Zend interpreter works since it’s been the only viable implementation of the language to date. HHVM changes this situation by introducing another run time for the language, a developer won’t necessarily know if their code will be deployed on Zend or HHVM. Because of this, the community will have to develop a language specification to ensure that any language changes are implemented identically in both run times.
Willingness to introduce BC breakage
One of the hallmarks of PHP has been its strong adherence to backwards compatibility, five year old code written to target PHP4 will generally run today on PHP5+ without any modifications. This has generally been possible because changes to PHP the language didn’t change behavior which would of broken previously working code. Because of this, many of PHP’s long standing syntax issues haven’t been fixed and changes to the standard library have been largely avoided. If HHVM emerges as an alternative runtime, some of this hesitation should be removed since if only “newer” code will run on HHVM it would be conceivable to introduce a “HHVM compat” mode into the Zend implementation which could include BC breaking syntax changes.
JIT into Zend
Just in-time compilation has been shown to dramatically increase the execution speed of interpretted programming languages and it’s one of the key benefits of the HHVM interpretter. HHVM identities “hot code” which is repeatedly executed and then compiles those blocks to native code. The result of this is that those “hot code” sections execute faster since they’re running native code instead of the interpreted op codes. As HHVM becomes more popular, I think we’ll see cross pollination of JIT into Zend similar to how Firefox adopted JIT after Google released Chrome.
Anyway, it’s still early but the emergence of HHVM as an alternative PHP runtime will definitely have a positive influence on the PHP ecosystem. From technology sharing to increased competition, the future is bright and I’m excited to see how PHP evolves in the next few years.