I’ve just returned from RubyDay 2016 in Florence (which is absolutely beautiful, by the way), where I gave a talk encouraging folks to think more about the future of Ruby in today’s multi-core world. A big part of that meant re-thinking what we consider “idiomatic” Ruby code, and to encourage experimentation and new paradigms in Ruby to help us evolve the language for the future. Well, little did I know, I was preaching to the choir at this conference!
As a comparision, I also recently went to RubyConf in Cincinnati (which is not as beautiful as Florence, sadly). I had an incredible time at both conferences, and learned a whole ton as well. However, I couldn’t help but notice how different the communities and attitudes towards Ruby, Rails and other Ruby adjacent topics were at both conferences.
At RubyConf there were several clear themes. A big one was how to help bootcamp grads and other new members of the community. It reminded me about how great and welcoming our Ruby community is. Another thing that really stood out to me was that in all those ubiquitous hiring announcements at most conferences, it seems like almost everyone was hiring remote developers. That’s another thing I’m very happy to see since I’m a big remote work proponent. And then there was Ruby 3 and Ruby performance. We’re making great strides in making Ruby (and Rails) faster, and some of the ideas for Ruby 3 seem really cool.
At RubyDay, however, while there were two members of the Rails core team in attendance and giving talks, it seemed like far fewer folks were interested in learning more about Rails at this conference. There were several talks there encouraging folks to experiment with Ruby, to take inspiration from other new-ish languages out there (especially a lot of Elixir and Crystal talk), and to explore new paradigms and frameworks. And these talks were all the most well attended of the whole conference. There’s clearly a lot of interest around these topics.
But the most encouraging thing I saw at RubyDay was that there are really smart people actually doing something here to try and push the boundaries of how Ruby is used. For example, Piotr Solnica gave a great talk about innovation in Ruby, and as part of that talk he covered some of the parts of dry-rb that are a little more out there for more traditional Rubyists. These libraries have a heavy focus on immutable data, which is the first major break from the more “traditional” style of Ruby, and it’s central to his style of coding these days. It’s a style that’s very clearly influenced by functional programming, and it’s like nothing I’ve really seen in Ruby before.
Also, there was a lot of interest around Luca Guidi’s Hanami (which uses ROM and several of the dry-rb libraries), which is something I haven’t heard about much in the States. It’s a really great library, and given a greenfield project I think it’s definitely ready for use at scale. It nicely addresses some of the major pain points that I’ve had with Rails over the last few years, like adding view models, decoupling domain behavior from persistence for models, and having a single class for each controller action rather than one class with seven methods for each “resource”. From talking to many of the attendees there, it seems like a lot of them were very interested. There was some good representation at the conference for Trailblazer as well, although I personally didn’t hear the same level of enthusiasm for that vs. Hanami.
But the biggest thing that hit me over the two days of the conference was that things like Hanami, Trailblazer, ROM and dry-rb aren’t viewed as also-rans in the Ruby ecosystem, but instead many people here in Europe are already viewing some of these patterns and libraries as viable paths forward for the future. At the speaker’s dinner I mentioned this difference between Europe and the US, and there seemed to be a lot of agreement from some rather prominent members of the European Ruby community about that sentiment (but I think it’s also telling that one of them said they were a little afraid to make that claim publicly). I’ve also noticed more and more people at my local Berlin Ruby meetup talking about these Rails alternatives and these more functional-inspired Ruby patterns as possible ways to make Ruby work better for us in the future. I don’t know why it seems like there is a more open attitude towards these alternatives in Europe than I’ve seen in the US, but I think it’s really healthy for the global Ruby community to have this kind of increased diversity.
Darwin’s Theory of Evolution basically said that diversity comes from changing environments pushing different pysically divided populations to adapt to those changes in environment in different ways to survive. I kept coming back to this image in my mind of the European Ruby community evolving along a different path like Darwin’s famous Galapagos Finches, and so at the speaker’s dinner we also spent a good amount of time trying to find out what is so different about the US and European Ruby environments that’s pushing this sort of divergence, and we couldn’t quite put our fingers on it.
The theory that I still hold is that the brand of “Rails” is just so incredibly strong in the US, but in Europe that brand isn’t as rock solid, making it less “crazy” to choose alternatives. Rails is of course still a big thing, but it’s not at the same level of renown as in the US, and because Rails also brings with it a very dogmatic style of writing Ruby, that’s more heavily influenced the accepted norms of writing Ruby in the US. In business for a long time there was a saying, “No one’s ever been fired for buying GE,” basically saying that it’s safe to go with an established and widely respected brand – and boy does Rails have a brand in the US! But while RailsConf is a huge thing in the US, there hasn’t been a European RailsConf since 2008…
The thing that people keep (rightly) bringing up when I talk like this, though, is “why not just write Crystal or Elixir if that’s what you want?” That’s a totally valid question. I think it goes back to the major theme of the talk that I gave. Ruby was written in 1993, before the first multi-core CPU was designed. It wasn’t designed to handle the architectures of today, and we’ll need to change significantly to handle that. I don’t think there’s any way we can avoid this. Maybe I’m wrong and some brilliant people will manage to make it all work, but I’d be very surprised if that’s the case.
But in Europe, it seems like there are lots of people pushing for that change now, while in the US there is resistance towards major changes to the language or the accepted norms. People say “if you want something different, use another language.” I don’t want to see Ruby diminish in popularity or usefulness in the future, and like Matz said in his keynote at RubyConf this year, OSS is like a shark - it keeps swimming, or it dies. So, I’m trying to do my part to get people thinking about these big problems today, to have these discussions now, and to try and inspire others to think about the future of Ruby so it can keep swimming towards a brighter tomorrow!