Ruby Video
Talks
Q&A with Matz
Evan Phoenix
@evanphx
Yukihiro "Matz" Matsumoto
@matz
#ruby
#yjit-yet-another-ruby-jit
#jruby
#performance
#community
#language-server-protocol-lsp
#static-typing
Summarized using AI

Q&A with Matz

by Evan Phoenix and Yukihiro "Matz" Matsumoto

This video features a Q&A session with Yukihiro Matsumoto (Matz), the creator of Ruby, and Evan Phoenix at RubyConf 2021. The discussion revolves around Matz's experiences over the past 28 years of working on Ruby, the impact of the pandemic on his work and community interactions, and the future of the Ruby programming language.

Key points discussed include:

  • Life During the Pandemic: Matz reflects on the past 18 months, mentioning a lack of travel and physical conferences, which has made life easier but has also caused a longing for community interaction.
  • Longevity in Ruby: Matz discusses the long duration of his work on Ruby and his thoughts about potentially taking time off, indicating he may consider stepping back around 2025.
  • Ruby's Next Steps: The conversation shifts to technical aspects such as upcoming features in Ruby, like the integration of YJIT (a JIT compiler) in Ruby 3.1, which promises performance enhancements while keeping the traditional MJIT engine available for compatibility.
  • Tooling and Performance Goals: Matz outlines plans for Ruby’s future toolset, focusing on improving productivity through better development tools rather than radical syntax changes, and setting performance targets for Ruby 3.x versions.
  • Static Analysis and Compatibility: They touch on advancements in static analysis tools, such as the type profiler, which improves error checking in Ruby programming.
  • Future Features: Discussing the future, Matz hints at ambitions for Ruby 4.0, emphasizing improvements in performance and developer tools.
  • Community Engagement: Matz concludes by highlighting the importance of the Ruby community and expressing hopes for more in-person interactions at future conferences as the situation improves.

This Q&A effectively captures Matz's insights and plans for the Ruby language while reflecting on the community's role and future developments. It serves not only as a retrospective on the language's journey but also as a hopeful look towards advancement and adaptation in the programming landscape.

