Q&A with Matz

by Yukihiro "Matz" Matsumoto

The video features a Q&A session with Yukihiro "Matz" Matsumoto at RubyConf 2018, focusing on the development and future of the Ruby programming language. The session touches on several key aspects of Ruby 3, including performance enhancements, community involvement, and future language features. The main topics discussed include:

Ruby 3x3 Initiative: Matz reflects on the ambitious goals of Ruby 3, aiming for a threefold increase in performance, noting that some applications have seen significant improvements, particularly in CPU-bound tasks.
Performance Benchmarks: While benchmarks show promising results, Matz indicates that improving I/O-bound performance remains a challenge, mainly due to operating system limitations.
Future Release Timeline: Matz discusses the projected release date for Ruby 3, humorously linking it to good numerology with the date 10-20-2020.
Community and Core Team Dynamics: A question about the smaller size of the Ruby core team compared to other languages prompts Matz to emphasize that he values the canonical implementation of Ruby for ongoing development and experimentation.
Upcoming Features and Tools: Matz shares excitement about the future of Ruby, mentioning his work on steady advancements and the potential development of tools like formatters and linters following the Ruby 3 release.
Type Analysis Discussion: The conversation includes discussions about programming language features, such as gradual typing, with Matz expressing concerns about type annotations potentially altering Ruby's essence.
Maintaining Compatibility: The importance of keeping the Ruby community unified by addressing backward compatibility in Ruby 3 is emphasized. Matz highlights the need to evaluate proposed changes carefully to avoid past mistakes witnessed in other languages.
Gemification of the Standard Library: Matz mentions plans to modularize the standard library by extracting parts into separate gems to improve maintenance and development efficiency.

The discussion concludes with Matz acknowledging the significance of community input and the need for clearly defined proposals for Ruby's future enhancements, reiterating that collaboration remains essential for the language's progression.

00:00:16.250 Okay, so hi! How are you? Great! Having fun in LA this year? Yeah? You've been traveling a lot? That's neat.

00:00:28.859 I was gonna mention that I don't know if you've all heard, but the Crystal Ballroom upstairs—that particular room—if that looked familiar to you, it is the room where they catch Slimer in 'Ghostbusters'. They destroy the chandelier, and it falls to the floor, and they get a giant bill and walk out covered in goo. So go home and watch 'Ghostbusters' on Netflix or somewhere because that's the ballroom we're talking about.

00:01:02.120 Yeah, anyway, thank you for reminding me! So let's see, a couple of questions... What should I do first? I think around this time last year you talked a lot about Ruby 3x3. How do you feel that effort is going so far?

00:01:15.630 I first mentioned Ruby 3x3 two years ago, and at that time, I had no idea how to implement that. I just said, 'Yeah, sure! That sounds fine.' But you know, it was ambitious, and indeed, I had no plan or particular technology to improve the speed yet. But saying that encouraged the community. So that the rod, read email, Buckle Off came to their rescue.

00:01:39.060 We have had some games that are running three to four times faster in some cases. However, it requires a significant replacement, which is quite heavy and pretty difficult to make compatible with the current implementation. Takashi Kokubun gave a presentation this year; he used the MG technology and framework to implement the JIT compiler for our bytecode.

00:02:02.820 Now, for CPU-bound benchmarks, it is 2.5 times faster than Ruby 2.0. That’s pretty close to what we're aiming for. Do you feel that the benchmarks you're using, like the Rails benchmark, are helping to measure that effectively?

00:02:56.099 Yes, but you know, improving the performance of I/O-bound applications is difficult. Most of that time is consumed waiting for the operating system in the virtual machine. So, in that sense, we have seen decent improvements for CPU-bound applications like Optical, but I hope we can also improve performance for Rails applications.

00:03:16.480 You know, it's been a couple of years now. Do you have any rough feelings about when that might be? I mean, two and a half times is a big improvement over two years, so I would say that's a success. Kudos to everyone who has been working on that! What does your gut say? Is it another two years before Ruby 3? Or...? We’re not holding you to it on camera or anything!

00:03:43.470 You know the famous Kennedy speech with the 'Indus Decayed'—well, that's good, right? That's two years. So yeah, today, not to you though, because you know, this decay means that it has to be released before 2020. Okay, I will miss next year’s deadline! At the beginning, I thought it had to be released in December 2020, but it turns out it's not to show for us right now.

00:04:36.120 So basically, the current plan is for it to be released in December 2020. 10-20-2020! I like that it's good numerology! That's great! It's been wonderful working on those kinds of things before, and it's been great to see the progress.

00:05:32.910 How's everyone doing? Any questions yet? Come on, come on, I wasn’t joking! I hope you’re lined up!

00:05:46.560 Hi! I'm Yuri. I work at Square. Before that, I worked at Twitter. I've been working with Ruby for more than seven years and it was fascinating to see your talk when discussing the popularity of Ruby, how we were at a peak, and now we may be in a dip or plateau.

