Friday, June 25, 2010

The New Ruby Ecosystem

Last week I finally caught up with the state of Ruby - the language, the community and the tools in fashion. I'm impressed. These guys seem to be doing a lot of things right.

I'd taken a break from Ruby a few months ago, after Metaprogramming Ruby had gone out of beta. On my comeback, I was a tad disappointed at first. I couldn't see much progress on things like standard language specs, Windows support or in-process concurrency. I didn't even see an increase in Ruby's popularity. In fact, even as the language is going strong in the marketplace, the burst of adrenaline that used to accompany its rise seems to have faded.

So, where did the once-vocal Ruby community go? As it turns out, they're hard at work building a new environment. It's an ecosystem composed of many small moving pieces, mostly interchangeable and in continuous flux, yet integrating nicely with each other. It's young and rough around the edges, but it's working well enough, and it pushes the envelope far enough, that it deserves its own name: I'll call it the New Ruby Ecosystem.

Here are a few examples:

- It seems yesterday that the Rails team announced their merging with Merb, their primary competitor for web developer love. In less than one and a half years, these guys merged two large frameworks into one better, cleaner framework that some people are already using in production. Most companies I worked with would take multiple years to accomplish such a feat - if ever.

- Any Ruby web framework now jives great with any Ruby web server. I can scale down from a fully load-balanced production system, to a local Apache, to a quick in-process web server without even thinking about it. I can also add components to the HTTP chain in a snap. Thanks to Rack's amazing simplicity, it took less than one year to move from Rack 1.0 to widespread Rack compliance. As Sam Ruby put it: I love it when a plan comes together.

- In what seems like one year, pretty much all Ruby-related development migrated to git and GitHub. GitHub is now a one-stop shop to do whatever you wish to whatever piece of open code in the Ruby world. Forking and contributing has never been so easy. The technology behind the library repositories took the time to split, experiment and then merge again, so that publishing a project to the community is now boringly easy. The barrier to contribute, join efforts or part efforts in the Ruby community is as low as they get.

- No other technology offers a comparable number of options to connect to just about any cool recent thingie out there, from noSQL databases to clouds. Yesterday I was looking for libraries to access MongoDB, and I was totally overwhelmed. These libraries also tend to be simple enough that switching from one to the other is as easy as I could hope. I just picked up the default Mongo driver for my next project, and I'm confident I'll be able to switch quickly to another driver or even a relational DB if I need to.

- There are now about ten flavours of Ruby interpreters, ranging from experimental, to cutting-edge, to enterprise-stable. I can have all of those interpreters, or even multiple versions of the same interpreter, on one computer. I can install a new Ruby, select a default Ruby, switch Ruby on the fly - each of those with a single command. I can switch Ruby automatically for a specific project directory, and I don't even have to notice: I just type ruby or irb, and bang - I'm using the “right” interpreter. I can even have multiple sets of gems (libraries) for each Ruby, and switch gemsets with one command like I switch Rubies. I cannot imagine a more flexible language environment.

- I can declare all the libraries that my project needs, install them all at once, instruct the project to ignore any unlisted library, and package all libraries inside the project itself. I can even use Bundler and rvm together to isolate each project within its own little bubble of libraries. The result comes close to copy-and-run installation from development to production. Complex library management tools suddenly feel so last year.

- The popular Ruby libraries, especially the Rails add-ons and the testing tools, evolve at a scary pace. Projects like Cucumber release production updates faster than you'll probably care to get them. Still, the tools are remarkably stable (unless you choose to ride beta versions) and play together nicely. There is something to be learned from a project that releases stable production versions every few days, even taking the time to go through a few large refactorings, and still manages not to break its thousands of clients.

- I can mix-and-match libraries to get my own ideal environment. Libraries are built to work together by default. I'm now switching a small testing project from Cucumber-RSpec+Webrat+Mechanize to Cucumber+RSpec+Capybara+Culerity+Mechanize, so that I can test simpler browser interactions in-process and switch to a real browser when I test JavaScript. The community is relentlessly looking for ways to make my life easier.

- I can deploy my Rails application to the cloud with a single command. The server will update all its libraries, tweak my app's configuration to run on its own backend, and generally do everything so that my application just works©.

Nothing of the above is revolutionary. Taken all together, though, these changes are a great display of the power of simplicity, testing, openness and relentless experimentation. In fact, I think that the development community at large should look hard at the Ruby community for inspiration. Sure, you can wait for the better stuff to make its way to your environment of choice - but no matter how good those efforts, you'll be lagging a few steps behind. If you fancy to be in the place where things happen, there is no current replacement for the Ruby community.

In a world where a standard can take years to be discussed, approved, implemented and supported, Ruby standards such as Rack skip from conception to widespread support at blazing speed. Every time I take a peek, the New Ruby Ecosystem seems to have reinvented itself in many different ways. This is inspect-and-adapt taken to new heights, and a wonderful showcase of the power of emergent design over big up-front design.

