Introduction Our friend Yukihiro Matsumoto, creator of the Ruby programming language, joined us for an interview right after the release of Ruby 3.0! Grigory Petrov, Developer Relations at Evrone, spoke with Mr. Matsumoto about the new features in the latest major Ruby release. Mr. Matsumoto also shared details about his approach to improving Ruby and gave us insight into the future of the language. The Interview Grigory: My name is Grigory Petrov, and I am here to interview Yukihiro Matsumoto, author of the Ruby programming language, just a few months after the major Ruby 3.0 release with all of its new shiny features. Thank you for joining us and for releasing Ruby 3.0. This is a huge release with a lot of experiments, feedback, challenges, and features. Which feature of Ruby 3.0 do you like the most? I like pattern matching, including the right-hand assignment. At the same time, I'm very excited about the ractors and the static type checking, because I think it will change and enhance the culture of Ruby programming. Yukihiro: Grigory: Yeah, static type checking is really amazing. I am looking forward to seeing how your idea of adding types in the standard library and frameworks will work out. Pattern matching is also really great. I miss it in Python, and it's a pleasure to use it in Ruby. Ruby 3.0 is backward compatible. That's great, because developers hate to break things, and they love the idea of not breaking backward compatibility. Can you recommend this approach for other languages? Is it a good idea to keep backward compatibility? Yes. When I started Ruby programming, the Ruby community was pretty small. So it was okay to throw out the older version and break the syntax of the Ruby language at that time. But as time has gone by and the Ruby community has grown bigger, with millions of Ruby programmers all over the world, even the tiniest change can now break things. Yukihiro: Last time we made a big breakage in Ruby 1.9, we learned the lesson that a big breakage can split the community for a long time. I made a decision, after Ruby 1.9, that we would not make a big breakage, even on a major version release. Other languages, like Python 3 or PHP 6, had a similar issue, which taught us the importance of backward compatibility. Language designers want to make progress, make changes, improve the language. But if it comes at the cost of compatibility, that is not good. We try to keep compatibility as much as we can. However, on the other hand, as you said, developers like new things, so we do have to add new features, and that makes it kind of a contradiction. But I think we tried our best, at least for Ruby 3.0. Grigory: Yes. That was really well done. And I hope that other languages can follow your steps and also keep backward compatibility. I remember, 10 or 15 years ago, all these tragedies were happening with Python’s transition from version 2 to version 3. This lasted for some years, and core developers weren't even sure if they should continue developing Python 3 or just fall back to version 2 and be happy. Also, something similar was happening to PHP. I'm happy that, right now, we are at the stage of development where we can bring amazing features without making millions of developers sad. Let’s talk about features. Programming languages borrow features from each other. We can see pattern matching in Ruby, and fellow developers can use hash destructuring in Python, JavaScript, and now in Ruby. Maybe the right-hand assignment will be borrowed by Python or JavaScript in the future. What are your plans for the next versions? Do you have any crazy ideas, things you want to borrow, or just test drive? That's a great question! But we have been focusing on Ruby 3 for a long time, and it's only been a month since the release, so I have not yet had those crazy ideas for the future yet. It might be enhancing the ractors and the module system for Ruby. Java and Python have the module system. Also, it might be useful to provide a structured packaging system. I have some vague ideas, but not concrete enough to disclose yet. Maybe you’ll have to wait a year or so. Yukihiro: Grigory: No problem. I've been writing code for 20 years, and I will be happy to write code for 20 more years. By the way, the Ruby packaging system may be not as full-featured as it is in Java, for example, but Ruby allows users to install and use multiple versions of the same dependency. And that's actually great, because Python, for example, can use only one version of the dependency, which creates a lot of issues. And Javascript, Node.js, just put versions in the specific directory. So, Ruby feels pretty great with the current system, but we will always look forward to new improvements. Yeah, we might prepare some kind of containers, so that the different versions of gems can reside in different containers or something like that. Yukihiro: Grigory: Yes, you have a lot of time to test it out. There are lots and lots of new programming languages that appear. How do you keep an eye on them? Do you have some RSS subscriptions or developers who come to you and tell you about new features? My major info channel is Ruby Redmine. We have tons of proposals from the community, and those proposals inspire me to design new features. I have to reject most of them, but these ideas to improve the language inspire me to design new ideas. Yukihiro: Before the pandemic, I attended many conferences and talked with people about Ruby, and programming in general, so that I could see the obstacles, the irritations, or the drawbacks of the language and the environments, and then I tried to improve them. These kinds of talks and conversations inspired me a lot. And that's one big drawback of the pandemic, that I couldn’t have those kinds of conversations any longer, for the last year and a half. Also, I surf the Internet and read blogs about programming languages and Ruby. Those articles inspire me as well. Grigory: So, if any one of our readers want to offer some interesting ideas to Yukihiro, they can use Ruby Redmine to suggest! And about this pandemic issue, everything is done from home, all conferences are online, how has this affected Ruby development, adoption, and the community, from your point of view? Well, day-to-day development has not changed that much. I live far from Tokyo, and our developers’ meetings and communications were heavily Internet-based, even before the pandemic, so this process did not change. But as I said before, we don't have physical conferences now, so that is one of the bad things. Yukihiro: But, on the other hand, I don't have to travel as much. I can stay home, have more time in front of my PC, and spend more time on programming or Ruby itself. Grigory: That’s great. By the way, during the last pandemic year, we organized and attended lots of online conferences, and so did you. What is your opinion about online conferences? Are they helpful? Can you collect feedback from them and communicate with other Ruby developers? For the conference attendees, the value is still there with online conferences, in the form of presentations. That's okay. But, at the same time, offline communication, having dinner or having a silly conversation together, these kinds of side channels are dropped from the online conferences and are things that I miss very much. The value of the conference is in that kind of communication. Yukihiro: Grigory: By the way, are you interested in joining us at our online RubyRussia conference from the comfort of your home? Sure! Yukihiro: Grigory: Great, I will send your invite in a few months! You do lots of experiments with the Ruby language. You add features to enhance new versions, and remove features if you and developers dislike them. I have not seen such a thing in other languages. How unique is this to Ruby? Did you see something like that in other languages, or you are the only person who does it? And what are the pros and cons of such an approach, where you give hundreds of thousands of developers something to try, but if it does not work out, you take it back? Okay, when the Ruby community was small, and they didn't care about the changes, everything was experimental. If it didn't work out, we just removed it, nobody cared about the compatibility. But those good old times went away, and now we have a huge community. Yukihiro: So, the cost of the changes is getting bigger and bigger each year. That means that Ruby design decisions cannot be reversed. That means the designers cannot make mistakes. I'm only human, and I admit that I make many mistakes. At the same time, while the Ruby community is big, our Ruby core developer team is not big enough to predict the future. If I can propose something, if we can experiment with these ideas within the core community, that's okay. But our core community is not big enough to experiment with those ideas before the release. Experiments we do with Ruby features are a compromise, fit for the current size of the core developer community. The big Ruby community does not allow me to make mistakes, but the size of the core developer community does not allow us to do all experiments internally. We have to ask the community to try things out. Once our core community is big enough to experiment internally, we will no longer need the process of public experiments. But, right now, it is a compromise. This happens with other languages. Python and PHP communities are big enough to experiment with everything within the core developers. But the current Ruby community size does not allow that kind of process. Grigory: I see the Ruby community and language adoption is growing. So, I hope that in a few years, it will have a solid opportunity to keep experiments limited to core developers, and all Ruby developers all over the world will receive a final version that they can use. Language design is pretty fun. The one very big benefit of language experiment is inviting the user community to help design the language. Even when we have a big enough core devs community, we may invite the broad Ruby community to participate in some language experiments. Yukihiro: Grigory: Yeah, or users who want to be involved in language development. They can join the core community and prove that they are worthy to participate in all these experiments. Most Ruby users do not even consider the possibility of joining the design process! That would be useful. Yukihiro: Grigory: I have a tricky question about all the ractors and async I/O fibers. I am a big fan of concurrency, both parallelism and multitasking. And right now in Ruby 3, developers have a big choice. For parallelism, we can use processes or ractors, and for multitasking, we can use threads or async fibers. How can a typical Ruby developer choose between them? For web applications, web developers don't have to care about concurrency, because the application servers, like Unicon, Puma, and Falcon, take care of concurrency. Unicorn uses processes, Puma uses threads, and Falcon uses fibers. The choice of the application server directly affects the choice of the concurrency system. Maybe we will have a ractor-based application server in the future. But not yet, so the choice of the application server directly affects the choice of the concurrency model. So, web developers do not have to care about concurrency. Yukihiro: A typical developer experiments with concurrency while investigating application bottlenecks. If input/output is the bottleneck, then it's wise to choose the async fibers. Async fiber is optimized for I/O multiplexing. If your program uses a lot of I/O communications, then choose async fiber. And if you want to experiment with the multicore and CPU-heavy tasks, then choose ractors. That's the basic choice, because the current ractor implementation matches one ractor to one native OS thread. You cannot create millions of ractors right now, because each ractor consumes a few megabytes of stack memory. That is huge. And fibers only consume a few kilobytes of memory or less. So, you don't have to worry about the memory cost of the fibers, you can create as many fibers as you want. That’s the second criteria of the choice. Koichi, who is in charge of ractors, is working to improve them. Maybe, in the future, ractors will not consume so much memory. Maybe, in the future, we will be able to use ractors the same way Goroutines are used in Go. But that is a future story. Grigory: Yes, and that future sounds bright. As for now, I really like the idea of framework offers to put some famous Ruby convention over configuration, so Ruby developers can use the model that was pre-selected by framework offers. And after that, if something is slow, Ruby developers can dig deeper and switch Rails to a different concurrency primitive. It's great to have some choice. One more question about the speed. Recently, I stumbled upon a short article by David Heinemeier Hanson, who mentioned an interesting observation that, for his entire fleet of servers that provide Basecamp and Hey.com email service, only 15% of the Basecamp ops budget is spent on Ruby. Making Ruby even 10 times faster will not be a game-changer. How important is the raw speed for Ruby? I have kind of mixed feelings. For most web applications, Ruby and business logic are not the bottleneck. Most of the time is spent working with databases, network connections, and operating systems. Shopify and GitHub use Ruby, so the speed does not matter that much. They’ve grown big, without any problems. If we focus on the productivity of the programmer, then the performance is not the biggest issue. Yukihiro: That was my opinion for a long time, up until a few years ago, when I realized that so many people make decisions based on microbenchmarks. All these Fibonacci numbers and n-body benchmarks are kind of silly, but they are kind of a developer instinct. A few years ago, I just gave up on getting developers to act against their instincts and started to improve Ruby performance, even on the microbenchmarks. JIT compiler is one of these improvements. JIT compiler does not improve Rails application performance right now, because the apps spend their time on database access and network access. But the JIT compiler can improve the performance of the microbenchmarks. But, at the moment, the compiler does not improve the performance of a Rails application that much, because of the bottleneck. The application is set in the database access or network practice, but the compiler can improve the performance of the microbenchmarks. We are improving Ruby performance in every aspect, including the microbenchmarks. Since some years ago, I have been focusing on the microbenchmark performance. It is kind of silly, but it is due to the instincts of web developers. Grigory: Yeah, and JIT actually helps. The last time I checked the artificial microbenchmark, just enabling JIT for Ruby made it ten times faster. So that really helps. Yeah, we are not fighting against instincts. Yukihiro: Grigory: The last technical question is about batteries included in the standard library. There are two approaches. The first one is what Python is famous for. A huge standard library with everything, like FTP-client, email-client, and zip archive, included. Beginner developers like it because they can use tutorials and get everything without installing dependencies. Everything just works. Core developers like it much less, because they need to support this huge standard library. They can't make breaking changes, because it upsets all the developers who learn the language. And these libraries, they are getting old pretty fast. Another approach is Ruby’s basic, low-level, standard library and ecosystem that flourishes and offers competitive solutions for everything. That's great for developer competition, and it drives innovation. But new developers are astonished, and they don’t know what to use. So, it's kind of controversial. What do you think about this controversy? Yeah, Ruby 1.8 took the "fat standard library" approach, but as time went by, some libraries were left unmaintained. We changed the approach by separating the library into gems. Yukihiro: Very few people used RubyGems with Ruby 1.9, but at the time of Ruby 2.0, RubyGems was set up for general availability. With Ruby 2.0, the RubyGems community became bigger and bigger, and everyone used RubyGems. So, if everyone uses gems, we do not need to bundle everything. So, we gradually separated the standard library into gems, making the standard distribution slim and maintainable. Remember, our core devs community is not big enough to be experts on everything. In general, our language core developers are not web developers. We are not good at maintaining web-based technologies like webrick, http clients, or even the xml processing. It was a good idea to keep these unmaintainable parts away from the standard distributions and make them gems. Now, developers can create competitive, better maintainable gems. Natural competition is a good thing! Grigory: Got it. With this pandemic issue and everything online, learning and education also went online. And for the last two years, I’ve seen lots and lots of courses, blogs, and places where developers can learn Ruby. They have new services, and I especially like Real Python for the Python language, and I hope something this great will be created for Ruby. So, what would you recommend for new developers who learn Ruby, or for seasoned developers who just want to brush up their knowledge for Ruby 3? Which books, blogs, or learning platforms would you recommend in the year 2021? In 2021, railstutorial.org and guides.rubyonrails.org have the best learning material for beginner programmers. The web application is a good example of programming, it's close to the real product. Nowadays, running scaffolding and writing several lines of Ruby code can make a simple web application. You can enhance those web applications in seconds and see the updated, improved web application. Yukihiro: The short development cycle encourages developers to learn more things. After the developer learns the insides of Rails or the insides of Ruby, they can learn whatever they want: machine learning, embedded systems. For beginners, the web application itself is a good starting point. Grigory: Yes, we also try to teach with web development, because it's what people consume every day. So, they are creating familiar things. And my last question. Recently I saw lots of Ruby awards in Japan, photos of government officials thanking developers for their work and so on. I have not seen anything like that in other countries or for other languages. So, is this appreciation from the government and all of the government-run events for Ruby something specific to Japan or Japanese culture? Or maybe it's something specific for Ruby, or is it both? Well, the developer community is quite similar both in Japan and outside of Japan, for example, in Russia, the United States, and Europe. But the difference is that Ruby is considered to have been born in Japan, some people in Japan want to encourage it, especially in the local government sectors. Yukihiro: I personally have a good relationship with the state governors and the mayors of some cities. They want to encourage the Ruby community by organizing conferences and awarding prizes. That’s their way of encouraging the community of a technology that is considered to have been born in Japan. In that sense, these kinds of local government programs are unique to Japan, but the local developer community is quite similar to other countries. Grigory: That's amazing. I hope to visit Japan someday after everything! See you later in the fall of 2021 at Ruby Russia. Thank you a lot. I hope, with our questions and your answers, our discussion will help developers to become better, to write better code, to be happier writing better code. Arigato. Watch the video interview here: https://youtu.be/B-UFFo4M-04 Conclusion Through our interview with Mr. Matsumoto, we learned more about the latest Ruby features and how the growth of the community has affected the development of the language. We also gained some great insights into the future of Ruby, and Mr. Matsumoto shared with us his love for the Ruby community and how much it drives the development of new features and new ideas. If you have a cool idea and love Ruby as much as we do — let's create something together! We love partnering with new people to build innovative new products. Let us know how to contact you, and we’ll be in touch as soon as possible to discuss your idea and how we can make it happen. . Previously published here The author of the story is the Chief Editor at . Evrone