00:06:02.580 Here's my question: One of the concerns I hear from many people deciding on a language for new projects is that there aren’t that many people working on the core Ruby team technically. For example, Python has more sponsors and a larger team. Is there any concern there for the future?

00:06:25.919 I, for one, care little about popularity. Maybe in the future, JRuby or Truffle Ruby will be mainstream, and most people will use those implementations. As long as they are compatible, that's fine. The point is that I, as the language designer, need a canonical implementation to experiment and play with. I have long experience with MRI, and it's quite difficult for me to work and experiment on JRuby or Truffle Ruby.

00:07:22.759 That said, new design, new language features, and new libraries should come to MRI first. People in the community might use different implementations for their applications, but that's okay. In the past, Heroku hired people to work full-time on MRI.

00:08:17.360 Yeah, several companies have allowed their employees to work on improving Ruby during business hours. This kind of collaboration has been quite valuable.

00:09:09.460 I have a question. What are you most excited about for future versions of Ruby, especially in features? We know we have garbage collection improvements and the JIT, but outside of those, what are you most excited about in the next year or two?

00:09:32.540 In terms of features? Well, I have some branches on my laptop that I haven't committed yet, and they contain various interesting methods and implementations. For example, years ago I modified Ruby's scoping rules, but I concluded that it caused confusion.

00:09:50.730 I’ve had a lot of silly ideas and experiments. To go back to you: Have you thought about creating a Ruby formatter? Recently, there's been a lot of talk among Ruby developers about linters like RuboCop. Have you considered developing a standard formatter that would define how Ruby code should look?

00:10:25.989 My plan is to focus on improving the language until Ruby 3, but after that, I have some ideas about working more on tools like formatters, linters, and analysis tools. These are valuable, and I should probably focus on getting those tools developed.

00:11:04.550 In previous years, you've mentioned considering gradual typing for Ruby 3. Are you currently thinking about a gem like Steep actually making it into the core?

00:11:44.150 We are working on some type analysis tools, such as one from Cookpad that works on abstract interpretation. The team from Stripe is also working on static type checking tools. Each has its pros and cons, and we are looking to combine them into one great type analysis tool for Ruby.

00:12:05.830 We are not planning to add type annotations like in PHP or Python 3; I personally find those annotations cumbersome. I believe we can generate type definitions from our static analysis tools without changing the fundamental nature of the language.

00:12:51.780 The homework I have from our meeting last night is to avoid those annotations, as adding them changes the nature of Ruby itself.

00:13:18.400 As the community grows, it’s becoming evident that there's been a lot of discussion around these features, especially regarding type annotations. The question is, how do we make that type system work without compromising Ruby's essence?

00:14:09.430 You mentioned that annotations can change how language functions. How can we keep the spirit of Ruby while adding useful features like type analysis?

00:14:51.160 The goal is to allow Ruby programs to remain as they are now while finding more bugs at compile time. It doesn’t have to be sound or complete. We don't anticipate diving into overly complex types, but manual type definition files will be available.

00:15:21.950 If someone wants to propose a feature for Ruby, they should create a proposal and submit it to our bug tracker. We need concrete analysis or use cases to actually develop these ideas into features.

00:16:04.440 I know we have had several conversations about the Ruby core team considering adopting new processes for evaluating features. However, most proposals tend to be broad without clearly defined goals.

00:16:50.140 The core team should focus more on concrete examples, use cases, and analyses that list clear motivations for why a feature would benefit everyone.

00:17:35.560 So it's important to provide the reasoning behind any proposed changes. While many ideas are great, for additions to the standard, we must be careful about making Ruby grow too large too quickly.

00:18:19.600 My casual question is, do you have any interests in other languages? What features are you looking at that excite you right now?

00:19:02.160 I’ve been looking at Elixir recently, particularly the pipeline operator, which is quite inspiring.

00:19:48.680 Some of the backward compatibility challenges you mentioned also arose in Python 2 to 3 transition. What are your plans for maintaining compatibility in Ruby 3? It’s essential to keep the community unified in moving forward.

00:20:35.440 In the past, breaking compatibility caused community division, which I want to avoid in Ruby 3. So, while I recognize that certain changes might lead to incompatibility, maintaining community trust and cohesion is of utmost importance.

00:21:41.900 I believe it’s vital for the core team to keep in touch with community interests and ensure that proposed changes are not conflicting with the established practices. Some shifts may indeed require difficult choices going forward.

00:22:24.980 Are there still plans to extract parts of the standard library into separate gems? I believe this could help streamline development.

00:23:05.400 Yes, we are considering moving toward gemification of the standard library to improve maintenance and avoid issues from past library authors retiring or leaving.

00:23:41.400 Thank you for your time. This has been a very insightful discussion, and I appreciate hearing your thoughts on the future of Ruby and the core team's direction.