Final disclaimer: As usual, cutting-edge Ruby is not for the faint of heart. In particular, using Ruby on Windows still gives me more headaches than I'd expect, so I'd hesitate to suggest some of the above tools to customers still deeply mired in Windows. If you use the beta versions of all tools, expect your own share of bumps in the road and frustrating error messages. It will take a few more months until Ruby 1.9, Rails 3, Bundler, RSpec, Cucumber, Heroku and all the related technologies work together without a hitch.

I know I'll be waiting. With a big smile on my face.


  1. Hello Paolo - nice writeup. I still use Ruby to "get stuff done" but look forward to Clojure's ecosystem catching up (or at least getting close).

    BTW, just added your book to my Amazon shopping cart.

    -Mark Watson

  2. Well said! I've been a part of the community for two-years now --without a programming background-- and the community is the reason I have been able to learn Ruby. Thank you (and thank you for all the links)! PS I lived in Bio Dora for two-months and miss the great food and wonderful people!

  3. Thanks for sharing your knowledge, your book was the definitive reason why I moved to Ruby! :)

  4. It's all good - really, I'm happy that I can work with ruby at my job and at home, and I have all these awesome things at my disposal.

    One thing is still lacking though (and makes me very jealous when I look at Python) - multiplatform GUI libraries support.
    Yes - I know that QT, wx and Swing (through JRuby) are all available, but the problem is that ruby is regarded (mostly) as a glue or web-oriented language.

    That implies lack of documentation, packages for different operating systems, examples and so on.

    Which is a shame really because I would happily code some desktop stuff in "pure" ruby. I'm not talking about just the support for libraries - that's not enough! I tried (oh... how hard I tried) to make qt-ruby work on two machines so I could do some development. I failed miserably.

    (I'm aware of such projects as Bowline, Shoes or Limelight but that still doesn't cut it - each one of them can't be even compared to for example wxPython)

  5. Don't forget Tilt, an awesome new "Rack-like" approach to web templating (haml/mustache/liquid/erb/etc).

    I love the trend of the ruby community to adopt thin wrappers that provide easily pluggable implementations. Rack revolutionized the ruby web development world, cant wait to see that idea extended out to other highly competitive problem spaces.

  6. Great post and great book (metaprogramming ruby)
    add : sinatra , couchdb , hobo

  7. Thanks a bunch. Getting back into the Ruby (and Rails) game after a couple of years in the cold, this writeup is spot on!

  8. There are still people developing on windows out there?

  9. Most "enterprise" development still gets done on Windows. That's not going to change any time soon. If ever. And a lot more code gets written internally, for internal consumption, than ever finds its way out. That's why Visual Basic was the most popular (well, widely-used at least) programming language for a decade. Hell, COBOL isn't dead yet, although I haven't seen much open-source COBOL on GitHub.

    If Ruby is to achieve truly broad acceptance (and whether we might want that to be so or not is something we could argue elsewhere) then it needs to be supported on Windows as well as on the *nix family. Fortunately, it's acceptable now, and getting significantly better through the commendable efforts of Luis Lavena in particular.

    While there may be performance issues compared with *nix, we're not likely to see them so they don't really matter. More interesting is the improvement in compatibility as we move towards gcc as the standard compiler, and the possibilities for integration with other enterprisey stuff through JRuby or IronRuby.

  10. Also other web frameworks like Sinatra, Padrino and Camping are also establishing themselves as simpler alternatives to Rails. Even after _why's disappearance last summer, the Camping community has been pretty active in terms of new development (see

  11. You forgot to mention Rubinius, another ruby interpreter/vm.

  12. Thanks everyone for the kind comments.

    I see that many of us are suggesting more cool technologies, both in and outside the Ruby ecosystem: Rubinius, Tilt, Sinatra, Clojure, CouchDB... FWIW, I agree on every single one of them. I didn't mean to select the "cream of the crop" - I just reported on the stuff that I have direct experience of, which left out a lot of the good stuff. Clojure tops my list of things to learn right now.

    IMHO, the "Ruby on Windows" problem is pretty big. Cross-platform compatibility is a killer feature these days, and I agree with Lukas and mikewhoodhouse that Ruby is lagging behind in this respect. I might write a specific post about Ruby on Windows in the near future.

  13. what's back with ruby on windows these days? Just the speed?

  14. Melissa: I wasn't thinking about speed. To me, the main issues of Ruby on Windows are the development environment and the community support. For example, using irb on Windows is painful (mainly because of Windows' terrible command line prompt). Also, while you can connect to MS technologies such as SQL Server via Ruby, that's not nearly as easy and reliable as connecting to most non-Windows technologies. It's a culture issue, really. The Ruby community tends to overlook Windows, and the Windows developers tend to dislike some tools that typically get used by rubyists, such as the command line or simple editors.