Stop me if you’ve heard this one…
Ruby is dead!
Hacker News
As someone actively writing (and heavily invested in) Ruby, it’s hard not to question if I’m “missing the boat” when I hear such things.
In an attempt to “stay relevant,” if you will, I spent the better part of last year exploring other programming languages and paradigms. I built many, many Hello, World applications. Although I didn’t master anything, I learned a lot.
I spent some time trying to wrap my head around Elixir and functional programming. Alongside Elixir, I began to embrace modern JavaScript using things like ES6, React, and Stimulus. I built a mobile application using React Native with a Firebase backend. I read a little bit about Rust, drooled over Crystal, and read (part of) a book on Scheme.
There’s a lot to learn from other programming languages and approaches. As I learn about these different techniques, I feel that I’m becoming a more well-rounded developer.
However, I ended 2018 with one overwhelming theme: Ruby still fits me.
Exploring a world outside Ruby reminded me that Ruby isn’t the ”one true way,” but it’s still an excellent tool in my toolbelt.
99.99% of the work I do is on the web. For me, Ruby is an excellent tool for that job. The language is flexible, stable, and fun to use.
Before I go any further, I want to point out that I understand that Ruby isn’t the right tool for all jobs. There is a reason new languages are evolving and seeing adoption.
I’d also like to point out that this isn’t a definitive “you should use Ruby and here are the reasons why!” type of article. This article is a summary of why I’m confident using ruby in 2019.
The Road to Ruby 3
I stood in the back of the room for Matz’s 2015 RubyConf keynote counting down the time until I had to catch my flight home. I’ll never forget when he laid out his idea for Ruby 3x3. The premise is that Ruby 3 will be three times faster than Ruby 2.
We’re fresh off the Christmas release of Ruby 2.6. I asked Noah Gibbs about the progress made from Ruby 2.0 to Ruby 2.6.
A lot of the early 2.0-series improvements (2.1, 2.2, 2.3) were in the garbage collector - the 2.3-and-later GC is much faster than 2.0.
For RRB, 2.4.1 runs at 150%-155% of the speed of 2.0, and 2.6 (no JIT) runs at about 10%-15% faster than that. So you can quote me at 165% the speed of 2.0. That’s 65% faster, or just north of time-and-a-half speed.
2.6 has been a bit of a speed disappointment for RRB and large Rails apps, but overall the 2.0 series has been pretty good. I tend to say that, as a rule, each minor version of Ruby averages 10% faster for Rails apps. So while 2.6 gave us nothing over 2.5, some earlier 2-series Rubies had us a bit ahead of that schedule and it all works out.
With that said, we are not on schedule to get a 3x speedup just out of these small speedups - that would be a lot of 10% speedups from minor versions. Instead, the big hope there is JIT and possibly concurrency (Guilds.) But we’ll probably count 3x as achieved even if a big Rails app doesn’t get it, because so much of what Rails Ruby Bench does isnt Ruby – database calls, I/O, Redis, HTTP server, etc. I’m working on a smaller benchmark to show more of that now, and more Ruby-heavy benchmarks like OptCarrot already do, in various ways.
Measuring speed is a genuinely interesting problem, and there’s almost never just one answer. There’s a great talk by Matt Gaudet from just before I started on this problem, if you want the deep dive version.
Noah Gibbs | Appfolio
Rails 6+
We’re on the cusp of a new major Ruby on Rails version. DHH recently released a blog post highlighting the tentative timeline of Rails 6.
April 30: Final release. Ship and celebrate the release of Rails 6.0 at RailsConf 2019!
DHH | Timeline for the release of Rails 6.0
Three things to highlight in Ruby on Rails 6:
- Action Mailbox - Handle incoming emails to your Rails application
- Action Text - Built-in rich text capability using Trix and Active Storage
- Parallel Testing - The ability to split/divide your tests to run in parallel
I’m most excited about parallel testing, as I currently use a gem to do that for me.
It’s nice to see DHH, Basecamp, and the countless contributors ❤️ still committed to Ruby and Ruby on Rails. I’m under the impression that for the foreseeable future David will continue to stay involved in Ruby and Ruby on Rails. (Guessing, here, but he loves Ruby.)
Generating a fully-fledged Rails application has never been easier. One thing I’ve grown to appreciate about Ruby on Rails is “no one paradigm.”
For example, there are times when I feel that I’m butting heads with the “Rails way.” When I find myself here, Ruby on Rails doesn’t prevent me from implementing new patterns or even doing wild things like replacing ActiveRecord.
One thing I often envy is the Laravel framework in PHP. Chris and I have talked about this on our Ruby podcast. Laravel has many tools most web apps need baked into the framework. Things such as authentication, authorization, events, queues, etc. Outside of that, Laravel offers official packages that handle things such as recurring payments with Stripe/Braintree, a GUI for debugging your application in development, an OAuth server, OAuth providers, and more.
I think adding these things into Rails might violate “no one paradigm.” Maybe it’s possible it’s as simple as Rails core believing Rails shouldn’t take those defaults.
I still enjoy Rails without having those libraries baked in. However, I’d be remiss if I didn’t mention I wish we had more first-party functionality like that.
I’m excited for RailsConf 2019. I hope to see you there!
Outside of Rails
Though the majority of my work is in Ruby on Rails, I’m very excited about the work outside of Rails.
For instance, the dry-rb project profoundly resonates with me after spending time exploring the functional programming world.
I have the utmost respect for Piotr and Tim. (and the other people on the dry-rb team I’ve yet to meet!) Their approach to writing Ruby code is unique, and I have a lot to learn from them.
Alongside dry-rb, Piotr has a database toolkit named ROM. Once again, this is an approach that is different to what I usually use, ActiveRecord. However, the approach resonates with me. I’m excited to explore this more in 2019.
The other project I keep my eye on is Hanami. The core team is currently working on version 2.0, which embraces more of the dry-rb and ROM libraries. I’m excited to see the result. I hope to build a project using Hanami 2.0 in 2019.
These are just a few of the exciting things happening in Ruby outside of Rails. I’m sure there are more I don’t even know. What are some of your favorite things?
Gems
The Ruby language has a plethora of gems. It’s one of the things I loved about Ruby when I came into the language in 2012.
However, some gems are starting to get a little stale. While it’s a bummer to see abandoned gems, it’s also an opportunity for Ruby developers to get involved in the community.
If a gem you like using is abandoned, you can fork it or build a new gem and share it with the community. I’d certainly love to see some fresh gem ideas in 2019.
An aside, I would love to see more open source models like Mike Perham’s Sidekiq. Mike gives you a fantastic open source project, with the ability to pay for more “pro” features. I imagine this helps Mike stay interested in the project.
Flexibility
One of the things I most love about Ruby (and at times have been frustrated with) is its flexibility.
Ruby includes a lot of sharp knives in its drawer of features.
DHH | Provide Sharp Knives
I’ve made many messes with Ruby code. You could argue this is the language’s fault, but I would disagree. I think in my cases, it was a lack of discipline and knowledge.
At times I’ve wanted to move to a statically typed language. I dream of the things the computer can do for me. However, in my experience so far it comes at the expense of the flexibility of using Ruby.
Several projects come to mind when I think of Ruby’s flexibility:
- RSpec - A DSL for writing tests
- Ruby on Rails - That magical feeling when you first learn how to use Rails (AKA “Look at all the things I’m not doing”)
- dry-rb - The ability to express functional concepts and blend FP with OOP in Ruby
Stability
I can count on one hand the number of times my Ruby projects broke due to a Ruby version upgrade. Matz has often talked about how stability is an important part of the Ruby language. In his keynotes, he’s looked at other languages with not so great upgrade stories.
Granted, I wasn’t around for the Ruby 1.8 => 1.9 transition. I heard it was a little bumpy. However, in my experience, it’s been solid. I very much appreciate writing Ruby code with confidence.
Ruby Conferences in 2019
At the time of this writing, there are 16 scheduled Ruby-related conferences in 2019. This count is according to the Ruby Conferences website.
Cough cough, special shoutout Southeast Ruby.
Ruby Jobs in 2019
One of metrics, if you will, I use to keep an eye on Ruby’s “demise” is the number of available Ruby jobs.
One website I like to use is Stack Overflow Jobs. A quick search for Ruby returns 499 jobs in Ruby out of ~6000 total job postings.
A search for PHP on the same website returns 404 (job not found lolz) jobs. I consider PHP to be one of the more widely used (and not dead) langauges on the internet.
Searching for Java returns 2,500 jobs. JavaScript returns 1,950 jobs. However, I expect that. Those languages (as far as I know) have always seen wider adoption.
Stack Overflow Jobs isn’t a full representation of the job market. But, the jobs listed on Stack Overflow are legitimate companies hiring developers.
If I were to look for a new job, this would be one of the websites I checked first. I might also check We Work Remotely and the physical job boards at RubyConf and RailsConf, which have no more room by the time we leave.
All to say, I would feel comfortable finding a Ruby job in 2019.
Conclusion
I’m happy with my decision to dig even deeper into Ruby in 2019. Ruby isn’t perfect, but it still fits the way I view the world quite well.
I’d be lying if I said I wasn’t envious for features from other languages. But, at the end of the day, I’m solving problems for people. Currently, I’m best equipped to do that using Ruby. The cool part? I’m happy while I do it.
Is Ruby the right tool for every job? No.
Are there valid reasons to look at other languages? Yes.
Are things still happening in Ruby? Hell yes.
Jason, you didn’t reference The TIOBE Index! Whoops.
Can Ruby and (Insert Language Here) coexist? Absolutely. I think too often we approach programming language wars as you have to choose one or the other. I don’t think that is the case.
Jason, are you going to keep using Ruby in 2019? Yes. But, that doesn’t mean I won’t try and learn from other languages and ecosystems.
Is Ruby dead? Nah. (isrubydead.com)
Follow me on Twitter.