HHVM + HACK + XHP is an entirely different experience compared to writing PHP. Code can actually be very clean and lots of bugs can be found that may have previously gone unnoticed + performance benefits.
Just wanted to say FB is doing an exceptional job with these projects.
Notice: what works in UNIX utilities is not what works for web apps serving many users simultaneously. In fact, I'm pretty sure this doesn't work for UNIX utilities either and is just something you should never touch with your libc. It's like calling non-reentrant strtok, some of this stuff just doesn't exactly fit into todays world.
If you look at the changelog, you can see it really is a beta product that people use in production anyway
https://raw.githubusercontent.com/facebook/hhvm/master/NEWS
"Ditko" 26-Feb-2015 finally solved me having to restart it every several days
I'm very eager to compare PHP7 in production
It was quite frustrating because I noticed some definite performance gains (e.g., ~2x faster page loads, etc.), but ultimately opted for PHP's stability.
The benefit to running all this in Docker is that I can swap HHVM back in relatively easily (unless it's changed really dramatically over the past 10 months or so). Your comment has me tempted to give it another shot!
Apparently this still happens but instead of several times per month, it is now a couple times per month.
Sigh, well PHP7 is right around the corner.
EDIT: Removed mention of "shared-nothing", which I misunderstood.
We do have other contained infrastructure that is written in some other languages like go and scala.
I'd personally be curious if they experimented with Go lang for this. Low memory, fast startup, fast at run. It makes more sense to use another language for bespoke than anywhere else in their stack, at least from my limited external viewpoint that is :)
It also means deployment will be different.
While the technology might make more sense, there's often enough reasons to not use it if you've specialized into a certain ecosystem.
However, if I'm able to hang back and take some time to develop something, priorities like being able to handle X I/O writes or, as you point out, threading becomes more relevant.
I think that it's easy enough to get a site running entirely on PHP--well tested, well supported, architecturally sound, and rewrite services into <noninterpreted-language-of-choice> as you hit performance bottlenecks.
If performance is absolutely critical to your app, then you may consider writing everything in Java/Go/C++, but it's pretty brutal for doing templating and whatnot. Besides, once you generate the page, there's a good chance you're going to cache a good part of it anyhow!
So if you have the chance to start fresh: choose Java or Go. Or anything else... (define "performance"?)
Node/IO.js and Go have their advantages, especially if one wants to use WebSocket.
Nowadays, half of the code is client side anyway (be it HTML5 JS (maybe with React/Angular) or mobile apps) - in such cases the server output and receives a lot of JSON. And then Node.js/Go/HHVM are about equal as good in benchmarks, at least in my personal benchmarks (10.000 -100.000 requests/s with Apache AB tool).
It's come a long way and I'm excited to see further improvements.
Last time I checked PHPs own tests only had about 30% coverage, and with a famously idiosyncratic language like PHP, which apparently needs a massive internal overhaul to increase speed, that seems less than optimal.
I thought the test suite was one of the best things to come our of multiple ruby implementations, though I read recently that core Ruby ignore it and so regularly introduce bugs that it would catch.
what editors do people that are using HHVM use?
That is Hack.