Nice. The 2-3x improvement is about the same that I've seen in preliminary tests with HHVM on a JSON API in ZF2. There are still many extensions that are not ported at all, something Box didn't run into but I have. These are lesser known extensions, but they can throw a wrench in the migration works. I would definitely check the status of all extensions and as the article mentions, test their code most extensively.
My biggest problem still is getting xDebug working with HHVM, something that after a few days of trying I have given up on once again (as of a couple of months ago). Unfortunately, a procedural or OOP language without a proper debugger (hphpd doesn't count) is pretty useless for real-word development. I know the HHVM team is constantly working on improving the ecosystem, so hopefully at some point, we'll have a real debugger that runs without crashing. Once that happens, I can definitely see rewriting the sections of the app that use extensions not yet ported to get the app ready for deployment on HHVM. Right now, the only reason we haven't done so is that we do want to compare both HHVM and PHP7 to see which one will yield the best performance.
Twitters problems are architectural, telecoms-scale ones. Rails is unlikely to ever be suited for problems like that, and it feels like any attempt to make it so would neuter some of the benefits it offers elsewhere.
On the other hand, PHP is just a language and doesn't enforce architectural style. A much better option for this sort of thing, IMO.
I think a big issue was at the time mainstream ruby was 1.8 and upcoming versions 1.9/2 would later replace and create a minor python2/python3 type issue where many later organizations using ruby 1.8 did not upgrade to 1.9/2 not until just recently, causing a kind of stall in patches contributions to what is now 2.2
That said many of the ideas from twitters work and others is now in ruby.
They have for at least parts of their infrastructure but there was a time where they were heavily invested in Ruby on Rails just like Facebook and PHP. They could have chosen to work on the framework and Ruby itself to make things better, they chose to move on to greener pastures instead. As a Ruby developer I regret that didn't "pull a HHVM", would have made my life easier, just HHVM and the whole FB/HHVM/Hack ecosystem is making PHP devs' life easier.
Are you just after a faster Ruby? We're working on an implementation of Ruby that is often an order of magnitude faster than anything else out there http://www.chrisseaton.com/rubytruffle/.
Or is it the typing and other infrastructure you wanted?
In the general sense I am absolutely after a faster Ruby. I am also after a Ruby with better tooling, better error handling and all bells and whistles. I'm following your development on Ruby Truffle with a lot of excitement, but like most Ruby / Ruby on Rails developers, the only thing that I wish is that I can just switch the Ruby and have it work exactly the same, except faster/better/stronger.
From what I understand JRuby/Truffle is closing the gaps at a nice pace (your recent tweets on constant folding is even showing that you're aiming not only for feature parity but for feature parity AND MOAR and that's awesome), but with existing applications and associated gems and all the implication of having to switch my Ruby to another slightly more exotic one, the thought is currently a source of anguish (because a lot of the existing ecosystem is extremely tied and tailored to MRI for better of for worse). I'm simply waiting for the time where I can just replace a line in my Gemfile and reap the benefits.
That being said, I would like to thank you for all the efforts you're putting in this, the blog entries, the Ruby Bibliography and all its promising research on making the Ruby ecosystem better, the benchmarks and overall collaboration with the folks at JRuby and I hope we get to see lots of good things in the future from your end.
Yeah we're going for being indistinguishable from MRI (unless you want to use the extra features). We even have a simple statically linked build that does not require a JVM, so that you're just running a simple binary like in MRI. That coupled with our support for MRI's C extensions is our strategy for MRI compatibility.
We've not blogged in a while but there were papers at PDLI and ICOOOLPS in the last few weeks. Since this time last year we've hired three new people to the project. We're running simple web frameworks like Sinatra and simple database drivers like Redis. Hopefully we'll have a big update at RubyConf.
Thanks a lot for the heads up on Crystal. The language looks close enough to Ruby that I immediately feel home, yet looks slightly different (and somewhat lower-level it seems).
FYI, PHP 7 (which is in beta status) is close to HHVM now, speed-wise (using Drupal, Wordpress, Symfony, etc.)[1][2], and it also includes many of the features HHVM + Hack added onto PHP in the first place.
Not 1:1 feature parity, of course, but a lot of people who were testing/considering a move to HHVM/Hack have reconsidered now that PHP 7 fixes many of the language's pain points.
Some of Hack's features such as return type declarations and scalar type hints will be in PHP 7 due to be released later this year.
PHP 7 also includes some serious performance improvements, contextual parsing, anonymous classes, combined comparison operator, null coalese operator and tens of other new features.
And yet, there's plenty of other, existing, proven languages out there that have had types and those tooling (beyond the 'basic') out there.
I'm not looking for a language battle here, but is inventing your own language based on your favorite language to bring common features from other language really such a good idea?
If you have an existing codebase in PHP, Hack provides a backwards compatible way to improve the state of things.
I have experienced both cases: a conversion of a large codebase from php to Hack and also a conversion from php to rails. Pick the right tool for the right job.
> I'm not looking for a language battle here, but is inventing your own language based on your favorite language to bring common features from other language really such a good idea?
My biggest problem still is getting xDebug working with HHVM, something that after a few days of trying I have given up on once again (as of a couple of months ago). Unfortunately, a procedural or OOP language without a proper debugger (hphpd doesn't count) is pretty useless for real-word development. I know the HHVM team is constantly working on improving the ecosystem, so hopefully at some point, we'll have a real debugger that runs without crashing. Once that happens, I can definitely see rewriting the sections of the app that use extensions not yet ported to get the app ready for deployment on HHVM. Right now, the only reason we haven't done so is that we do want to compare both HHVM and PHP7 to see which one will yield the best performance.