As we wrote in the last blog post, there was an event, Ruby25, to celebrate the 25th anniversary of the programming language Ruby in Shinagawa, Tokyo on February 24th, 2018. Mr. Yukihiro “Matz” Matsumoto, known as the inventor of Ruby, and leading programmers of Ruby and Ruby on Rails gathered to speak about the current situation of Ruby at the event.
In the last segment of the event, there was an interview, “Ruby’s Future: A Talk About the Future by Matz & Miyagawa.” Mr. Tatsuhiko Miyagawa of a popular podcast on programming, Rebuild.fm, who is currently living in the United States as Principal Software Architect at Fastly, interviewed Matz.
In this post, we will highlight ten critical points about developing Ruby from Matz’s answers in the interview.
Matz_bot Will Take Over From Matz!?
Matz’s two daughters surprised him by getting on the stage and giving him flowers after his keynote at Ruby25. This scene looked as if Matz was retiring, so Mr. Miyagawa jokingly asked about Matz’s successor.
Matz: There are suggestions that we should let bots and AIs take over the positions (of Ruby’s leading developers), so we are working on that. We are discussing that we should start collecting our data as soon as possible.
Miyagawa: It seems it is technically possible, but can it be done? I assume it will be a bot who can express your opinion and what you like.
Matz: The bot will say “I don’t like the name” half the time. It will say “Not this name. Go back and come up with a better one.
And he laughed.
Additional propositions and functional improvement in developing Ruby sometimes get denied when the method name does not fit the Ruby brand even if the proponent displayed an excellent benchmark data and the actual use cases. The importance of naming has become part of Ruby’s culture, and Matz himself is the watchdog. When Matz finds a name unfit, the functionality addition patch will be pended until the proponent comes up with a better name.
Matz: We will be in trouble if I get into an accident now, but we might be able to make it by the time I retire if we start collecting my data now.
Mr. Miyagawa mentioned about the Benevolent Dictator For Life (BDFL) model. The BDFL model is used for governing and decision-making in open-source projects. The BDFL is a title given to the people who have the final say in arguments in the development communities. The BDFLs are usually the founders of projects or people who will be the lifetime project leaders. While there are many Ruby core developers, Matz is the one who makes final decisions on Ruby’s direction.
Matz: When you see Ruby as a software product, I think it is better to have one person who performs as the product owner or manager that gives his or her opinions and makes decisions on its design. In Ruby’s case, it is me. If I make a right decision, I get compliments. But if I make a terrible choice, I’m the one to be blamed. If someone proposes a great idea and I give the green light, I’m the one who gets all the praises. What a great system!
This made audience burst into laughter.
Is It Possible to Delegate Ruby Development Like Linux Subsystem?
Following the question of the BDFL model, Mr. Miyagawa asked whether it is possible for Ruby to delegate through subsystems like Linux kernel development and what’s going on with the latest Ruby core development.
Matz: Subsystem is not suitable for Ruby. Ruby is not like Linux. In Linux kernel subsystem, you can make small changes in the system without affecting the hole kernels. With Ruby, you can’t really do those.
At Ruby, we appoint teams for text strings, regular expression, and virtual machines. But I usually don’t judge their technical decisions. I trust they can do that on their own.
After all, as the Benevolent Dictator For Life, I have to make final decisions on what method we should add, what new features we should develop, or how we should name. It is hard to keep up with consistency when you develop Ruby for 25 years. Some people might point out some things were called differently in the past. But I believe we have been developing Ruby under one person’s policy in general.
Continuous Development for Ruby3.0
Mr. Miyagawa asked questions on Ruby3.0, the next major version update.
Miyagawa: You said the most important move is NOT to cut off the Ruby branch and develop separately from Ruby2.0, right?
Matz: That is right. I’m thinking to develop continuously. I used the branch model to update to Ruby2.0 for the first time because there were features that weren’t in Ruby1.9. I will keep coding on the master branch and call it Ruby3 when it reaches a certain threshold.
The discontinuous version update from Ruby1.8 to 1.9 caused a division in the Ruby community. I assume it was a costly transition for the people who kept using the old version. Even though the new version had terrific features and improved performance, some users didn’t get to enjoy significant benefits.
Some users had been using Ruby1.8 for five years, the worst case, ten years and updated reluctantly. It is a shame to have great talents dispersed. Ruby is not the only case. It happens with communities of other programming languages and is a common failure. This time, learning from mistakes of other programming language communities, I think it is better to develop Ruby3.0 with the versioning scheme. Linux team has been incorporating this scheme since its version 3 update. It is a development model that naturally lets you say “I’m going to call it version 3” after implementing changes. Following Linux as an example, I am going to use the versioning scheme for Ruby.
Ruby3 Will Be Backward-Compatible
Mr. Miyagawa asked if there will be no incompatible changes because the version update will be continuous.
Matz: There will be no changes that will cause incompatibility in general. I will fix minor bugs and implementation errors that were meant to work differently. I’ve done this kind of fixes through Ruby2.3 and 2.5. Of course, there will be reminders of the upcoming changes before I implement them in the next version.
It is hard to say all the technical decisions I’ve made in 25 years of developing a language are right. It will be a lie for me to say there was nothing I wanted to fix. Because I have the experience of moving forward without thinking carefully about backward compatibility, I sometimes need to ignore minor bugs and mistakes even when I’m itching to fix them.
Even if I want to make a minute change or fix a bug, there is a user somewhere in the world who is using that feature since the Ruby user base has gotten this huge. There will be someone yelling at me, “My program doesn’t work anymore! What have you done!?” Depending on the severity of the effect, I will need to revert the change, or simply apologize.
At Ruby, we are currently making very conservative decisions, considering the compatibility with the former versions. On the other hand, Ruby on Rails makes drastic changes and breaks backward compatibility. How they update is so different that it looks as if it is not in the same Ruby community. I think there is a reason for the difference. Ruby is a programming language, which acts as the base layer, so the changes can be impactful. The fundamental compiler technology was developed in the 1970’s. On the other hand, the web evolves rapidly, so new technologies and concepts, and things we need to be careful with such new technologies keep appearing. So, Rails’s decision to break backward compatibility to progress is incredible in its own way. Ruby developers are trying to improve performance and add new features while keeping the compatibility. That is technically more challenging in a way.
Deciding the Default Setting for Ruby While Considering JIT Performance
The following questions Mr. Miyagawa asked were on JIT that was implemented for the beta version of Ruby2.6 and on type inference which will be implemented in Ruby3.0.
Matz: MJIT*1 (implemented in Ruby2.6) is not a feature but an implementation for processing. While keeping the performance of Ruby, it makes the execution speed faster. I might enable JIT at some point, but I haven’t decided yet. Ruby can start up frequently like scripts, but it slows down the startup in the processor with JIT. It is slow right after the initiation and gets faster as it keeps compiling. If it is a long-running process as in servers, the overall processing speed is very fast. JRuby has this characteristic even though it is a Ruby family. But, it doesn’t mean this is ideal for all programs. We need to question ourselves when JIT should be enabled and whether JIT needs to be explicitly specified while considering the performance. I want to wait and see for a while. Because JIT consumes significant storage space, I want to avoid that to be the bottleneck.
Type Check Feature and IDE Code Completion are Possible with Type Inference
Miyagawa: Ruby3.0 will have a type inference feature called Steep*2 right? Are you firm on not writing types?
Matz: Yes. In the Ruby community, many people say it is ok to write types for prototypes. I am the only one who stubbornly says, “I don’t want to write types!” so they give me the side-eye.
Ruby can execute without writing types. I think it is not DRY (Don’t Repeat Yourself) if you write types unnecessarily. When someone tells me it is better to write types even though it is unnecessary, I would say “Why?” I just don’t like writing types on the code typefaces.
I think it is possible in future to collect the data types on execution and use it for type inference with Ruby. I picture it to be something similar to the IDE code completion.
Miyagawa: Even though I like coding with Ruby, I can have a sense of security and comfort when specifying the type while coding with Go for example. Probably, it is a different kind of comfort from Ruby.
Matz: Right. The more data you have, the more you can do. If you develop in Java with Eclipse, its tools support refactoring,which is useful. You can also work on refactoring by replacing texts using Emacs and grep. But, when you want to change the class name, it is better to change the name and the data type all at once. If you can store the data type in a separate file, Ruby can write accurate programs and support reading to make changes at once. We are aiming to provide what Go and Java can do well while keeping Ruby as it is even though it might not perform entirely the same as those programs.
No Additional Magic Comment (Pragma) in Future Ruby
Mr. Miyagawa asked if there will be new syntax or features since it will be compatible with the old version.
Miyagawa: If you are going to add new syntax, it must generate a syntax error in the current Ruby, right?
Matz: Yes. Something that is questionable is whether the syntax check can go through Ruby. It sounds irresponsible for me to say it as the person who wrote the parser, but it is difficult to add new syntax because the range of syntax errors is pretty small.
Miyagawa: Are you going to use something like opt-in pragmas to change the parser behavior?
Matz: The closest thing in Ruby t to change the behavior is the magic comment. The most impactful comment is “frozen_string_literal,” which disables changes in literal strings, meaning immutable. Should I make this as a default setting for Ruby3.0? My answer to this question changes every time someone asks me. I have an internal debate. “This kind of big change is not good. But the version 3 will be a great opportunity to change something major.” Probably, it won’t make it in Ruby3.0, but I have to start thinking about package and namespace seriously.
A Tool to Support Humans
Miyagawa: Do you think programming should progress in the direction of computers that support humans?
Matz: Basically, we don’t need programming languages if we can process information like computers. We can just start speaking in binary numbers. Unfortunately, we are not capable of doing so. As a compromise, we are using programming languages. But how much should we compromise? In Ruby’s case, we are always on the side of beside humans. Our ideology is to make everything easier for humans by having machines make an effort. If computer performance gets better and better, we will have more time and manpower, so we can use the resources for supporting development. That is Ruby’s philosophy.
Miyagawa: Is Ruby a tool we can dump what we are thinking?
Matz: Right. Writing only what we want to do is ideal. But computers are not that smart, so we write how instead. When we want to minimize the gap between us and the computers, we want to teach computers what we want by using Ruby.
The Popularity of Python Is Something to Fear?
Miyagawa: I think Python has earned its position in the new education system recently. As a programming language, Python is versatile and performs well in practical situations such as machine learning. How do you feel about the popularity of Python?
Mats: For example, about ten years ago, when Ruby was on the front line of web development and Rails was popular, Python team was working on scientific computing libraries and made a consistent effort to improve in the direction of education. Probably, the consistency led to the current popularity of Python. I think we, Ruby team, should follow a similar path.
Miyagawa: I don’t think Python and Ruby are 180 degrees apart, opposite to each other.
Matz: Probably about 60 degrees.
The audience bursted out in laughter.
Future Plans for Inventing Something New?
Miyagawa: You built Ruby, a programming language, and it is your most known product. Are you planning to develop something else?
Matz: It doesn’t mean that I haven’t thought about working on any side projects. Several years ago, I built a programming language called Streem*3. It is a different type of language from Ruby and on a small scale. It is still at a toy-level. It’s been fun to work on, and I sometimes have fits of trying out new Streem ideas. I think I will continue doing something like that. If I have to choose what I want to do, I’ve been wanting to create a database since long ago. Redis is very close to what I want to create. After all, I like the base layer of programming. But the first step is the highest hurdle.
Ruby is my lifework, so I will never retire from developing Ruby. I want to be involved in the Ruby development as long as I’m alive. Also, I want to create a system to let others continue developing Ruby by the time I retire.
For more information about Sider, please go to our website.