So is this decline in interest for the language, Ruby’s biggest challenge to overcome in 2009? I don’t believe so. I’d venture to guess that most developers have heard of Ruby by now, and I think it’s fair to say that as a community, we’ve attracted a lot of attention towards Ruby over the past few years. The Ruby word is clearly out. As Ruby moves forward, organic growth is expected and the numbers above shouldn’t scare you in the least.
Ruby’s challenge for 2009 is not about adoption, marketing or – to adapt a term from the Christian vernacular – trying to convince other developers to accept Ruby into their hearts. The real challenge will be technical, namely moving away from the main Ruby 1.8 interpreter.
Historically, Ruby has been an exceptionally well designed programming language with a very lousy implementation. Some of the main issues surrounding MRI are common knowledge: memory hungry when compared to other scripting languages, extremely slow, lack of native threads, and lack of support for Unicode.
Ruby 1.9.1 resolves these issues though. As such, we as a community should really make an effort to get rid of our MRI baggage and move forward as quickly as possible to embrace Ruby 1.9.x. The payoff is an improved language with a faster and “less memory intensive” VM, as well as native threads (albeit with GIL) and support for multi-byte strings. There’s no reason to look at the past. A stable version is available and we should all be using it.
In practice, very few people have switched to Ruby 1.9. Some developers wrongly believe that Ruby 1.9 is just one intermediary step to Ruby 2.0, and as such it’s not meant to be used in production. Better communication could have avoided this common misconception. More importantly though, developers are not using Ruby 1.9 because there are very few libraries that work with it.
The Rails team is a notable exception, having placed a lot of effort into a release (2.3) that works
completely with Ruby 1.9.1. But most libraries, gems and plugins won’t work with it, so inevitably Rails on Ruby 1.9.1 loses a lot of its initial appeal.
Unlike in the Python community where Python 3 is seen as an improvement to the language (Python 2.5/2.6 are perfectly fine for the time being) the Ruby community doesn’t have this sort of “luxury”. We finally have the chance to eliminate the root causes behind the harsh criticism that Ruby is sometimes subjected to, and to have a good implementation at our disposal. All we have to do is make a swift switch to Ruby 1.9.
To achieve this worthy goal I urge project owners to report compatibility with Ruby 1.9.1 information in their README files. I realize that this is open source and that doing so is a voluntary effort, but I truly think that Ruby 1.9.1 should be seen as a priority by the community as a collective whole. If you are not a project owner, you can still help by testing active libraries with Ruby 1.9.1 and informing the author of the library you test of your findings. Those who are able to, could also submit a patch that would enable those projects to work with the latest version of Ruby.
In truth, it wouldn’t be a bad idea to keep a list, perhaps within a wiki, of projects that have already been ported to Ruby 1.9 and that have been tested/confirmed as working. This switch to Ruby 1.9.1 can also act as a reset button when it comes to getting rid of many of the old, unmaintained, half-assed attempts from N years ago. Porting to Ruby 1.9.1 could act as a rough, implicit line of distinction between active and inactive projects.
I don’t know if this is an open letter to the Ruby community per se, but you could view it as such, as I feel that the topic of switching to Ruby 1.9.1 is one of vital importance for us Rubyists. If you agree with this point and assessment of the situation, please consider spreading the word, sharing your thoughts, and linking to this post.
When new developers come to the Ruby world, lets greet them with Ruby 1.9.x. In the long term, doing so will improve our growth as a community more than any marketing effort ever could (and the two efforts are not mutually exclusive either). Ultimately, Ruby’s biggest challenge may just be our greatest opportunity to improve.
Get more stuff like this
Subscribe to my mailing list to receive similar updates about programming.
Thank you for subscribing. Please check your email to confirm your subscription.
Something went wrong.
Agree… and I think that http://isitruby19.com/ is a nice starting point. To all “programmers”: never feel scary of looking *inside* the (gems’) code.
Excellent link, Carlo.
Maybe some banchmarks on a simple Rails application on 1.8 vs. 1.9 should be used to invite “programmers” to think more about 1.9 approaching… What do you think about?
I just supported this blog with my twitter id:- softmind
@Carlo: It’s not a bad idea. There is already an effort to this extent being carried out through the Ruby Benchmark Suite, but a well constructed, standalone test would also be interesting.
@Softmind: Thank you for your retweet. 🙂
Be that as it may, the alternative implementations (namely Rubinius and JRuby) are still aiming to be compatible with 1.8.6 rather than 1.9 or other official versions. It surprised me that you didn’t mention any of these interpreters.
Nice written Antonio! I convince all ruby programmer that they should care about ruby 1.9.1 compatibility. I have a blog (writing in polish language) where I wrote many posts about differences between 1.9.1 and 1.8.6 etc. I think we should try switch to 1.9.1 as far as we can, even if sometimes it looks almost impossible (some library doesn’t work etc).
I also think that people who have our community respect (like you Antonio!) should write a lot about it and constantly encourage people to switching. Thanks you for all your work.
@Norbert: The main point is moving away from MRI. JRuby, Rubinius, IronRuby, MacRuby and MagLev either are or will be valid alternatives for some developers.
Norbert Crombach, JRuby latest version (1.2.0) is almost compatible with 1.9.1. Rubinius is another story and because they try to have full working implementation they aim to be compatible with 1.8.6 (because it was stable version when rubinius project has started). Adding 1.9.1 support to it should take too much effort.
“Adding 1.9.1 support to it should take too much effort.”
I mean: shouldn’t take too much effort :).
I totally agree with your observations on Ruby 1.9.1 and your ideas on promoting its use, but.. I disagree that evangelism is no longer important. I’d still put it at #1.
I’ve encountered a lot of people out there who know of Ruby but have dismissed it for fabricated reasons. Evangelism isn’t just about getting people to hear of Ruby but to appreciate its realities. There has been a sore lack of this sort of evangelism – real “out in the wild” type evangelism where Ruby solutions to problems are presented at every occasion.
I don’t think migrating to Ruby 1.9.1 is a significant challenge at all with new apps right now, although clearly there’s still work to be done and I think your suggestions are worthwhile. That said, the number of significant libraries that don’t work on Ruby 1.9 is falling rapidly and we just need to get people using it.
@Radarek: Thank you very much. 🙂
@Peter, I believe in the importance of evangelism, but I think it needs to be coupled with a conscious effort to move away from MRI. The two things together can do a lot for our community.
As far as I’m concerned, the numbers mean nothing. I know that the community is strong and that there is a great number of awesome Ruby-based projects and that there are more coming.
You are right about a swift move to 1.9.1. I think that the leaders of the Ruby community need to pick this message up and really emphasize it. RailsConf would be a great place to start.
I teach a university engineering course where Ruby is featured as the primary language.
I think the biggest challenge for Ruby is entering the curriculum at schools, where it will become part of the fundamental education of the next generation of software developers.
If you know of anyone else who is teaching Ruby at the University level, please have them contact me!
Sorry Antonio, but you are deluded if you think a jump to the next version of the interpreter is all that’s needed for Ruby to become mainstream.
Good underlying technology has never propelled products into the mainstream (Java was already mainstream with the early versions of its JVM, and we all know how bad they were).
Ruby had a shot at becoming mainstream but if it hasn’t now, it probably never will.
Oh and one last thing: all the emerging technologies feature an exponential growth at some point, there is nothing remarkable about that. The hard part is sustaining that growth, and Ruby obviously failed to do that.
This is where I think Java will make a come back via groovey, grails etc. I had always said, building a rails equivalent in java is a lot easier than building as good as a VM as JVM for Ruby.
I think we’ll see large growth for GOG in 2009.
“memory hungry when compared to other scripting languages”
Ruby? Memory hungry? Boy you haven’t seen Perl. 🙂 Perl wants 1.5 KB of memory for every empty function that you define. Ruby is lightweight compared to that.
I totally agree that moving to 1.9 is important for us as a community. Your points are all very well made. Getting momentum to move developers over is why I started the Ruby 1.9 or Bust project over at http://ruby19orbust.com We have this chicken and egg problem and though we’d eventually crack it, I’d like to see the solution sooner rather than later.
Thanks for the read, Antonio. I certainly agree with you on this one. I think that dispelling the myriad Ruby myths and better education are key to helping the adoption rate of 1.9 and beyond.
I remember a similar call-to-action in the Java community years ago and this is what I feel is needed now to help Ruby gain back some of its lost popularity. Ruby is a powerful, beautiful language. One of my favorite all-time languages to work with not because it’s “cool” or because it’s what the hip developers are doing, but because it is a joy to write. Calling Ruby “expressive” doesn’t even begin do it justice. I have personally noticed performance improvements in the 1.9 release, but as you stated the Gems and plugins aren’t all there just yet. Getting the word out there is a great idea to help get these up-to-date or, as one reader pointed out, to help delineate the active applications from the stale ones. This is something that Java developers know all too well.
And I have to disagree with @steve. Even though Ruby has been around since 96′ it wasn’t really until 03′-05′, during the Rails heyday, that the language was really “officially” noticed. Sure, that is an ice age in Internet time, but look how long Java took to really gain a solid enterprise foothold. Corporations are slow to change and they have (mostly) settled on Java as the de facto choice, but I see Ruby’s adoption at the enterprise level increasing every year. I’ve had more Ruby/Rails development projects in the last 2 years than all other languages combined. I’ve been using it more frequently for tasks I would have typically done in Java, Perl, or even PHP. Will it ever be as huge as Java? Who knows. It really has to do with education in the marketplace and at the curricular levels. Just my 2px…
Antonio, thanks for the great read. I agree with every one of your points, and am even inspired to go ahead, take a leap, and switch my own projects to be fully 1.9.1 compatible. Thanks for the extra push 🙂
I’ve got a Rails plugin (datesplicer.solin.eu) that I want to test under Ruby 1.9.1.
Does anybody have a word of advice on how to install Ruby 1.9.1 alongside your original Ruby version (e.g. under Ubuntu)?
Download the ruby 1.9.1 source and do the following:
sudo make install
This will install all of the binaries into /usr/local/bin/ in the form of ruby1.9, irb1.9, etc. You’ll probably want to add /usr/local/bin to your PATH since it’s not there by default.
switched to 1.9 around ’04 or ’05 (Gridflow required the latest Matz-patches for embedding..) and ported my web framework to it around ’07 (mainly for block/lamba scoping/syntax and speed improvements)
the reason i ditched Ruby in favor of the ML family (OCaml/Haskell) was performance, stability, and a typechecker of any sort let alone a nice one (99% of ruby ‘metaprogramming’ goes on at VMstart/libload-time anyways and could be pushed to compile time with a proper typesystem)
ruby’s just way too big for what it is too. Blocks, Procs, and methods (and myrid of ways to convert between them and their various takes on scoping and relations thereof to OO…). if i wanted this kind of language i’d proably reskin Lua with a nicer syntax (MetaLua) or tweak out on Potion..
I don’t what is your definition of “mainstream”, calling ruby a non-mainstream language is a joke.
I don’t know what is your definition of “mainstream”, calling ruby a non-mainstream language is a joke.
imho, one of Ruby’s biggest strengths is also it’s biggest weakness, and that would be Rails. Simply because the association between Rails and Ruby is so strong, that there’s a tangibly felt assumption that if you’re doing Ruby work then you must also be doing Rails work.
For instance, I just bought the Ruby in Practice book, and in a 13 chapter book, 10 of those chapters are either directly about Rails features, or the discussion is heavily Rails oriented.
There should be, in the market, a more advanced version of Hal’s Ruby Way book, or Matz’s book. That there isn’t speaks volumes (no pun intended), about the ghettoization of the Ruby language as simply a means to implement Rails projects.
Difei: I wonder what criterion *you* use. The TIOBE index places Ruby at 2% mindshare and various searches on job boards put it at about the same amount of popularity.
This puts Ruby squarely in the “non mainstream” category to me.
I share in your enthusiasm, but I don’t agree that a simple revision of the language will do the trick. IMHO what is needed is a killer app.
Rails is not a killer app, so I would look for something else. (Joomla, Drupal, WordPress, etc. have the CMS space “nailed” with PHP/MySQL. Ruby should look for something else; RoR is a poor competitor.)
Up to this point, Ruby simply has not found a “Killer-App” to push forth its popularity. So instead of asking your readers to help evangelize a new revision of Ruby, why not ask them to start writing Ruby into TNT (The Next Thing) in hopes that something will catch fire?
For the record, I’m a HUGE fan of Ruby, and I believe it is the best language I’ve worked with. I’m from the old days of punched card Fortran, and I’ve been through at least 20 languages since then. (The WORST language? FORTH!)
Thanks for the call to arms. I’ll keep writing Ruby into my apps in hopes that we’ll catch fire with TNT.
Amen Antonio. I’m certainly supporting your campaign: http://alwaysthecritic.typepad.com/atc/2009/04/adventures-in-ruby-191.html
Lookout for Ramaze becoming the ‘killer web app engine’ for Ruby, if not the killer app itself 🙂 And it’s always been at the vanguard of 1.9 support.
I agree that 1.9 has better garbage collection, and is faster, and so is better. I’m not sure if a switch to a better version is the “killer app” for Ruby (oh and BTW, I think that rails was the killer app for Ruby–there just needs to be another killer app, e.g. shoes or ramaze or a django clone would be 🙂
Macruby might help, too.
Could somebody please write a debugger for 1.9? Though some attempts exist http://betterlogic.com/roger/?p=1158
I think the killer app “could be” something like “flash programming done in Ruby!”
[maybe a wrapper for javafx?] something along those lines would sure be swell and potential to become popular.
Just thinking out loud.
hmm. Now that I think about it, I wonder if jruby in the browser could be a competitor to javafx/flash… 🙂
In my point of view, the problem for making the switch to 1.9 is simply that it’s not available in my linux distrib. If I install Rails, apt-get gets the ruby 1.8.
So, just get things working so that distrib maintainers adopt them and make them available to the public. That’s all.
All in all great article. I wish there was more told about the whole thing and as for myself I’d love to replace PHP with Ruby for a few ancient projects that are out there.
Roger: Flash is something else and I don’t think anything will be good enough to take over that niche anytime soon. I advise you to take a glance on Adobe AS3 LiveDocs to ensure.