Ruby 2.3 on Heroku with Matz

Happy Holidays from Heroku. Congratulations to the ruby-core team on a successful 2.3.0 release, which is now available on Heroku -- you can learn more about Ruby on Heroku at heroku.com/ruby. We had the pleasure of speaking with Matz (Yukihiro Matsumoto), the creator of Ruby and Chief Ruby Architect at Heroku, about the release.

What’s New in Ruby 2.3: Interview with Matz

Ruby releases happen every year on Christmas day. Why Christmas?

Ruby was originally my pet project, my side project. So releases usually happened during my holiday time. Now, it’s a tradition. It’s ruby-core’s gift to the Ruby community.

Do you have any favorite features coming in Ruby 2.3?

I’m excited about the safe navigation operator, or “lonely operator.” It’s similar to what we see in other programming languages like Swift and Groovy— it makes it simple to handle exceptions. The basic idea is from Objective C in which nil accepts every message and returns nil without doing anything. In that way you can safely ignore the error that is denoted by nil. In Swift, they have better error handling using optional types, but the fundamental idea is the same. Instead of using nil, they use optional types.

Since Ruby is an older language, it follows the old way. In the very early stages of Ruby, before releasing in 1995, I added that nil pattern in the language. But it consumed all the errors, which meant error detection was terrible, so I gave up that idea. With the new operator, you can use the nil pattern and avoid accidentally ignoring errors.

Swift and Groovy use a different operator: ?. (question dot). And Ruby couldn’t use that because of predicate methods. So I coined it from the &. (ampersand dot) pattern.

Was there any discussion of adopting Active Support’s try?

The try uses the send method, which is not really fast enough. I believe those kind of things should be built into the language.

What are some other highlights in 2.3?

The did_you_mean gem, which helps with method name misspellings, is great as a default feature. We bundle it now, so it’s now a default and you don’t have to do anything extra.

We included it because for Ruby 3 we’re working towards better compilation and collaboration, and this is the first step in that direction. Better error messages help developers’ productivity and happiness.

Are there any features that are not getting the attention they deserve or may surprise developers?

I don’t know. I like the new dig method, which is related to the safe navigation operator. It makes it simple to “dig up” nested elements from nested hashes and arrays, which is useful when dealing with parsed JSON. These days, this method is kind of popular, especially when using an API for microservices. In such cases, the dig method and safe navigation operator would be quite useful, especially with optional attributes.

Are there any features that you secretly hope no one will use, so you can remove them later?

No, but the frozen string literal pragma is kind of controversial. We might change it in a later version.

How would you decide if it stays or goes?

The Rails team got a lot of pull requests that say add the freeze everywhere. The literal freeze method is much faster by comparison in 2.2. People wanted to make it faster by avoiding the string allocation and reducing the GC pressure.

We understood that intention, but adding a freeze everywhere is so ugly and we didn’t want that. That’s why we introduced the magic comment of frozen string literals. At the same time, I don’t like that a magic comment can change the semantics or behavior of the language. So that point is kind of controversial. We’ll see how well it works out.

Do you anticipate any backwards-compatibility issues when migrating from Ruby 2.3 to Ruby 3?

Fundamentally, we will not change anything in a backward incompatible way. I expect every Ruby 2.x program to run without any modification in the future version of Ruby. Even the frozen strings stuff is basically compatible.

In Ruby 3, if we do have to make an incompatible change, we have to provide a reasonable reason. And also we have to provide a migration path that is not too difficult. That’s our strategy towards the future version.

Thank you for your time!

I hope we can have this kind of conversation again in the future!

This interview was conducted by Terence Lee and Richard Schneeman, members of Heroku’s Ruby Task Force. You can find them on twitter, @hone02 and @schneems.

Browse the blog archives, subscribe to the full-text feed, or visit the engineering blog.