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.
