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…
The next section weighs in on a secondary conversation which can be summarized as people taking offense at my opinion that Groovy has some serious limitations after someone says that there is little reason for JRuby when we have Groovy. Anyway, that’s what triggers the first pragraph, but in the next few paragraphs he offers a good reasoning behing why the Java platform really needs a dynlang solution.
CHARLES: 2. JRuby vs Groovy, Rails vs Grails
You guys can be pretty single-minded sometimes.
Groovy is Groovy. Ruby is Ruby. I like Ruby. Some of you like Groovy. The same can be said for Rails. I can’t say (and certainly wouldn’t presume to say) Groovy is a failure or the wrong language any more than you can say Ruby is the wrong language. It’s about choice.
Think about it this way: In the UNIX world, there are two types of languages. C and everything else. The heavy lifting is done by C code…the kernel, the drivers, the libraries. In some cases, applications are also written in C…particularly where requirements demand a staticly-typed bare-metal language. In the other cases, folks use the other languages. Perl. Python. Tcl. Ruby. sh variants. Scads more. It’s not unreasonable to say that UNIX variants simply would not function without those “other languages” tying it all together.
Now look at Java. The Java platform provides a kernel, drivers, and libraries, all written in Java (or in some combination of Java and C/C++). For years, everyone (including Sun) has pushed that everything should be written in Java, and that only Java deserved to be supported on the JVM. So the story ended there, and for millions of Java developers, dynlangs remained interesting toys not to be used for real work.
I dare you to tell any UNIX admin or developer they can only ever use C for anything from now on. You better be wearing body armour.
When you look at the facts, the emphasis on Java alone has raised a half-generation of developers trying to build UNIX systems with only C…trying to build a house with a hammer. The very notion is absurd. It’s just as absurd to say there should be one true dynlang on the JVM, be it Groovy or Ruby or Python or anything else. We are craftsmen, if not artists, and no craftsman will claim that a single tool can do everything.
So I ask you these few questions:
1. Should there not be a Ruby implementation for Java?
2. Should we not try to make Rails run and integrate with as many Java frameworks as possible? (We already have extremely compelling tie-ins with JDBC and JMX…and the possibilities are endless)
3. After fighting for alternative languages to curry favor with the development community, does it make sense to claim our language is the one true choice? And the same question with alternative web frameworks?Come now, friends. We’re smarter than that.
My Note: I have opinions, I’m not going to censor them because people don’t like them, and I welcome the fight. I use Groovy, but I don’t like it, and I don’t recommend it very highly. The project lead of Grails thinks it’s unfair, I’m not suprised. To you, the read, Apologies if that’s not an opinion you agree with. I’m not touting ruby as “the one true choice”, but I am definitely saying that Groovy has some limitations and I’d prefer my scripting language to be something like Ruby or Python, not a hybrid approach. If you disagree, then join the discussion.



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.
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.
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.
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
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.