At Foo Camp this past weekend, Steve Yegge of Google gave a talk called "Google Rails Clone" where, as John Lam reports, he talked about his experience porting Ruby on Rails to Javascript at Google:
In an effort to increase developer productivity at Google, Steve tried to convince the company to adopt Rails (and consequently Ruby) as a programming language. When that fell on deaf ears (Google really does not want to increase the number of languages that must be supported by their infrastructure), Steve decided to do what any other frustrated programmer would do: he ported Rails to JavaScript. Line by line.
This is clearly something that caught the interest of the software development community, with reactions that run the gamut. The effort reminded some of other projects, particularly TrimPath Junction, another attempt to reproduce Ruby on Rails in Javascript, but also Phobos and Helma. Many saw this as confirmation that Yegge's Next Big Language is Javascript or ECMAScript, and made reference to Steve's recent Marshmallow and Rich Programmer Food posts. Some pondered the connection to .NET on Rails, and some questioned the effort. Steve has since updated his blog with more details.
InfoQ took the opportunity to speak with Steve Yegge, who was kind enough to answer some questions about the effort, but was quick to point out that he speaks for himself and his opinions, not for Google as a whole, and that those reading this should not infer any deep Google-spanning conclusions.
First and foremost, many of you have asked how you can get your hands on the project; whether and/or when this effort would be made public and/or open-sourced. Steve said this was something they've talked about and may consider in the future, but that it wouldn't be likely to happen soon:
We've talked about open-sourcing our "Rhino on Rails", but so far it's been no more than idle chit-chat. For one thing, work on the framework plays second fiddle to work on the actual application, so it's progressing slowly, mostly as 20% work. For another, we're dependent on various other Google infrastructure components that are themselves in the process of being open-sourced, although I don't know if any of them have been announced yet.
The real key, though, is watching to see what happens in the Rails-ish web framework space on the JVM. There are plenty of other Rails clones out there in varying stages of maturity, including JRuby on Rails, Grails, Phobos, TrimPath, and probably half a dozen others.
If one of them emerges over the next couple of years as the dominant player, and it meets Google's internal quality bar for security, performance, scalability, internationalization support, and so on, then we'd be fools not to consider the possibility of migrating to it.Maybe it'll be big, and maybe it'll be a throwaway that never makes it outside our team, let alone out the door as open source, but I think we're years away from knowing either way. Platforms take a long time to mature, and the web-framework space is really churning right now.
Hence, any public-facing release of it is dependent on the open-source market conditions over the next 2 to 3 years, and also depends on how well the thing catches on internally at Google, which we won't know for a year or so
On Rails, and the whether or not Rhino on Rails is a 'port' or simply a framework inspired by rails:
As it happens, I kinda like Rails. I like Ruby, too, independent of Rails. But for making web pages, Rails is the nicest thing I've used. And given the surprising number of titles available about our heroine Rails and her mute little woodland creature sidekicks Prototype and Scriptaculous, not to mention the vast number of Rails clones out there in other languages, I'd say DHH was really on to something unique and significant when he created it. Kudos.
On the subject of whether or not it was a 'port' or a Javascript framework inspired by Rails:
it's as close to a true port as I could get, given restrictions of the JavaScript language, but only of the ActionView and ActionController parts [and Railities], not ActionMailer ... plus a teeny bit of ActiveRecord, although for the most part we were already constrained in how we talk to our backends. Long-term, I think the story is going to be Hibernate. But we've gradually been extending it to have better performance, security, and i18n support than Rails, so the delta is still fairly significant, and a Rails book only gets you maybe 60% of the way to being proficient with the framework ... We've also been building some nice tools support, including spiffy debuggers and other IDE functionality for Eclipse and Emacs.
Talking about why he didn't just use Ruby on Rails directly:
Programming languages are surprising little beasties, something akin to having your own 100% tame pet Siberian Tiger. You tend to think the two of you are getting along quite nicely, but for languages as expressive as Python, Ruby or JavaScript, you've got to exercise tremendous discipline or they can bite pretty hard. You have to consider what the experience is like for casual users who need to work in your environment for a while. Limiting the number of languages is the first step towards making it easier for everyone internally to contribute to any internal code base they like (e.g. as 20% work) without fear of falling victim to unexpected language semantics.
Each language you "officially" support at a company has a pretty heavy tax -- infrastructure support, documentation, training for devs, code duplication, and other downsides. [P]rogramming languages have a core of standard functionality that everyone knows, followed by a long tail of murky semantics that become increasingly difficult to figure out, especially for dynamic languages with no actual spec like Perl, Python, Ruby and their ilk. Google very prudently keeps the number of languages as small as practical, so that we can build up large groups of experts on the semantics of the languages we've chosen. One of the reasons Google's code base is so clean and homogeneous is that they've standardized on C++, Java, Python and JavaScript as the only official languages for production work. It's also to cut down on the combinatorial explosion of components required for language interoperability.
So I couldn't use Ruby. I needed to be on the JVM for interoperability with the rest of our code base. (Take my word on this one -- it's not something I could have solved by RPC calls; I needed to be running on the JVM itself for this.) Being on the JVM rules out C++ and (native) Python.
Between the choice of JVM languages, Steve Yegge describes the choice between Java, Jython and Rhino:
Looking at the Rails APIs, which typically pass around hash literals as parameters, it didn't seem like Java was going to be a particularly good match. Ruby has no method overloading, and both Ruby and Rails have all sorts of conventions for passing varargs or block (function) parameters. Java's different enough from Ruby that the impedance mismatch might have killed the effort, so I decided to stick with a dynamic language.
Jython seemed like the obvious choice at first, except that it hasn't had much momentum since around 2001. It used to be arguably the best non-Java JVM language around; Jim Hugunin did an amazing job with it. Unfortunately it's had almost no love in the past six years, and it's now lagging the Python spec by several major versions (2.2 vs. soon-to-be 2.6).
Rhino, in contrast, has a great deal of momentum. It's been around even longer than Jython; it began life as a port of the SpiderMonkey (Netscape/Mozilla) JavaScript C engine, and it was written with an eye for performance. The Rhino code base reads almost like C code: it avoids allocation and does as much as possible with jump tables to avoid the overhead of virtual method lookups. It has two code paths: a bytecode interpreter that runs in a tight loop, and an optimizing Java bytecode compiler that turns many expensive-ish JavaScript property lookups into Java local or instance-variable lookups. It's a pretty serious piece of software.
And on the subject of JVM languages in general:
You also have to factor in the delta in semantics between a language and its JVM implementation. Most dynamic languages don't have particularly rigorous specifications, and the JVM implementation often differs in undocumented ways from the C implementation. One of the things I really like about Rhino is that JavaScript really does have a spec (ECMA-232), and Rhino does a first-rate job of documenting places where it differs from ECMA (e.g. its multi-threading semantics.) Even so, there are still JavaScript-Java bindings to consider, and while Rhino's are reasonably well-documented, it's still taken us some time as a team to work through the edge cases and really figure out how things like type-mapping and overloaded-method invocation work. For any given JVM language, you have far fewer experts worldwide than the corresponding C implementation has. From this perspective, introducing JVM languages entails more risk than introducing their original counterparts, offsetting many of the gains you realize from library interoperability and Java support infrastructure.
Steve Yegge has released more information on his blog, so read on there, and stay tuned to this thread at InfoQ.