More FAQs about JRuby and Sun
There's been a lot of buzz about Tom and my new jobs at Sun, and understandably so. The response so far has been overwhelmingly positive, and we're grateful for that. It's all very exciting.
There have been a few questions to come up again and again on blog postings and mailing lists, however, that I figured I could answer. Some are fear, some are uncertainty, and some are doubt, but almost all have good answers. I understand some folks have concerns and want to address those as best I can.
Note, my responses may not be Sun policy, but they're my policy. And I don't bend so easily.
1. Does the Sun move mean Groovy, Jython, BeanShell, and friends are being cut out of the picture? Has Sun chosen a winner in the dynamic languages realm?
Absolutely not, on both counts. I got involved in JRuby for one reason: Ruby was underrepresented in the Java world, and happened to be a very attractive language to me. Jython was fairly well-established and performed quite nicely. Groovy was gaining some traction and seeing an upswing in developer interest. JavaScript was scheduled to be included in Java 6. What about Ruby? JRuby didn't run most Ruby apps, had known major incompatibilities with C Ruby, and performance was very poor. Something had to be done.
I like to solve difficult problems, and JRuby certainly has presented some difficult problems. How do you take an existing interpreter that mostly works and--without breaking it--completely refactor and rewrite its internals to maximize performance and compatibility? Answer: very carefully. JRuby has come a long way this past year, and now we have leave to round things out on an accelerated schedule.
So what then? Naturally there's the tools angle (which I'll address in a moment), but will a JRuby 1.0 release mean the end for JRuby and continuing development of dynlangs on the JVM? Of course not! JRuby will continue to be a learning experience for all involved...inside and outside of Sun. Once we've solved JRuby's issues, why not find a way to raise all ships? Support for invokedynamic, open classes, and closures at the VM level? Hooks for code generation, alternative typing systems, and deeper threading, IO, and memory integration? Seamless cross-app connectivity for dynlangs + Java EE with all the tasty agility we've come to love?
This is only the beginning, my friends!
2. Sun has stated that Charles and Thomas have a mandate to think about/work on developer tools; does this mean Eclipse-based solutions are off the support list?
I want to make this perfectly clear...we will not discriminate between any users of JRuby. JRuby is a community project, first and foremost, and part of cultivating and growing that community is a rigid adherence to non-discriminatory support policies. We would be cutting off our right hand (or in my case, left hand) if we started picking and choosing who "deserves" support and help from the JRuby team. Nobody would benefit and everyone would suffer from such a move.
Of course, as Sun employees, we've got a major interest in ensuring NetBeans provides a world-class IDE for Ruby projects on the Java platform. But we were JRuby developers first, and we know that although we want people to migrate to NetBeans, we'll engender no community love by giving existing, mature Ruby IDE solutions the boot. Remember folks, competition is good. It would just be entirely unfair to deny NetBeans users the distinct joy of Ruby and Rails development. We're going to spread the love.
3. Will Charles and Thomas have to move to California?
Not at all. Tom and I will continue working from the Minneapolis area under Sun's remote-employee programs. You'll certainly see me and sometimes Tom at your favorite Ruby or Java conferences, but we'll continue to make home in flyover country. Moo.
4. Was this move in response to the IronPython 1.0 release this week?
Come on folks, you know how fast HR moves. You honestly think they could officially hire us in less than a month? This move has been in the making for several weeks..and man has it been hard to keep secret. I'm glad the truth is finally out and we can take a deep breath...before really getting down to business. (And really, for a move of this magnitude to only take "several weeks" is impressive by any measure...)
I wish the IronPython guys success...and Jim Hugunin is obviously in a similar position, doing what he loves. Hopefully our differing sponsorship won't get in the way of cross-pollenation and idea sharing. It would be a real shame if being hired to innovate by innovative companies actually hurt the innovation that got us here in the first place.
--
I'll plan to keep up with major questions as they come up. I really want this to be full disclosure, folks, as much as humanly possible. JRuby isn't my project or Tom's project--it's yours. You deserve to be in the loop (zero-day media blitz secrets notwithstanding, of course ;)
There have been a few questions to come up again and again on blog postings and mailing lists, however, that I figured I could answer. Some are fear, some are uncertainty, and some are doubt, but almost all have good answers. I understand some folks have concerns and want to address those as best I can.
Note, my responses may not be Sun policy, but they're my policy. And I don't bend so easily.
1. Does the Sun move mean Groovy, Jython, BeanShell, and friends are being cut out of the picture? Has Sun chosen a winner in the dynamic languages realm?
Absolutely not, on both counts. I got involved in JRuby for one reason: Ruby was underrepresented in the Java world, and happened to be a very attractive language to me. Jython was fairly well-established and performed quite nicely. Groovy was gaining some traction and seeing an upswing in developer interest. JavaScript was scheduled to be included in Java 6. What about Ruby? JRuby didn't run most Ruby apps, had known major incompatibilities with C Ruby, and performance was very poor. Something had to be done.
I like to solve difficult problems, and JRuby certainly has presented some difficult problems. How do you take an existing interpreter that mostly works and--without breaking it--completely refactor and rewrite its internals to maximize performance and compatibility? Answer: very carefully. JRuby has come a long way this past year, and now we have leave to round things out on an accelerated schedule.
So what then? Naturally there's the tools angle (which I'll address in a moment), but will a JRuby 1.0 release mean the end for JRuby and continuing development of dynlangs on the JVM? Of course not! JRuby will continue to be a learning experience for all involved...inside and outside of Sun. Once we've solved JRuby's issues, why not find a way to raise all ships? Support for invokedynamic, open classes, and closures at the VM level? Hooks for code generation, alternative typing systems, and deeper threading, IO, and memory integration? Seamless cross-app connectivity for dynlangs + Java EE with all the tasty agility we've come to love?
This is only the beginning, my friends!
2. Sun has stated that Charles and Thomas have a mandate to think about/work on developer tools; does this mean Eclipse-based solutions are off the support list?
I want to make this perfectly clear...we will not discriminate between any users of JRuby. JRuby is a community project, first and foremost, and part of cultivating and growing that community is a rigid adherence to non-discriminatory support policies. We would be cutting off our right hand (or in my case, left hand) if we started picking and choosing who "deserves" support and help from the JRuby team. Nobody would benefit and everyone would suffer from such a move.
Of course, as Sun employees, we've got a major interest in ensuring NetBeans provides a world-class IDE for Ruby projects on the Java platform. But we were JRuby developers first, and we know that although we want people to migrate to NetBeans, we'll engender no community love by giving existing, mature Ruby IDE solutions the boot. Remember folks, competition is good. It would just be entirely unfair to deny NetBeans users the distinct joy of Ruby and Rails development. We're going to spread the love.
3. Will Charles and Thomas have to move to California?
Not at all. Tom and I will continue working from the Minneapolis area under Sun's remote-employee programs. You'll certainly see me and sometimes Tom at your favorite Ruby or Java conferences, but we'll continue to make home in flyover country. Moo.
4. Was this move in response to the IronPython 1.0 release this week?
Come on folks, you know how fast HR moves. You honestly think they could officially hire us in less than a month? This move has been in the making for several weeks..and man has it been hard to keep secret. I'm glad the truth is finally out and we can take a deep breath...before really getting down to business. (And really, for a move of this magnitude to only take "several weeks" is impressive by any measure...)
I wish the IronPython guys success...and Jim Hugunin is obviously in a similar position, doing what he loves. Hopefully our differing sponsorship won't get in the way of cross-pollenation and idea sharing. It would be a real shame if being hired to innovate by innovative companies actually hurt the innovation that got us here in the first place.
--
I'll plan to keep up with major questions as they come up. I really want this to be full disclosure, folks, as much as humanly possible. JRuby isn't my project or Tom's project--it's yours. You deserve to be in the loop (zero-day media blitz secrets notwithstanding, of course ;)
Written on September 8, 2006