There were some great talks at RubyConf this year, covering themes like concurrency, monitoring and architecture, among others. But there were also a number of presentations about the future of Ruby, which piece together an interesting dialog.

Ruby 2.0

Starting out with the very first presentation, Matz’s keynote took a quick look at the history of Ruby and his motivations for creating the language. He then dove right in to some of the exciting things he has been working on for Ruby 2.0. New language features like keyword arguments, Module#prepend, refinements and various speed improvements are just some of the things to look forward to in the upcoming release.

Shortly after Matz’s talk, Koichi Sasada gave an in-depth overview of his work on the Ruby 2.0 VM and how he has drastically improved the performance of method dispatch. Koichi also made a point to show us how much complexity already exists under the hood by giving a few “quiz” questions during his slides.

A different picture of the future

Next I decided to check out Brian Ford’s talk titled, “Toward a Design for Ruby.” At this point, I was pretty excited about all the new features I had been introduced to throughout the morning. However, this talk painted a different picture of Ruby’s future.

The talk was a criticism of Ruby. With Matz present in the audience, Brian did an excellent job of fairly addressing issues with communication, growing complexity of features (especially those expected to be released in Ruby 2.0), the state of the standard library and the need for specification of Ruby’s features.

Brian finished by saying, “Ruby is now over 18 years old. Please set it free to fulfill its destiny.” It was hard to hear that Ruby has significant challenges in its future, but I think it was a very healthy criticism that needed to be brought to everyone’s attention.

Matz addressed some of these concerns in his question-and-answer session, saying that improving communication with the Rubinius and JRuby teams is important to him and something they need to do. But there are still some very important questions that went unanswered:

• Why doesn’t the core team use GitHub to develop MRI?

• Why aren’t major discussions available in English?

• Why don’t we have tests that define language features instead of implementation details?

• Why do we still not have real concurrency in Ruby?

avoiding Community fragmentation

I’ve been thinking a lot about the quote, “Those who make collaboration impossible make forking inevitable.” Since I’m not a language implementer, I don’t frequently deal with these problems. The people who do, the people trying to improve Ruby, are the ones we need to worry about. If super-smart people who love Ruby, like Brian Ford, have no power to design and improve the language, they are either going to fix it themselves in their own implementation, or they are going to leave for another community that gives them that power.

I don’t want to see the community fragmented and I don’t want the awesome people supporting us to leave for another language. Let’s make sure that Ruby and the community stick around by taking these issues seriously and making projects like RubySpec and Rubinius first-class citizens.