Its been quite a few years since I have been last subscribed to the internals mailing list. I still hang out in one of the popular core dev IRC channels, follow quite a few on twitter. So I still manage to stay on top of what is happening more or less but not the details in the discussions. Just wanted to put this as a disclaimer. Any opinions in this blog post are opinions formed watching something at a distance and this always runs the risk of being quite wrong or more impartial.
To me it feels like PHP development has become much better structured. It also feels like the RFC process has enabled an influx of new contributors that previously simply didn't know how to get their stuff in. There were a bunch of old devs opposed to adding this documented "processes", saying that "open source is about fun and processes kill the fun". But to me that was always shining through that argument was that there is always an implicit process and that process is usually ideal for the current people "in power". As such, there is nothing wrong with that, since if the current people can handle the load, why bother trying to please a theoretical new contributor? But while several core contributors, like Rasmus, Derick and Ilia, have sustained pretty significant levels of contributions, many others have drastically reduced their contributions. More over as the feature scope increases it makes a lot of sense to also grow the number of maintainers. However I guess the really active core group of contributors in most open source project I know tends to hover around 10-20. The beauty of clearer processes is that it can also help in clearer delegation, which can lead to subgroups within an open source organization that again have an inner circle of 10-20 really active people. Now from all I hear "discussions" on the internal mailing list still have a tendency to generate lots of less than helpful traffic.
But everything could be turned up side down in the near future. I have been critical of Facebook's initial efforts at trying to reimplement PHP. A change of direction towards a JIT without a code compilation requirement however have made their efforts significantly more viable. More importantly Facebook is now actively trying to enable anyone to run their chosen PHP framework on top of HHVM. They are even actively soliciting feedback from framework authors where they would like HHVM to go next in terms of language features. If you compare this to current PHP internals where it seems to be a never ending battle between mostly the older developers concerned with backwards compatibility, no doubt one of the reasons why PHP has been able to catch 80% of the internet, and framework authors asking for new language features to enable easier development. Make no mistake adopting Facebook specific syntax in frameworks will of course make that code incompatible with PHP itself. Some of this could be "fixed" by a "compiler" that transforms HHVM specific features to normal PHP code, but that would be probably more sad than ironic. Also what about windows users, still a very significant portion of the PHP user base?
None the less the proposition seems tasty when wearing my framework hat. But while this is exciting, its at least as much troubling to me. Do we really want Facebook to have final say in how the language evolves? I am not even sure if Facebook really wants this responsibility. I guess other scripting languages have already had to deal with this situation with various popular reimplementations of Ruby (JRuby, IronRuby ..) and Python (Jython, IronPython ..) having scooped up large parts of their user base. Then again I assume these reimplementations have actually also helped grow or at least sustain their use bases. Facebook has hired quite a few of previous PHP core developers though I am not entirely sure how involved they are in HHVM development. But at the very least it could ensure that there is a bit of a trust relationship between PHP internals and HHVM, which is of course quite important in the open source world. Rasmus also seems to be sympathetic to HHVM. To me a key requirement for this all to make sense is for more non Facebook employees to get involved in HHVM development. This would ensure that the project wouldn't blow up if for some reason Facebook looses interest. It would also help in making the internal decision process on HHVM more transparent.
At the same time I see a huge opportunity here. If I remember correctly it was Thies that first stated that the goal of PHP internals should focus on making it possible that all extensions could in fact be written in PHP rather than C back at some LinuxTag over a decade ago. With HHVM's JIT this now seems more feasible than ever before. I have long said that building a good API is an iterative process which requires input from many people and early adopters to battle test. However as PHP is written in C the number of contributors are limited and its not easy to get a broad range of testers to put the concepts into real world testing. PECL has tried to reduce this pain point a bit by providing infrastructure for C developers to create and distribute extensions outside of core release process. But to me its still clear that its not a sufficient solution to provide the number of eyes needed to build more complex APIs. So HHVM could help push forward a revolution in the process of adding new functionality to PHP that I have been waiting for since ages.
So in conclusion there are lots of reasons to be excited about HHVM's impact on the PHP community. But we should also ensure that in the process the community does not become dependent on a commercial entity.
Update: The performance of HHVM seems quite impressive indeed these days, since Chregu ran these benchmarks, the HHVM team has released version 2.3, which supposedly reduces CPU load another 20%. HHVM is now also available on Travis-CI.
Update 2: The article has been posted to hacker news, resulting in a surprisingly sane discussion.
Competition is good for business
There were other projects before (RoadSend PHP), but HHVM is already good enough for a lot of php code bases and works more or less.
Sometimes it seems PHP Internals/Devs uses backward compatibility as excuse.
Other Languages have constructs like a strict mode that works on parser, compiler and runtime feature level. Throwing errors with E_STRICT is only a small part of it.
Some functions throw exceptions, other produce simple text warnings. Even when you can select the mode like in PDO, then it wasn't guaranteed to be successful because of bugs. There is a lot framework code to explicit hide PHP Language design flaws (that won't be fixed) or some bugs or odd behaviour. Adding a case for HHVM will be easy. The question here will be: If HHVM works on enough servers good enough, why write a case for broken PHP?
HHVM usage of c++ makes a lot extension code much more readable then the cluttered ZEND Macro extension stuff. A welcome side affect will be that PHP Language users are much more likely to spot and maybe even fix an error in extension code for HHVM.
The assumption that all people who write stuff in php/python/javascript are totally non programmers are odd. The code base of php vm is simply unfriendly. A binary extension defeats the purpose of current PHP nature, write once and run on any box with PHP installed:
“Upload to Webserver, and start your browser”-Deployment
(If you can effort other deployment methods there are a lot other languages)
But there are real php extensions written in PHP already: Frameworks
So what do these Frameworks at the low level usually provide?
Input Processing and sanitize (GET/POST/COOKIE)
Session Management
Database Access without surprises
Syntactic sugar for callbacks
Template processing
XML, HTML, JSON processing
These are stuff that php should already have in some kind of fast internal c code, but it simply fails to deliver. Frameworks fill the gap. If HHVM provides substantial better alternatives and people use HHVM then Frameworks will use these extensions.
Framework code is already filled with edge case handling for different PHP Versions, adding a case for HHVM isn't a problem.
As soon as HHVM is easier to deploy and most code will work, the PHP runtime may get obsolete or will deliver a better out of the box experience for Framework authors and direct PHP programmers.
Actually this means we will get a better and more stable language over time...
There's still a lot of software development using PHP that's very poor, but as long as it's the simplest solution for a small business to go from nothing to functioning & completely stable website, PHP has a big future regardless of what happens with HipHop and other attempts to reshape and modernize the ecosystem.
Node.js and Ruby and other languages like Clojure get much of the hype, but many startups are still built off of PHP and that's easier than ever. The hardest part nowadays is doing things like picking the right business model and reaching out to customers (Facebook and things like BuyLikesReviews are new ways of doing that) but the technology itself behind PHP is much more useful than the media hype indicates.
As long as any new solutions or innovations doesn't change the PHP philosophy of "upload a file and you're deployed" things will be great.
This twitter thread very much highlights what I was trying to say in regards to the growing pains around the RFC process:
https://twitter.com/derickr/status/499586842279542784