I don't see the point of HH. There are valid reasons to use php. IMO they are: A existing codebase and the fact it is installed everywhere.
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.
By fosap 13 years ago
Er, surely the whole point of the article is that they are making it so that more of the existing codebase will run.
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.
By RobAley 13 years ago
Newer PHP isn't too bad to program in, so long as everyone who ever will need to write a line of your code is relatively disciplined, and works to an agreed upon standard.
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.
By jeffasinger 13 years ago
I haven't seen a PHP codebase that didn't run on 5.2 in years. If you don't support 5.2, that means your code is at least eight years old at this point, with no effort at all to upgrade.
That's kind of scary. It'd be like captaining the SS Swiss Cheese.
By debacle 13 years ago
Sadly, I've seen companies that depend (like literally, if it were to fail the company would shut down) on a codebase that is on 5.0 :(
By andyhmltn 13 years ago
If you find "PHP a delight" you'd probably love a language with a sane design even more.
By astrodust 13 years ago
As someone who did make such a change, I agree with this. I'm assuming the parent did not intend it as trolling, as I don't.
By mildtrepidation 13 years ago
I wish there were more stories of people who've gone "post-PHP", talking about their experiences.
"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.
By jcroll 13 years ago
The shortcomings it tries to fix is the speed of the execution of the language, something PHP already gets better than other dynamically typed languages such as ruby. There's lots of good reasons to pick PHP as the language to develop A web application on and with HHVM in the mix the reasons will be greater still. PHP is a real programming language, if your greatest knock against it is the inconsistent order of function parameters then I don't really think you do have a knock against it unless of course you want to take the same swipe against C.
By jcroll 13 years ago
For projects the size of Facebook there's a lot of risk and not a lot of reward in rewriting the whole site. Instead of retraining all their developers to write in a new language and taking the time to stop all current development and begin the rewrite, they were able to have a few guys go off and make the current infrastructure faster.
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.
By maximilianburke 13 years ago
Don't forget the fact that PHP devs are relatively cheap. Especially compared to people capable and willing to learn your brand new homegrown language.
By michh 13 years ago
Python, Ruby, C#, and JavaScript are "homegrown" now?
By astrodust 13 years ago
No but people were suggesting that if they're writing their own VM, they might as well design a better programming language to use on it.
By michh 13 years ago
And the truth comes out.
By twistedpair 13 years ago
[deleted]
By 13 years ago
What are valid reasons to use PHP? Like, you don't care about your code or you have no availability SLA?
By AsymetricCom 13 years ago
It's a great language for quick prototyping or doing sysadmin tasks (i would choose php over any shell script language any day). I also see no evidence that php apps in practice are any less reliable. Php is in fact probably more reliable because it doesn't give you dangerous stuff like multi-threading and because its very forgiving of errors (it doesn't consider an error a good reason to stop running code).
By Joeri 13 years ago
Although it's not a feature that appeals to everyone, modern PHP (5.4+) has nearly any sort of syntactic/structural feature one would want in a programming language, except enumerations[0]. After using them in Scala, traits are also a nice plus to have in PHP. I do use PHP less than I used to, opting for Python more as it has more uses than PHP does (PHP can be used with GTK or CLI, but no thanks) outside of the web.
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.
[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)
If you want to use libevent/libev without coding the glue yourself, you can use React PHP (http://reactphp.org/), which supports timers, websocket/WAMP, ZeroMQ, HTTP (but not SSL), DNS, Redis (Predis async), and plain sockets.
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.)
By tmzt 13 years ago
Hmm, I've heard of React, but have not had a chance to look at it much or use it yet. Looks like it would be better than any of the other alternatives out there though for PHP with a similar feature set. Thanks for the recommendation.
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.
By yareally 13 years ago
I'm really excited that Facebook is stewarding in a new era of PHP. I would love it to see some of these framework maintainers (particularly fabpot and jwage) push their frameworks towards interop with HHVM.
The sooner we can abandon the backwards php.internals mentality of "Do things easy the easiest way possible," we'll see a much stronger language.
By debacle 13 years ago
Maybe HHVM will be like MariaDB and MySQL, HHVM will become the new fork and the current stewardship will be left behind with their troll mailing list. Either way I think HHVM is going to be a huge step forward for the PHP ecosystem, it's going to kick up some dust and we'll see where everything lies when it settles.
By jcroll 13 years ago
So am I right in thinking that HPHPc is around 6x faster than Zend and HHVM so far adds another 40%?
i.e. HHVM is currently 8x faster than Zend and still getting faster?
By sambeau 13 years ago
Yes, although that can be considered an odd comparison as technically at this point HHVM is not a PHP implementation (ignoring the incomplete stdlib and autoload bugs) due to things like
> CakePHP has a class named String. HHVM does not allow [...] for classes to have names of primitives.
and
> a method called setValue() that takes two parameters, [...] only one parameter is provided [...] HHVM does not allow this.
and
> HHVM requires classes that implement interfaces to be compatible with the interfaces they implement.
You can argue the HHVM language is a better language than PHP (not a high bar to set), but that makes HHVM not a PHP runtime.
By masklinn 13 years ago
I disagree. Currently there is no standards body that defines what is PHP, and thus the "official" PHP runtime is "simply" another runtime like HHVM (and others) that implements what it considers to be PHP. It's taken as the "defacto" standard simply as it was the first, and still largest supported, PHP implementation.
There is currently talk on PHP Internals (as there has been for some time, to be fair), of creating a PHP standards body to dictate the language. The "official" PHP runtime will (probably) then be written to that standard, and any other runtimes can conform to the standard (and be a "PHP runtime" as you define it) or not as they wish.
By RobAley 13 years ago
If a language developed as a runtime, and no standard has yet been defined for exactly how the language will behave, then that runtime IS the spec. See Perl.
In the meantime, if HHVM doesn't conform to some version of the PHP runtime, it doesn't conform to the PHP language (of the same version). The community could change this, either through defining a standard or accepting HHVM as close enough to be considered a PHP dialect, not a different language with similarities.
By kbenson 13 years ago
> If a language developed as a runtime, and no standard has yet been defined for exactly how the language will behave, then that runtime IS the spec. See Perl.
Nope, it simply means that there is no spec.
By RobAley 13 years ago
HHVM doesn't permit quite a few things that regular php allows, and it also turns into outright errors "bad" things that regular php treats as warnings because it thinks it can run despite it. I also don't think it supports eval(), although it may have changed since the last time I read about it.
When you remove the "I don't know, maybe, maybe not" part, you can make you code a lot more efficient.
(not making a judgment call here, just clearing things up on how it is possible to be that much faster)
By nolok 13 years ago
HPHPc, the static compilation version of the runtime, didn't support eval, because eval is not static :) With the JIT compiler and VM, the runtime now support eval and other more dynamic PHP features:
The outright language gaps to 5.4 are few and fairly obscure these days, in my opinion. Most practical problems are due to missing or slightly misbehaving extension functions, rather than the core language. You can write programs that produce different output from php.net if, e.g., they depend on the order that destructors are called when killing lots of objects at once, but you can also write programs that differ across minor revisions of php.net. In the absence of a standard, much like pre-standardization C, "PHP" is anything that runs useful PHP programs. We think HHVM qualifies.
HHVM lets you do eval(), and we try to do a decent job of running it fast. We do actually jit eval'ed code, though if you're running in whole-program optimization mode the presence of eval() will prevent lots of compile-time class hierarchy analysis based optimizations from working. Yes, yes, we should be optimistic and deoptimize when we're wrong, it's just easier said than done :).
Facebook disallows eval() in production code for reasons you can probably imagine.
By kmavm 13 years ago
> (not making a judgment call here, just clearing things up on how it is possible to be that much faster)
It's probably possible to be that much faster (on average and in good cases) even without throwing out huge swathes of the language.
See: javascript runtimes, they don't throw out the parts which bother them but they do deoptimize (or not optimize in the first place) code making use of specific constructs (e.g. `eval` or `with`, I believe V8 also used not to optimize functions using `try/except`, not sure if that's changed).
That means pathological code will run no faster on the fast runtime than on a standard interpreter, but it'll still run. And non-pathological code will run significantly faster.
By masklinn 13 years ago
For what its worth, HHMV does support eval. Other previous compilers in the HipHop range didn't.
By RobAley 13 years ago
It depends what you are running, but you are at the right order of magnitude. Our main measurements are from running facebook.com back when it could run on both HPHPc and PHP 5.2 and then extrapolating from there with any improvements.
By ptarjan 13 years ago
So wait, you're telling me that Facebook's PHP interpreter moves fast and breaks things?
By Pxtl 13 years ago
No just that HHVM doesn't yet support the entire PHP codebase
I'm on the Cake Core team. We're moving towards a 3.x release, which will be all PHP 5.4 compatible (namespaces, etc.) so the issue they point out in class loading will be non-existent.
We are discussing aliasing the String class to a CakeText class, and then deprecating the String class in a 2.5 release. If we had known this was an issue[1], then it would likely have made it into the recent 2.4 release.
Something that would be nice would be to see the method in which they ran the tests, so that we can include their testing into our TravisCI/Jenkins setup. Probably would help other frameworks/packages as well. Will file a bug.
[1]: They could and should have filed a bug. A cursory search of our lighthouse
issue tracker does not surface one, though admittedly lighthouse is pretty shit, so it may indeed be there.
By josegonzalez 13 years ago
The biggest issue I have had with HHVM is that the extensions are totally undocumented ( not like there is much for the Zend engine ). So trying to port over extension to it is a excersize in futility.
By dkhenry 13 years ago
Right now, I think documentation would be futile and also suffocating. Considering the stability of HHVM and its steward (Facebook), I expect things to break/change.
By debacle 13 years ago
If they want wider adoption they will need to document extensions. There are tons of extensions out there and I would say most non trivial installation use at least a few of them.
By dkhenry 13 years ago
I agree, I just don't think it's useful for them _right now_.
By debacle 13 years ago
We did some experiments with HHVM and discovered that our heavy reliance on both redis and mongodb meant no HHVM for us - it supports neither of those things.
If they could get php.ini support working, I'd be very pleased to leave php-fpm behind.
By nasalgoat 13 years ago
phpBB sports zero. Hopefully this will encourage a migration away from that mess and phpBB will end up on the dustbin of history. Please? Pretty-please?
Drupal's success is nice. I've run a Drupal site for a hobby project and performance wasn't stellar, so it's nice to know that Drupal might run well on HHVM.
By Pxtl 13 years ago
phpBB is being rebuilt using Symfony components
By jcroll 13 years ago
phpBB, vBulletin, and the rest of them should be loaded up into a rocket and fired into the sun.
Would it kill them to get someone to look over the UX of these things? WordPress has a user interface that, while tricky, does make sense. These "bulletin" products show their origins as some high-school kid's project to make a website.
By astrodust 13 years ago
I went to install HHVM to test my own code, but it turns out it's 64-bit only. Kind of sucks.
By rmccue 13 years ago
Is there any valid reason to run 32-bit systems in 2013?
By q3k 13 years ago
You don't always get to choose your architecture. Sometimes it's dictated by other concerns.
By astrodust 13 years ago
I wish there are a similar effort on Ruby VM.
By ksec 13 years ago
as long as I don't need to login on facebook to use it
By oridecon 13 years ago
I don't think the point of HHVM is to run things like phpbb. It is a tool for Facebook to run their own stuff on as fast as possible.
By programminggeek 13 years ago
? This blog post was written by the authors of HHVM, do you know something they do not?
EDIT: I should add, the last time i talked with sgolemon she said (half jokingly) that their goal is to replace zend (engine)
By fosap 13 years ago
By RobAley 13 years ago
By jeffasinger 13 years ago
By debacle 13 years ago
By andyhmltn 13 years ago
By astrodust 13 years ago
By mildtrepidation 13 years ago
By astrodust 13 years ago
By jcroll 13 years ago
By jcroll 13 years ago
By maximilianburke 13 years ago
By michh 13 years ago
By astrodust 13 years ago
By michh 13 years ago
By twistedpair 13 years ago
By 13 years ago
By AsymetricCom 13 years ago
By Joeri 13 years ago
By yareally 13 years ago
By tmzt 13 years ago
By yareally 13 years ago
By debacle 13 years ago
By jcroll 13 years ago
By sambeau 13 years ago
By masklinn 13 years ago
By RobAley 13 years ago
By kbenson 13 years ago
By RobAley 13 years ago
By nolok 13 years ago
By elgenie 13 years ago
By kmavm 13 years ago
By masklinn 13 years ago
By RobAley 13 years ago
By ptarjan 13 years ago
By Pxtl 13 years ago
By jcroll 13 years ago
By johnx123-up 13 years ago
By josegonzalez 13 years ago
By dkhenry 13 years ago
By debacle 13 years ago
By dkhenry 13 years ago
By debacle 13 years ago
By nasalgoat 13 years ago
By Pxtl 13 years ago
By jcroll 13 years ago
By astrodust 13 years ago
By rmccue 13 years ago
By q3k 13 years ago
By astrodust 13 years ago
By ksec 13 years ago
By oridecon 13 years ago
By programminggeek 13 years ago
By lacksconfidence 13 years ago