But HH is neither installed everywhere nor will the old codebase be compatible. Why not use a proper language right from the start? There are tons of alternatives that do not suffer from the shortcomings hh tries to fix.
Their roadmap also includes making it easy to install on Linux and other platforms, so it may make inroads into "everywhere".
If they can even achieve the first objective, then people can continue with the normal PHP runtime as usual in most places and switch to HHVM when they need better performance.
Also, I find PHP a delight to program in. YMMV.
However, your average codebase, written for PHP 5.0 or older, touched by many, mostly incompetent people over several years, is usually incredibly painful to work with.
That's kind of scary. It'd be like captaining the SS Swiss Cheese.
"PHP developers", by which I mean developers that know PHP and PHP only, are the first to throw a fit when their language is criticized.
This is especially awkward as most PHP developers don't even observe best practices for developing with PHP, insisting on using obsolete versions, write hazardously bad SQL queries with so much moaning about how it's not a big deal, and get absolutely irate when you suggest they use an application platform instead of rolling everything by hand.
There's something to be said for using a language where the community encourages people do to it properly, and everyone's trying to make an effort to move forward together.
Also checkout the Symfony components and how many large open source PHP projects are using them:
* Symfony Framework
* Drupal
* Laravel
* Silex
* phpBB
* Guzzle
Then there's Composer (which also uses Symfony components) and PHP-FIG. The list goes on.
What you need is more modern PHP developers advocating on boards like HN how good PHP has become, not how much better other ecosystems are than what PHP was five years ago.
StackOverflow is filled with people who've suffered badly at the hands of w3schools and various atrocious YouTube tutorials which perpetuate the absolute worst practices from the 1990s.
Perhaps the problem isn't having good resources so much as getting rid of the bad ones.
PHP still has a long, long way to go. The rampant infighting in the core team, the completely incoherent API and language design, the lack of innovation on core libraries, none of this is very encouraging.
PHP is a greasy pig at the best of times. You can kit it out all you want and it still isn't a first-class scripting language, it's only a web-site scripting system, and the way it's designed it will only ever be a web-site scripting system.
The only advantage to PHP has been, in historical terms, its ubiquity. Most if not all hosts support it. However, this is a blessing in disguise. Most of these hosts only support PHP 5.2 or maybe PHP 5.3, usually trailing two or three releases behind what's current.
For those who write WordPress-like "download, install on server" packages, sure, PHP is an effective delivery platform, but I'd hardly call it a great programming language.
Maybe I'm missing something, though, but I've never seen anything about PHP that's made me go "Yeah, I wish I had that in X language", but it's often the case in reverse.
I've done a lot of Python, Ruby, Perl, C++, Objective-C, and JavaScript and each of these has something interesting about them, a style that meshes well with their design philosophy.
What does PHP bring to the table that means choosing PHP is a good idea as opposed to just doing PHP by default?
What is there to enjoy about PHP? It's an honest question.
I think the thing that php needs right now is a 'good parts' book and an accompanying movement. Like javascript the way it was used around 2000 was embarassing, but that is simply no longer the way you use it.
If you have a sizable existing PHP codebase time and money would be better spent making it run on HHVM than rewriting it in another language, especially if you have an existing army of PHP developers.
There are also quite a few good libraries and frameworks out there for PHP, although they're hard to find if you're not already experienced in PHP and can filter out the horrible ones by reading their code. Compared to Python, the task of finding quality code is generally harder from all the existing stuff out there holding on to bad hacks from PHP 5.2 and before (as well as long time PHP developers abusing such bad hacks out of habit).
Also, in PHP, trying to do anything event related with server to client notifications[1] comes down being an ugly hack[2] unless you want to use some third party PHP extensions like libevent[3] or offload to another language/service you could have just written everything in to begin with. PHP is just not built for anything unconventional like that and makes your life a headache if you ever find you need it at some point. Screwing with all of that is way more of a pain than just using Python with Tornado or Twisted, using Node.js or something like Play 2.0 with Scala. For what it's worth, the MySQLi native driver/api supports non-blocking async queries to the DB at least now and the native PostgreSQL API does as well (albeit the PgSQL API is not Object Oriented and I resorted to wrapping it a class that mimicked the MySQLi Object Oriented API for consistency).
[0] http://marc.info/?t=132988607800003&r=1&w=3 (lots of futile rants about it here). Basically comes down someone rejecting enum because they claim it's "redundant" (though PHP has plenty of previously accepted redundancies) when you can fake them with classes (which is not true as you cannot use them in a switch [without faking with toString()] and cannot use them without instantiating an object). The other excuse is it would introduce "strict typing creep" to PHP, which is silly, since you can already type hint on functions by including a the class or array type in each parameter (and will even throw an error if using the incorrect type). Excuses are not surprising though, given the news the past month of how toxic the core developer mailing list is for PHP.
[1] http://ajaxpatterns.org/HTTP_Streaming
[2] To implement in PHP without event listeners, you have to use some sketchy third party php based http servers instead of fcgi+fpm for those parts or fake it with an infinite loop + sleep and use nginx + http push stream (http://wiki.nginx.org/HttpPushStreamModule)
I'm using it for a project I'm working on because PHP has the only supported cpanel client library, and I don't want to maintain my own bindings for cpanel. I've found that React works quite well for processing queues in PHP and notifying the client via websocket when events occur.
I did introduce a Play/Akka scheduling daemon instead of hand rolling that in React, which simplifies the PHP worker greatly as it only needs to process jobs submitted over ZMQ, not read the database and update an internal list of jobs.
I would love to try porting this application to HHVM when there is support for a libev/libevent/libuv extension that is compatible with React.
I was not aware of the async database library in PHP, though it doesn't seem to be integrated with the React main loop implementation and might be some work to get it working. Are you aware of the difference between Mysqli and Mysqlnd and do you know when I should use either on of them. (I use PDO for database access and prefer the OO api it provides.)
MySQLnd uses the same API as MySQLi, so the only differences are deciding which to use within php.ini file and ability to use the asynchronous methods in for the MySQLi API in PHP. When MySQLnd originally came out, there was no support for SSL connections with it, but that's been fixed since PHP 5.4 I believe.
Won't be able to use PDO though if wanting to use the async stuff (unless they have added that). Could probably write a small adapter to wrap one or the other though. MySQLi API design is kind of quirky compared to PDO API, so I generally write a small helper class to make life easier for dealing with prepared statements and binding variables to them.