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.
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.
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.
try uses the
send method, which is not really fast enough. I believe those kind of things should be built into the language.
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.
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.
No, but the frozen string literal pragma is kind of controversial. We might change it in a later version.
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.
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.
I hope we can have this kind of conversation again in the future!