Charles Nutter Responds: our full-time responsibility is a solid JRuby 1.0

by Tim O'Brien

Charles Nutter responded to the responses in my last blog entry. Looks like he has answered my primary concern - that he's being hired into the NetBeans team to work on NetBeans at the expense of JRuby, the first section, clears that up 100%:

CHARLES:Looks like I'm coming into this one a little late...but I'll bite.

1. JRuby is secondary to NetBeans

Totally false. The principals at Sun...ALL the principals...have made it clear that our full-time responsibility is a solid JRuby 1.0 that can run the big popular Ruby apps (i.e. Rails, which necessitates Rake, IRB, RubyGems, Mongrel, and others). I've even gone as far as to say "I'd love to also help out language X" or "I'd also like to devote some cycles to working on C Ruby" and been told that JRuby should be my top priority. Time and time again, Sun folks are telling us and the general public that we're being hired to work on JRuby first. Trust me, if it weren't so, I'd tell you. I didn't leave one fulltime job that took away from JRuby to join another.


more response below the fold...

5 Comments

Henrik
2006-09-10 17:07:35
I'd rather focus on another aspect of the multi-language support of JVM. Recently I read about IronPython performance on CLR. Apparently it does amazingly well. Apart from skewed benchmarks I can imagine a couple of reasons why it might outperform the native implementation, but I was annoyed to read that it outperformed the JVM implementation by a significant margin.


So I hope Charles will work with the JVM experts to define the state of the art for making high performance scripting languages on the JVM. Hopefully it will also inspire performance improvements for dynamic/introspection operations.

Tom
2006-09-11 06:06:22
Charles -- congrats.


I agree wholeheartedly that the JVM needs a dynamic language, and for that I'm grateful Sun has given you professional support.


My concern though is this -- how do you plan to effectively bridge the two worlds (Ruby and Java) without having ugly seams wherever they meet?


What about overlapping APIs? If I have a Ruby lib that I want to use, that depends on a bunch of other Ruby code that does the exact same thing as my company-standard codebase of Java libraries, am I stuck with importing all of the duplicated Ruby code? Does Ruby have some magic that makes this easy to handle? What if I write code in JRuby that explicitly depends on Java libraries? Then it's not really portable.


I'm afraid of entering the MS C++ vs. Borland C++ vs. GNU C++ syndrome... They're all C++ but none of them are really the same.


Besides that, are there concerns that down the road the Ruby language will change and implement something that just doesn't fit under the JVM? Or vice versa? Is there a possibility that Java will create some paradigm that just doesn't fit well in the Ruby language?


The closest example I can come up with is .NET Annotations in IronPython -- As I understand, Python just doesn't support the notion (at least right now) hence there's a bunch of .NET stuff that can't be effectively used in IronPython simply because the paradigms don't match up. Please correct me if I'm wrong b/c I'm not an expert on this. This is why I might support Boo over IronPython if I wanted a dynamic language in .NET.


I'm concerned that JRuby will continually be playing catch-up and fighting to maintain compatibility. I would hate to always need to apply patches to run Ruby framework X in JRuby. Not that I have any lack of confidence, but this is generally how porting goes. It seems to always be a few steps behind the 'native' solution.


Thanks and best of luck in your work.

cooper
2006-09-11 09:52:58
While I share your opinion of Groovy as a language, the one thing that stands out vs Rails is the fact that it does at least work with JPA and other "Java" frameworks. While the idea of a mixed Rails/Java environment isn't unappealing, it would be nice to see a Rails with a little more of a Java flavor to it, using generated JPA packages for persistence, so the code can easily be shared.


All in all, I think Charles' new digs will be a boon for Java, but the road to the future is not a straight line and there are a lot more decisions to be made.

Ron Pomeroy
2006-09-14 10:58:13
I agree with the sentiments Charles expressed.


As a long time Smalltalker (note the correct capitalization :-) ) I never completely warmed up to Java - though I used it successfully for years now. I say "successfully" but much of the Joy of Programming I experienced in my Smalltalk career have become a distant fading memory.


That said - I do have a great deal of respect for the JVM - especially some of the more recent work that uses internal feedback mechanisms to self-tune GC - and I know there's more interesting stuff in the future.


In the short time I've been doing Ruby I've begun to get back some of that earlier joy.


JRuby at the language and library level...


Personally I'm less interested in bridging Ruby and Java at the language and library level. As in Smalltalk, block closures and mixins lead to a very different approach library design. With Mixins you extend the system wherever it makes the most sense - not just by subclassing. I see a big impedance mismatch between the Java way and the Ruby way. It's the same thing I saw when I started Java after doing Smalltalk.


What I really want out of JRuby is a scalable highly performant runtime for Ruby - That's it. Providing a facility to call or subclass Java is fine - I just hope it doesn't hinder a pure Ruby development experience.


Thanks Sun for the official support of Ruby.


Ron

prashant
2007-01-25 02:44:02
Charles,


Great work in Ruby. Yesterday i downloaded JRuby and started seeing inside the language.I am a fan of programing languages and currently involved in java from 3 yrs.


Cheers
Prashant-Vijayawada


Very eager to watch how jruby gets the hype and respect from developer community.


All the Best and Good luck.