00:00:10.639 Hi everybody, welcome to our annual chat with Matz. It's great to see you! How are you today? I'm great! This is a fine day today here in Japan. It’s getting cool.
00:00:48.160 Yes, in the last one and a half years, I have had no business trips and no physical conferences. My life is much easier because I don't have to move around the world, but at the same time, I lost a lot of chances to meet the community in person. That is kind of sad; I miss that.
00:01:12.880 Yes, I've had lots of time with family and pets, though my children might not like that as much.
00:01:24.840 This brings me to the first question I had. People are curious because you've been working on Ruby for quite a long time. How long has it been now?
00:01:54.640 I started working on Ruby in 1993, so it's been 28 years. It's curious—some people ask me about if you have thought about taking time off or if someone else might step into that role for a while.
00:02:11.599 Yes, I'm vaguely thinking about taking a longer break when I turn 60, which is four years from now, probably around 2025. I don't know; maybe we have to appoint somebody to take my place for a while. But I'm not sure if I want to.
00:02:52.959 I think for that time, we might have a committee to help, as I have concerns about that. People ask these questions because they want to make sure you don’t burn out—doing the same job for 28 years is a long time.
00:03:16.160 It definitely has been a long time and has become a part of my life, so I don’t worry too much about burning out. However, I could get sick or hit by a truck, so I worry about that.
00:03:45.040 The core contributors and core team members will help decide the direction, but ideally, we can assign a single person to lead the community and design the language.
00:04:06.240 I had one idea: maybe we can fork the Ruby language and name it 'Ruby Fork' or something like that. It could allow for experimentation without worrying about compatibility. The idea would be for contributors to train as language designers, and after that, they could work on the main Ruby language, possibly called Ruby 5.
00:05:00.400 Being a programming language maintainer is such an interesting role. In fact, if you think about it, all of the programming languages that have reached the level that Ruby has could fit in a small conference room. How do you train someone for that? It’s such a unique process.
00:05:51.759 Alright, let's talk about some tech stack stuff. I saw that YJIT work is going into Ruby, and I wanted to ask about it. First of all, that sounds amazing! The folks at Shopify did a great job on it. Are we still going to have MJ? Will both be there for a long time?
00:06:14.160 For a couple of reasons: One, YJIT only supports the Intel instructions and is less compatible with other architectures like ARM, PowerPC, and less popular CPUs. Therefore, MJ will still work and will continue to be there. The second reason is that YJIT uses the GCC, a fully optimized C compiler, which can improve performance overall.
00:07:04.240 So users will not have to manually decide whether to use YJIT or MJ; the system will automatically configure based on runtime benchmarks and profiling.
00:07:35.680 I tried YJIT right before this Q&A session after recording the keynote. It's going to be integrated into Ruby 3.1, which is expected for Christmas.
00:08:09.120 Yes, as a programmer, I feel like I’m transitioning away from being an active CRB programmer. The contributions now depend on the core team, and I really appreciate all the work they're doing.
00:08:45.600 Regarding MRuby, I have started working on the release of MRuby 3.1, which will have compatibility with CRuby features, but I still want to make sure it doesn't introduce any conflicts.
00:09:02.000 For example, keyword arguments will be newly available features, but pattern matching might not be ready yet. However, the performance of MRuby is improving and its memory consumption is being reduced.
00:09:38.720 Recently, someone is working on a smaller compiler because the MRuby compiler is too large for microcontrollers. They are developing it to compile Ruby programs into bytecodes on a host and transmitting those to microcontrollers.
00:10:14.080 One person is even making a self-made keyboard using Raspberry Pi Pico to run Ruby.
00:10:28.320 We better not tell Aaron Patterson about the Ruby keyboard; by the time this keynote comes out, he might already have one!
00:10:35.840 He is likely to give a presentation about Ruby at this conference. If anyone hasn’t watched it yet, please look it up. He did a terrific job at Ruby Kaigi last month, even though it was conducted virtually.
00:11:15.520 During this week, there was discussion about removing the GIL from Python. Are you aware of that? Yes, I’ve seen discussions about Python's performance, including creating faster implementations. Ruby and Python have both experimented with performance boosts in the past.
00:12:18.639 However, many attempts had to be discarded due to compatibility issues, including libraries like NumPy that relied on certain exclusivity of the GIL. If Python succeeds, that would be good news, and we could potentially borrow ideas from them.
00:13:07.360 It’s interesting how removing the GIL can lead to challenges with accidentally locking, as you've called it. Libraries that rely on it might break, making transitions complicated. There’s also the risk of introducing new unintuitive behaviors.
00:14:01.680 That's why for Ruby we are taking another approach, such as Ractor, which is easier because it allows for separation in the runtime. It was released with Ruby 3.0, but the API is stable now even though the implementation is still being improved.
00:14:44.480 The fiber scheduler was introduced in Ruby 3.0, a fundamental part of asynchronous I/O. We’ve seen applications like Falcon utilizing fibers, and we are discussing further integration of async features through higher-level APIs.
00:15:20.000 The last year really feels like we're revisiting some of the ideas from Ruby 1.8, where we had green threads and important considerations in reading from file descriptors while avoiding blocking. That was nostalgic.
00:16:23.680 About static analysis tools, we have the Type Profiler, which has seen significant improvements. It works similarly to TypeScript, offering type checking via plugins in environments like VS Code. Users will benefit from these additional features without needing to write type declarations.
00:17:32.560 Even with my use of Emacs daily, I appreciate how tools are evolving. They enhance programmer productivity and help make Ruby as efficient as possible.
00:18:04.480 Regarding Ruby 4, I've set goals for enhancing tools like Solargraph, improving performance benchmarks, and focusing on micro-benchmarks to ensure that Ruby remains competitive. Our long-term vision includes that Ruby 3.3 will be three times faster than Ruby 3.0.
00:19:25.760 As for maintaining the Ruby parser, Ripper will remain a standard parser. However, we need to keep improving it to support streaming and error reporting without blocking the process, which is crucial for language tools.
00:20:19.200 At the end of the day, the Ruby community is a critical part of the language's success. This conference is a key component of that community, and I look forward to future gatherings, both virtual and in-person.
00:21:00.000 Thank you, Evan! I hope we can see each other in person next year.
00:21:12.000 Thank you for your time, and have a wonderful rest of your year.
Edit
Explore all talks recorded at RubyConf 2021
+92