I'm going to be speaking about JRuby again this year at eRubyCon, in Columbus OH. I just got back from Rails Underground, which reminded me how much I love the smaller regional Ruby conferences. So I'm totally pumped to go to eRubyCon this year.
The idea of "Enterprise Ruby" has become less repellant since Dave Thomas's infamous keynote at RalsConf 2006. There are a lot of large, lumbering organizations out there that have yet to adopt any of the newer agile language/framework combinations, and Rails has most definitely led the way. I personally believe that in order for Ruby to become more than just a nice language with a great community, it needs to gain adoption in those organizations, and it needs to do it damn quickly. JRuby is by far the best way for that to happen.
There's another aspect to adoption I think has escaped a lot of Rubyists. In 2006 and 2007, Ruby gained a lot of Java developers who were running away from bloated, over-complicated frameworks and the verbosity and inelegance of Java. When I asked at Ruby conferences in 2005, 2006, and 2007 how many people had done Java development in a former life, almost everyone in the room raised their hands. When I've asked the same question in 2008 and 2009, it's down to less than half the room. Where did they go?
The truth is that the Java platform now has reasonably good answers to Ruby in Groovy, Scala, and Clojure, and reasonably good answers to Rails in Grails and Lift. And yet many Rubyists don't realize how important it is for JRuby to continue doing well, many still seeing it as simply "nice to have" while dismissing the entirety of the Java platform as unimportant to Ruby's future. It's an absurd position, but I blame myself for not making this case sooner.
I believe that JRuby is the most crucial technology for Ruby's future right now. Regardless of how fast or how solid the C or C++ based Ruby implementations get, the vast majority of large organizations are *never* going to run them. That's the truth. If we can leverage JRuby to grab 1-2% of the Java market, we'll *double* the size of the Ruby community. If we completely lose the Java platform to alternatives, Rubyists may not have the luxury of remaining Rubyists in the future. It's that big a deal.
So I hope you'll come by eRubyCon and hear what we've been working on in JRuby and what we have planned for the future, especially our work on making JRuby a stronger JVM citizen. I'm certain to expand on the Hibernate-based prototype code I showed at Rails Underground, and hope to have some additional, never-before-seen demonstrations that will shock and amaze you. And if there's time, I'll demonstrate my two research pets, the "Ruby Mutant" twins Duby and Juby.
See you there!
32 comments:
"When I asked at Ruby conferences in 2005, 2006, and 2007 how many people had done Java development in a former life, almost everyone in the room raised their hands. When I've asked the same question in 2008 and 2009, it's down to less than half the room. Where did they go?"
Um... it's not less Java people, it's more other people. Hypothesis: If you'd asked the same question about PHP, you'd get a mirror-image change in results.
Tim: I think you're wrong. The percentage matters a lot. Ruby's community is not growing so fast that a drastic disappearance of former Java developers means only that there's a lot more people that have never used Java. I'm convinced it means that a large number of those Java devs are going *back*, and because of alternatives to Ruby/Rails on the JVM we're not getting as many new folks.
Even if you don't accept this analysis, you and other Rubyists need to at least consider the possibility and what it might mean for Ruby's future. I could certainly be wrong...but if I'm not, it could have devastating effects.
"Rubyists may not have the luxury of remaining Rubyists in the future"
Charles, aren't you a bit overly dramatic :)
Less ex-Java people come to RailsConf, probably less smalltalkers come to RailsConf and probably less ex .NEt developers come to RailsConf.
Does that mean that Ruby is dying? I don't think so. I think that the community is growing and that we are also getting a lot of people new to development who don't have a C/java/.net background but are fresh to the game. We also have a lot more conferences and ruby related events. Local groups spawned here and there and one doesn't need to go to RailsConf to learn more info about Ruby.
However, I strongly believe that JRuby is a key solution to introduce Ruby to the Java community. I do think it has an important mission and will affect the future of Ruby. Of course, same thing goes for IronRuby and MacRuby but JRuby is currently ahead of the game and has a larger user base.
Now, if JRuby would fail to bring part of the Java community to Ruby would that really mean that the Ruby community would die? It would certainly affect the community growth but that doesn't mean it would die.
- Matt
Matt: Here's the facts that lead to my conclusions:
The Java community is still by far the largest developer community. Many millions of developers worldwide. There are more opportunities for Java platform developers than for any one language or platform in the world. Also, the Java platform does not appear to be going away, and with recent alternative language work it seems to be gaining strength again.
Many Rubyists still seem to marginalize JRuby or Java developers or the Java platform as unimportant to Ruby's future. As a result, the best Ruby developers are not working to help further JRuby's adoption on the Java platform.
For areas where Ruby has become most popular, like web development, there are now acceptable options on the JVM with more direct support and tighter platform integration. This means fewer Java platform developers are moving to Ruby and Rails.
If Rubyists do not see JRuby as important, they will do little to help JRuby succeed against its JVM rivals. If its JVM rivals become the only viable JVM-based solutions for agile development, Java platform developers will choose them over Ruby and Rails, increasing the size of their communities and making them more viable. If the entirety of the Java community end up using languages and frameworks other than Ruby and Rails, it will be extremely damaging for Ruby/Rails relevance in the future. And that means fewer jobs, fewer Ruby/Rails-friendly organizations, and fewer opportunities to grow Ruby.
It's time Rubyists got past the bigotry against all things "Java" and realized that there's a massive pool of developers, organizations, and opportunities out there that could be lost very easily. It wouldn't mean the death of Ruby, but it would have a very real and very large impact.
Charles:
Interesting post, and thanks again for all your work on JRuby.
If I understand you correctly, you are saying that the Java devs that Ruby had started to attract in recent years have since switched 'back' to other JVM languages?
A) How can we convince ourselves that this is actually what happened, rather than one of the other possibilities, such as the one Tim suggested?
B) Assuming A turns out to be true, how can we determine why they switched back?
C) What can a Rubyist that has no direct interest in Java do to help? Specifically, I mean someone that reads this post and wants to take action. I, for one, have never understood why Java devs do ANYTHING, much less how they choose languages.
After spending some time hacking Java library wrapper with JRuby, I am totally sold. JRuby makes complex libraries easily reusable from Ruby: it would take huge amount of time to port something like Weka or Mallet to C or C++ and make it available to Ruby as extension on all OSes.
Wrapping Weka in a DSL results in an impressive framework for machine learning with RSpec/Cucumber for testing, and you get it all after one week of evening hacking (!!). And oh, you can use Hadoop core at the same time to distribute data processing.
With possibilities like these, CRuby makes little sense if any, and becomes less and less viable even economically. And, after all, it is still Ruby, it just runs in the different environment.
And thanks for all your hard work and "peacemaking", Charles.
Wilson: Here's a few thoughts...
A) I think there's at least some evidence to show this is the case. I know a few people who had been strong Ruby advocates who now advocate alternatives on the JVM (like Stu Halloway's recent defection to Scala), folks who had been Ruby/Rails devs and now prefer Groovy/Grails (Robert Fischer for one, and I've talked to others), and numerous people who we've met with at Java conferences who said they "had to" switch to Groovy/Grails/Scala/Lift because more work had been put in on integrating with and wrapping Java's de-facto standard libraries like Hibernate. It's somewhat anecdotal evidence, but it points in a bad direction.
B) I think the #1 way in which to reach them, and learn what we need to improve, why we lost them, and how we can keep from losing others would be for Rubyists to start promoting Ruby at *Java* conferences. JRuby is obviously the means to do that. I think we Rubyists (myself included) have gotten in a rut, only every presenting and attending Ruby-related conferences. We've wrapped ourselves in this blanket, isolated from other dev communities, believing everything is going great and Ruby is untouchable. But we need to be vigilant and take Ruby into the heart of other communities by presenting at their conferences on their turf. We need to truly evangelize, as well as *listen*.
C) Along with "taking the fight to them" and talking to Java devs, I think there's a lot regular Rubyists can do. In my talk at Rails Underground I outline a few key steps Rubyists can take:
1) Start using JRuby every chance you get. At least *try* it and let us know why it doesn't serve your needs.
2) Help us improve the Ruby aspects of JRuby by reporting bugs, writing RubySpecs, and if you have any Java experience at all, porting 1.9 behavior and C extensions to JRuby.
3) Start evangelizing at Java conferences.
4) Study what makes Groovy/Grails, Scala/Lift, and Clojure attractive options and help us find ways to compete in Ruby (both JRuby and otherwise). Know your enemy.
5) Study the available Java libraries out there and help us put a Ruby face on them. We'll make sure the Java integration plumbing works well, but we need Rubyist help installing the porcelain.
Michael: Yeah, I'm excited to hear about your work and others' work to put a Ruby face on all those Java libraries. I think Hibernate is a perfect example of what could be accomplished. It's well-known to be the most feature-complete and extensive ORM package for pretty much any language. It's also very complicated and has an enormous API. It's a perfect candidate for "Rubification", and indeed Grails' "GORM" wrapper around Hibernate and JPA is probably the #1 reason people choose Grails over alternatives. Think about how ActiveRecord drew so many people to Rails. Now imaginehow far we could get if we had ActiveRecord with Hibernate's featureset. It boggles the mind.
Thanks for all your work!
hi
thank you for your great work on jruby, i am a java dev, was looking to lighten my java bloat with languages like ruby/jruby, i really like ruby, before trying ruby i played with groovy/grails, but found out web related tasks, ruby has still the edge, then came across scala, i really like scala,so scala stole my time from ruby, but still i believe that if you are doing web related stuff, ruby is very productive, except for the "CONSTANT CHANGES" to the library, gems break all the time..., i really feel if people maintain a "gem repository" for jruby focus little bit on the window world, things would be far better, i still am hanging on to jruby, i really want it to stablize ...,all my old gems/effor has become invalid with new releases,things keep on changing,so the effort put is all gone in few weeks/months, again i have start it all over, pls maintain gem repository for that release...
iagree that scala,etc have made a
dent..., looks like ruby community is blinded
thank you once again for all the hard work by the jruby team
-rubee
JRuby is very good and Rubyists should give it a try more often. JRuby buys you a lot of stability and those simple Ruby libraries and scripts of yours start getting uptimes spanning several months quite easily.
So it's time for phase two of the famous triple E. Embrace was first. Now it's Extend showtime. ;-)
I get what the "bitter pill" was all about now. It has to do with making more use of Java from JRuby. Though I would question trying to entice people to be early adopters of even newer technologies before JRuby gets even more stable. With every new version of JRuby, users have learned to expect major improvements and fixes. So while it could be said to be fairly stable, there might be ways to making it work more seamlessly and so on when it comes to making it beat CRuby more thoroughly.
For a contrarian point of view, some people could expect to see JRuby appealing for more stability and conformance with CRuby before trying to fight on new fronts. For example, come December, and Ruby 1.9.2, how will JRuby cope with it?
Nonetheless, adding some Javaisms to JRuby cannot hurt it too much either and might even be a plus when comparing it to other language implementations. Although this too should be more of a long term war than just a short term battle.
One thing that shook me up a little was the recent statistics of ruby book sales.
http://radar.oreilly.com/2009/07/state-of-the-computer-book-mar-25.html
Take a look at the graph comparing books sold by language. Ruby had the biggest percentage loss of sales. This could be because people are waiting for Rails 3 or Ruby 2 to come out before buying a new book, but it does show that there are not as many newcomers to the language buying up books.
Mr. Interweb: those charts only included point-of-sale sales, which according to Oreilly's next post, only accounted for 32% of their sales (and they say the Prags as well). As a result, I consider their results statistically useless. I'd be interested in the prags year-to-year change on Ruby books.
i have to add couple more point, gwt, google app engine are very awesome/potential tools/technologies,
one stuff about gwt is, it is incredibly verbose(becos of java)
i was looking if scala could generate the java source files, but that is not the case, if jruby or it mutants(duby,juby) can generate GWT java classes, it will be really fantastic,
i think, this (google)is one more thing distracting people from ruby/jruby. so if jruby can provide
tools on this stuff, it will gain
adoption
- Nokogiri seems to be an awesome library, but i cant make it run on windows with jruby1.3, if iam doing pet project,
most of the home machines are windows and not macs/ubuntus(serious hackers stuff)
- i mostly care about good ruby libararies always being integrated and upto date with jruby( ex nokogiri).
- i agree waiting for rails 3/ ruby 1.9 and lots of gems breaking
made me spend time on gwt/gaej/scala
- i agree that enterprise jruby with java libraries will also contribute to a good success ( GRAILS guy was really smart in this case atleast).
-All said and done, i still am counting to JRuby to deliver...
by focussing one any/all the directions listed above
-rubee
Groovy and Grails has hit the tipping point.
I think your post is dead on.
Jruby has quickly become my preferred platform, and it's great to hear the plans for the next release. My biggest hurdle in spreading ruby into the java groups at my company is the need to use jruby classes in java. We have a highly customized solr deployment and I could easily write components in jruby if they could be compiled into java classes. I'm hoping flood gates open once that hurdle is out of the way.
shameless plug: I've tried to help spread the jruby love with moonstone which is a jruby wrapper around lucene. Unfortunately it's hard to get a lot of rubyists to understand the possibilities of leveraging the java platform in this way. Who needs acts_as_solr when you can use lucene directly in your ruby app!!!
Hi Charles!
This post got me thinking. I'm 100% with you on the importance of JRuby to the Ruby community. And also its importance to the so-called "enterprise" world. It's our best bet.
But still, I'd like to know the motivation of java developers around the world on the JVM languages debate, so I've set up a quick poll here: http://bit.ly/VA1w3
I'd appreciate if you guys code visit and share the link. I'll publish the results on twitter at the end of the week. My twitter is: @leonardo_borges
TKs
Charles,
Great post and I like the others really appreciate your efforts in JRuby. (I still remember fondly the announcement on ruby-forum when you were acquired by Sun)
One thing that is important to consider is that many of the new languages are taking SMP head on and have built in constructs for dealing with concurrency such as Scala and Clozure. Scala in addition to being OO also incorporates many functional constructs, this in itself is very attractive to developers..
Another is that Scala borrowed heavily from Ruby and can even be considered an evolution of Ruby in some regards. Almost everything in Ruby is in Scala and in some respects I would argue that it even has a purer OO implementation due to it treating functions as first class objects.
Just like Ruby was a great conglomeration of Perl, Smalltalk, etc.. Scala can be viewed in much the same way..
Maybe if you can't beat them, you should join them. :)
"taking the fight to them"
"Know your enemy"
You make this sound like a war.
Aren't you the guy who only recently was telling us how having numerous JVM languages was a good thing, and that there was room for everybody?
Or does that only go while you thought you were on top?
ilan b,
I too think Scala in many ways incorporates things I like about ruby. One big thing it doesn't have, however, is the level of programmatic symbol manipulation most dynamic languages including Ruby offer. In Ruby, for instance, I can define easily define methods, constants, and classes programmatically, and I can't do that in Scala. Scala's behavior of generating accessor functions for every instance member, for instance, constrasts with Ruby's attr_accessor function. While attr_accessor itself is neat, what is neater is that I as a user could easily write a function that does the exact same thing as attr_accessor. I could not, however, easily extend Scala to imitate it's facility for attribute method generation.
While Scala is a great statically typed language, I don't think it can replace Ruby simply because it doesn't have compile-time equivalents for all of the features you get with Ruby at run-time. I think Ruby faces bigger threats from the other dynamic JVM languages like Clojure and Groovy.
@Sean
Brilliantly put, I too really enjoy the meta programming goodness of Ruby but then again, it has lead to the Monkey Patching madness that we sometimes deal with (especially if dealing with ActionPack within Rails)
The more I think of it however, the more I agree with you. Thank you for reminding me!
Jruby is damn good. I said this because of Jruby support in windows. I am working on windows environment and Jruby working like charm in windows. I even ran a Jruby on Rails application(redmine) in windows with tomcat, this is hard to do with cruby which can't easily run a rails on windows.
> Regardless of how fast or how solid the C or C++ based Ruby implementations get,
> the vast majority of large organizations are *never* going to run them.
> That's the truth.
I mostly program in Java. However, I don't think JVM is the end all, be all. Maybe you meant that large organizations trust more well-enstablished platforms backed by (other) well-enstablished organizations? I don't think that is true. Take for example Apache and PHP. Both are implemented on C and hugely successful.
Besided that, not being dependant on JVM also means that you don't have to pay for all the weight you don't need. This also means more freedom to move where you want to go instead of being draged by the underlying platform.
Personally, I don,'t use JRuby as I'm not in an "enterprise-ish" environment, however, I do greatly appreciate the importance of it. I can agree that JRuby is very important to Ruby as a whole. It could really pull in a lot of people from the Java platform. On the other hand, I think it's important to warm the people who use MRI more to JRuby.
So, I think work on JRuby needs to proceed on both "ends" of the spectrum. On the one side, JRuby should integrate as tightly as possible with the Java platform. On the other side, JRuby should be as compatible as possible with MRI, especially with 1.9.x. (1.9.2 isn't a big change from 1.9.1, just some enhancements and new functionality).
I think the imporant thing to keep in mind for people who program in MRI, is that should try to keep the Ruby libraries we write compatible with JRuby as well.
Excellent post. I would go as far as to say that if JRuby or something similar does not offer the seamless extension of the Java platform as Groovy/Grails does then Ruby/Ruby on Rails faces an uphill climb in Corporate America.
Additionally, it must offer qualitatively superior solutions in Java/J2EE world than Groovy/Grails does today.
Before my comment, a little bit of context: I'm working for a big Telco operator (you get the picture : “big”). In this company, you have to follow the IT rules to do something (software installation, language to use, etc…).
For mainstream development, we merely use Java with Eclipse IDE tools (for the big picture) and we all have in our PCs (Windows desktop/laptop), the Java VM installed. For a long time, it was JRE 1.4, but now 1.5. And quite soon after 1.5, we had 1.6 installed.
As we go "Web 2.0" (well, you know…), we use Flex/Flash Builder for Website UI design.
So in big companies, you have to follow the rules (whatever you think of the rules – good or bad- : language choice, version control, development methods, etc...).
If you want to use something different, you have to pass along many committees with a lengthy process to get an approval witch ends in large part with quite a No.
If I want to use “c-Ruby/MRI” on my laptop, I should have “Admin rights” to install it or I need approval from the IT department.
Remark: well, I have Admin rights so I can do much more than the average employee (and I dot it because it’s tolerated. But it can be removed any time and without notice).
Why is it this way? Well because in big companies, IT departments are accountable for the consistency of all legacy applications. And every migration to new version of any software (basic example: Windows XP to a new version ;-) ) should be as smooth as possible for the Enterprise application ecosystem.
So IT Departments don’t try every new “something” every month (and there’s a lot of new “something” in the market).
And this is why you still find large COBOL, FORTRAN, Ada codebases in some industries.
And their point of view makes sense.
So in most cases, from an Enterprise point of view, creating a new “branch” of “coding environment/ecosystem” will simply fail (or might fail).
But this is where the idea of having some or many Ruby VM implementations is interesting.
With JRuby, having ruby code transformed on a Jar or a java codebase and then deploy it on a JavaEE server can bring the possibility for Ruby to enter more easily in the Enterprise game.
So this is why Jruby, IronRuby are good for the Ruby ecosystem.
Loic.
(*) : By the way, I liked your comments on the Lightning talks at Rails Underground London July. I agree with you :
Conferences should not be just about Rails. Ruby can do much more.
When I go to Rails conferences, I always think “can I do desktop applications or something else with Ruby ?”.
But, to be honest, due to its success, Rails is a good marketing flag for Ruby.
I agree with the original post. I am actually more pessimistic than Charles, when assessing the viability of Ruby/JRuby in the long run.
I understand Charles has a vested interest as he is spending so much of his life building JRuby. For me, it's different, I don't have that same problem. I just analyse with an open mind.
For ruby to grow and become a major force, it has to be accepted by enterprise(whatever their size). This is what drives java technology and .net
see my comments at https://www.blogger.com/comment.g?blogID=20975090&postID=8442900577419001024
my entry is almost at the bottom : chris at 6/27/2009 1:18 PM
Like I said, we'll do a check in 5 or 10 years from now and we'll see who was right in their analysis.
cheers
Chris
Charles,
Thanks for all your efforts for [J]Ruby and the community. I agree with ilan b that Scala is gaining mojo w.r.t. Java developers, but one aspect that has not been mentioned is that two of the four JavaPosse members (Carl Quinn and Dick Wall) seem to be enthusiastic Scala supporters, and their podcast has much influence on the development community. While Tor Norby's work on the IDE plug-in for Netbeans really helped Ruby developers, there seems to be a strong influence towards Scala and other JVM languages. Charles is right- It's the enterprise, stupid!
Hi,
It is great to use Ruby language.The eRubycon is great to see new updates on the Ruby conference and language development.
audiokabel
I don't anything about ruby language but i am a Java professional and as a number of users increase in my Java programers community Java become a most popular language for development.
I agree that being closer to Java is good for adoption in companies.
The main reason I've stayed away from jruby in the past is it has been so slow. Since that appears to not be as much of a problem I might end up participating more :)
-r
The fact of the matter, IMHO, is that Ruby isn't really such a great language. I don't know about Groovy but maybe Scala and Clojure are just better.
The two points i'd like to raise are:
1. Typical OO is bullcrap. This is where Clojure is better. It does away with the false assumption that the "class" with "methods" is the right thing to model your problem domain.
2. Static typing is a benefit. Especially under the time constraints of a commercial project, you will never write all the unit tests you would need to catch every type mismatch. This is where Scala is better.
And the list goes on. Don't get me started on first class functions.
Impressive article but my view are these. If Rubyists do not see JRuby as important, they will do little to help JRuby succeed against its JVM rivals. If its JVM rivals become the only viable JVM-based solutions for agile development, Java platform developers will choose them over Ruby and Rails, increasing the size of their communities and making them more viable. If the entirety of the Java community end up using languages and frameworks other than Ruby and Rails, it will be extremely damaging for Ruby/Rails relevance in the future. And that means fewer jobs, fewer Ruby/Rails-friendly organizations, and fewer opportunities to grow Ruby.
Post a Comment