Again this year, I was able to attend RubyConf, and again it was a lot of fun. Going out to conferences is important, especially when working on a small team. You can get a good sense of what the wider development community is thinking about from blogs and social media, but it’s not a substitute for face time.
It’s an interesting time to be a Ruby developer. It’s still as pleasurable to write in as ever, but Ruby is no longer the new shiny. I myself have no shortages of new languages I’d like to dive deeper into, like Elixir, Elm, and Rust. But Ruby isn’t going anywhere. Not anytime soon. The community is still growing, there’s still phenomenal work being done on Rubygems, and the language is still improving. If there was an overarching message this year it was yes, Ruby Can Do That.
The wider developer community has started (re-)discover the value of functional programming. And though Ruby is a thoroughly object-oriented language, its approach of focusing on ergonomics and ‘developer happiness’ means that its borrowed some of the more useful bits from FP. When I was learning Ruby, the first idiom to blow me away was the ability to iterate over and map collections instead of looping. I thought “Wow! More languages should do this.” Sure enough, this and more of the Ruby features I’ve come to love are plucked right out of FP. Saturday’s opening keynote was all about how you can leverage the functional style without jumping to a new language.
Ruby’s core team is also working hard at improving the three most highlighted weaknesses of the language, performance, and type safety and concurrency. The 3x3 goal of making Ruby 3.0 three times faster than 2.0 has already made some good progress in the point releases we’re using today. I’m happy to say over the summer I was able to bring all of our still active projects, some as old as the 1.9.2 days, up to 2.3 and they’ve never run better. A big thank you to the Rails team for backporting support, which made this transition much easier.
I was also able to sit in on Koichi Sasada’s talk laying out the proposed Guild system. It’s still far off, but they’ve wrapped a complex idea in a somewhat easy interface. What’s also impressive is that it isn’t a breaking change, it’s simply a new layer on top of the existing syntax.
An even further out idea was announced during Matz’s keynote. Ruby’s dynamic typing is at once the source of some of its vast expressibility and its biggest source of runtime errors. But what if the Ruby interpreter could analyze your code and tests and detect these type issues ahead of time? You’d get a large portion of the advantages of a statically typed system with none of the brain (or finger) effort! A fellow attendee has a detailed write up of the proposed idea. This is easily my most anticipated feature.
While these improvements are still a long ways away, I left RubyConf more confident that the language still has a lot to offer and can continue to be relevant well past its current momentum. And beyond that, the conference was a lot of fun! See you in 2017!