A tool like HipHop will become the defacto runtime for php, when it combines its compilation with its runtime in an on the fly JIT compile. Then you get your deploy model back (just edit and reload), and the performance gains. Keep your deployment scheme, keep your language… get performance gains. Win win win win win. Am I missing something here? The community needs to jump behind this.

I don’t understand why people keep saying things like “this is nice but its only for those who are cpu bound” and “other parts of web applications could be better optimized”.It seems like an argument built for misdirection. If you could improve php by 50% you could (theoretically reslice the hardware) and shut off a large chunk of the internet with no lost capacity. Sure, the apps will still be IO bound, but for the ones that required more than one httpd to fire up all those hungry mod_php’s they will now need less boxes, less cpu, and will get to dispatching those IO requests faster, and processing the results faster.

Yes. I’m saying we’d need less power plants. This is a big deal.

Side note: Wt (http://www.webtoolkit.eu/) is a very descent native C++ web toolkit.

A lot of the decision on language (and prototypes) comes down to a decision on technical debt. If you’re using PHP, you’re incurring some debt by developing with a slower language at runtime. But you’re avoiding other debt by being able to develop, test and deploy quicker.

HipHop, to me, is a code debt refinancing tool. Used well, it could save you. Used poorly, you’re not paying down the debt at all, or possibly even making it worse.

(Aside: If there was a selection of good C++ web frameworks/libraries, HipHop may not have been as necessary.)

I’m curious to look at HipHop for one-time translations from PHP to C++ and then maintaining the C++ code from there. By the sounds of it, though, that’s not how it’s being used at FB.

Also, if you can do per-class translation or run a fully compiled app but then plug in individual classes in PHP, it could be pretty nice from a rapid development standpoint. I assume that FB is doing this.

I understand what you’re saying about picking the wrong tools, but now that HipHop exists, it seems there are fewer reasons not to use PHP (or Rails => JRuby). While you can claim Facebook made a mistake, their resolution means other startups can’t make the same mistake. In general, I think we should be working toward brining scalability to the most agile language, as there is a clear value to doing so (the same can be said of projects like Grails, the other way around).

Ultimately I don’t see much sense in objecting to something feeling like a “hack”. What is a hack, but a rift between dogma and implementation? Programming languages are tools, not philosophies. We shouldn’t allow ourselves to be limited by the aesthetics of a technical solution.

So maybe “discard prototypes” is too strong a phrase. But I think there’s a value to remaining objective here, to reviewing, and to entertaining the idea that maybe the technology that started it all is actually limiting the solution. For example, the way the Twitter folks said, (something like) “you know, we actually needed long-running processes [and Ruby had a hard time with that]“.

Obviously, it’s purely inflammatory to suggest that PHP is a good prototyping tool ;) — I’ve certainly deployed plenty of production code on PHP. But I think there’s a valid point missing in a lot of this HipHopped-up retoric, which is: revisit your prototype decisions. And maybe even, if you can afford it, “throw away your prototype”.

Prototyping, in general, is always the worst reason to adopt a language because, in practice, it’s a lie. It was a lie when people said it to get in the door at Yahoo! and various enterprise places (and then became entrenched), It‘s a lie when people argue for Rails development (and then had to hire consultants), etc. It’s even a lie in most RAD tools—when you use prototyping to build a UI, you either never leave/break it (Interface Builder), or you drop it once the part you needed has been built (Windows Forms Designer).

To be fair, Michael, I never suggested Facebook should have *started out* writing code in Java. I am a huge fan of prototypes and I concur that PHP (like Rails) is a good prototyping framework. I do, however, want to suggest the possibility that the PHP version also have been treated as a prototype. I believe it’s important to be able to discard prototypes. It feels like HipHop, more than anything else, is about holding on to a prototype. (Granted that’s really unfair in FB’s case, given the amount of third-party code out their that’s written for that “prototype”.)

Anyway, while I’m ok with Aaron’s opinion of me being puritanical & naive, I do want to make it clear that I’m not against HipHop or Facebook — or any of Facebook’s open-source tools. I do think that it provokes some good discussion about prototyping and choosing the right tools for a job, though, and I feel those are worth discussing.

Deep down, I think I just feel strongly that the reason to choose PHP is the deployment paradigm and *not* the language. So, I just don’t see a reason to use a tool like HipHop other than rescuing an ailing PHP application.

*Had* they started with Ruby, it does seem likely that they could have moved to leverage JRuby on the JVM and they could have used existing tools rather than having to rebuild the compiler/engine themselves. At the end of the day that does /sound/ like it would have been cheaper. Of course, hindsight is 20/20. I’m more interested in how other people choose to use HipHop than how Facebook uses it; I’m sure it makes perfect sense for them. I just think it’s important to say “prototypes should be thrown away”.

I know you’re a PHP guy, but I want to point out that Rails really does offer a tremendous advantage here. While it is much more resource intensive than PHP, it can be compiled into Java relatively easily for instant, long term scalability.