It's not that obscure. Anyone with an ounce of experience in PHP can start writing solid Hack on day one. And that would still be true even if Hack were never seen in the wild.
Unless you think it's hard changing the open tag from <?php to <?hh :p
Our internal plumbing is different, so the extension APIs aren't the same, thus PHP extensions can't normally be used with HHVM. Paul has a source-compatability transformer which works for simple extensions (no fancy stuff allowed), but we recommend anyone with an extension consider porting the code.
If your extension is one of those "This was written in PHP but we wanted it to be faster so we turned it into C" types, you should consider going back to PHP for it. In practice, we find that HHVM can JIT PHP code into running about as fast as (sometimes faster than) C/C++ extension code.
If you do need to dip into C/C++ (because you're calling an external library), the API we've designed is a LOT easier to work with than PHP's. And I say that with the authority of having written THE book on writing PHP extensions: http://amazon.com/dp/067232704X .
As the author of pretty much THE book on writing PHP Extensions ( http://amazon.com/dp/067232704X ), I can say with a fair bit of authority that writing HHVM extensions is SO SO SO much easier.
On the scale of a single request (doing stuff from the command line), most benchmarks I've seen are about half the memory footprint. Obviously that's going to vary program to program ($data = file_get_contents("some2gbfile.txt"); is going to take 2GB, regardless), but for "normal usage" 1/2 looks fairly common.
On a webserver, that goes further since HHVM is single-process/multi-thread, whereas PHP (in its typical setup) is multi-process/single-thread. This cuts HHVM's memory overhead much further.
Yes, PHP can run multi-threaded, but it still has a number of instability issues in that mode.
HHVM developer & PHP runtime developer here. I've got hands in both runtimes and all even I can say is: Maybe.
I think the most likely outcome is that PHP will adopt some of HHVM's additional features, but remain a separate project. IMO that's a great outcome, since we'll both likely drive the other to be better.
Do not want. Do not need. GTFO