Edit : seems like i wasn't clear. I don't mean sad for the people working on the project ( i'm sure they love what they're doing), i mean sad because as a non-php dev ( but basically everything else dev), i know many "better" languages that would benefit from having those kind of people on board.
Modern PHP, with Composer, the PSR standards, and the Framework Interoperability Group's efforts is a very different beast to PHP4 or <=PHP5.3. Sure, one can make an argument that a "better" language would be a nicer target for this sort of amazing talent, but that ignores reality: So many things run on PHP, that it's a good idea to fix PHP's issues. HHVM and Hack are doing sp (in parallel with the communities efforts), and I thank them for it,
Besides inconsistent/bad library argument order/naming, and a couple parser related issues that are slowly being fixed (like the "immediately use an array returned from a function" issue fixed in 5.4) I don't see any "huge amount" of quirks.
I do see a lot of bikeshedding, from people who could have found similar BS in most languages in major use.
P1 - "PHP sucks, it's a terrible language with no proper design and no serious person would ever want to use it"
P2 - "But tons of large projects are built on it and people ship with it everyday"
P1 - "So? It's still terrible"
P2 - "What do you think is so terrible?"
P1 - "Oh lots and lots of things, I wouldn't even know where to begin"
P2 - "How about this: let's throw boatloads of cash on it for a while and see where we get."
P1 - "Oh gee, I dunno if..."
P2 - "Boatloads of cash it is.
[edit] After seeing how my comment could be seen as ridiculing HHVM: I'm a PHP dev and I'm loving every second of what they're doing. I think they're right on the money.
That said, I'm appreciating the move to containerization and micro-services more... replacing some pieces with better options becomes far easier when those pieces are smaller. I can prototype in something like node, and move those troublesome bits to something like go or c++ if needed.
It's simply not viable from a time-investment point of view to throw away tools you know extremely well, are well entrenched, well supported and stable every few years because something new comes along.
Hack is a fantastic language and the work by the HHVM team benefits the PHP ecosystem as a whole.
PHP may have its problems, but many companies use it for its many benefits, mainly the ease of finding developer talent.
Or the best decision ever made by the company.
You might as well feel sad that these brilliant people are not "curing cancer" or "eliminating AIDS" or something.
> Integration of LLVM as a further optimization step to make the hottest code run even faster on HHVM.
These multistage JITs are absolutely fascinating, I believe Safari is doing something similar with Javascript. Intuitively I would've assumed the overhead of firing up yet another JIT and VM to run it on would make it not worth it, but I guess the instructions currently generated are so far off optimal that it is worth doing.
EDIT: Anyone know of any papers regarding multi-stage JITs that I can check out?
http://php.net/mysqli.poll
With Hack's async support, the runtime manages all of this for you. You call "await $query", and then your function is suspended until the data is available. Other code automatically runs until it too hits an await statement -- which might block it on MySQL, memcache, curl, or anything else, with no extra manual coordination needed. The runtime manages it all for you.
http://hhvm.com/blog/7091/async-cooperative-multitasking-for... has some examples for what this looks like with curl -- in the final example, notice how you can just "await" on a bunch of different things and let the runtime worry about coordinating all of them.
Not only a priori, but in terms of testing actual code and designing benchmarks as well - you have to make sure the right sections of code are hot, hitting the right levels, etc. It's extra mental load and work. (and if you're a JS developer, you may have to do this across multiple platforms). And oh, regressions and updates.
I'm not entirely convinced it's all worth it, but so far I'm begrudgingly accepting it.
Even the same compiler can behave differently just by changing the target CPU.
However, HHVM was generally between 2 and 5 times slower than vanilla PHP at rendering pages. In micro benchmarks it was way ahead, but running the whole application was a very different matter.
I decided to wait until the thing matures a bit more before trying again and then hopefully with more time to investigate the causes of this huge difference in performance.