00:00:01.599
All right, hi everybody! I'm Evan Phoenix, and I'm here with our beloved Matz. How are you today, Matz?
00:00:12.400
I'm great, thank you! It's been chilly here.
00:00:17.760
Yes, I was going to ask about the weather. Normally, wherever we would be during RubyConf in the U.S. it would be cold. It seems it's cold at your house too.
00:00:26.160
Yes, this time of year tends to be chilly.
00:00:31.679
How have you been over the last few months with the coronavirus? Is everything okay?
00:00:38.000
Oh, yes! We are doing well. Many events and conferences have gone online, so I miss communicating with users in person.
00:00:44.000
On the other hand, I'm pretty happy because I actually hate flying.
00:00:50.719
I remember you mentioned that before. We're always very thankful you come, but on the other hand, you do get to spend all this extra time at home, which is sort of a silver lining.
00:01:08.640
Yes, we're recording this before the conference, obviously. Thank you for sending me your keynote. I got to watch it before we did this so I could talk to you about what was in the keynote, which is great.
00:01:27.520
I thought we could jump into a couple of topics from the keynote.
00:01:35.040
Ruby 3 sounds like it's going well.
00:01:46.240
Yes, but we still have work to do on the release. There are still some features we are working on.
00:01:53.119
One question I noted at the end of your talk was about how you and the core team are evolving and adding features through more experimental features, which start off as experimental and stabilize over a few releases.
00:02:07.200
Instead of trying to make a big feature production-ready from the beginning, is that something you have discussed with the team?
00:02:31.680
Yes, it makes sense. In the early days of Ruby, I could design everything from the beginning, and that was okay since all my decisions were mine then. But as Ruby matured, many fundamental features were implemented.
00:02:47.120
Now, we sometimes have controversial or complicated features that might not be designed perfectly from the start. We need to do experiments and gather user feedback before finalizing their designs.
00:03:13.440
When our community was smaller, we could easily throw away features if they were mistakes, but now with millions of users and so many existing Ruby programs, it's a different situation.
00:03:35.120
That's why we improved our process of introducing new features, allowing for experimental ones and more gradual stabilization.
00:04:43.199
It's very useful, as I've noticed that getting users to try beta software is always challenging. They often prefer to try the final product rather than experimental features.
00:05:00.639
Even when we release previews, very few people try them. So, somehow we have to create scenarios encouraging users to give experimental features a chance.
00:05:53.759
I think, for instance, the Ruby VM and bytecode features were initially experimental but have proven to work well.
00:06:09.720
Now I’d like to delve into performance. It seems you and the team want to address Ruby performance through several approaches.
00:06:39.360
I was glad to hear you say you want to improve on microbenchmarks because that is how users test things.
00:06:49.920
While language designers usually focus on broader performance issues, addressing microbenchmarks is necessary since decisions are made based on them.
00:07:04.960
I find it interesting that there is discussion of the new async features and how they interact with C extensions. Has there been much discussion about how Ruby fibers work with C extensions?
00:07:57.040
The Ruby C extensions and fibers can work well together thanks to Sam Williams, who wrote some assembly code to maintain independent stacks for each fiber. As a result, fiber performance is generally adequate, and you don’t have to worry about this mixing.
00:08:25.599
That’s excellent to hear! I know that Koichi is giving a talk about Raptor, so if we have time, we can discuss that.
00:09:01.440
Another thing people may be curious about after watching your keynote is Ruby’s evolution regarding functional programming. Every year, someone asks if you will add functional features to Ruby.
00:09:29.640
This year, I think those asking will be pleasantly surprised with some interesting functional features, like named parameters.
00:09:48.480
Is there any experimentation with these new features, or have you played with writing some example programs?
00:10:07.440
Yes, I’m a programming language geek, so I enjoy exploring various languages and gathering inspiration from them. I want to improve Ruby while ensuring compatibility.
00:10:31.200
My goal is to reduce the programming burden and increase the joy of programming.
00:10:57.440
While I’m not trying to make Ruby a purely functional language, I look for ideas and syntax from functional programming languages like Haskell, Scala, and Elixir.
00:11:11.760
It’s interesting you mention the pipe operator, as it was controversial and ultimately removed. The difference between the Ruby design and expectations from Elixir users proved problematic.
00:11:44.319
Language design relies heavily on common understanding and background. Sometimes, even small differences from what people expect can lead to abandonment of ideas. I might revisit certain ideas in the future, but not at this time.
00:12:17.200
It's refreshing to see experimentation where features are added and sometimes removed based on their effectiveness. For example, we introduced one-line pattern matching using the keyword ‘in,’ but later abandoned that in favor of a different syntax.
00:12:58.560
The multi-line pattern matching will use ‘case,’ while one-line uses ‘in.’ You can mix them in the same case too.
00:13:28.320
I think destructuring has always been a fascinating concept in Ruby, and I'm glad to hear pattern matching can also destructure from hashes or objects.
00:14:10.000
Pattern matching will allow users to extract elements into locals easily, which is a lot of fun. Objects will need to implement `deconstruct` methods to participate in pattern matching.
00:14:43.360
The flexibility to pass objects that can destructure themselves makes Ruby's dynamic nature even stronger. I'm curious about static types, which we've discussed at many RubyConf events.
00:15:32.080
How many years do you think it’s been that you’ve considered adding static types to Ruby?
00:15:56.960
I've been thinking about it for at least ten years. Even before Ruby was officially designed, I had ideas for static typing. However, the concept felt too advanced for that time.
00:16:45.760
Recently, I’ve been wondering how flexible types will work within Ruby. I haven’t used the RBS type signatures yet, but do they support interface types?”
00:17:17.920
Currently, the type profiler cannot extract interfaces, parameterized types, or generics. However, you can write down the interfaces and parameterized types by hand in signatures, keeping Ruby's flexibility intact.
00:18:06.400
My main concern has been if I introduce strict typing, the community might shift towards a static type approach which would change Ruby's inherently flexible atmosphere.
00:18:48.560
The goal is to maintain that dynamic flexibility while allowing for some static type checking for those who prefer it, which aligns with the flexibility Ruby has always offered.
00:20:11.440
The aim is to eventually have signatures distributed with gems, allowing for better type checking without sacrificing Ruby's dynamic nature.
00:20:49.280
You mentioned some other recent tools related to static typing that have emerged. How did you decide which tools to adopt?”
00:21:29.720
I recognize there's a need for compatibility among tools, which is why I encourage existing tools to adopt policies that complement Ruby’s ecosystem.
00:22:27.040
I'd like to see ongoing collaboration with tool developers to enrich the ecosystem further.
00:22:52.240
Before we wrap up, I wanted to make sure we discuss the potential for macros in Ruby.
00:23:17.600
Your keynote mentioned macros, and I understand they are planned, but will they require new syntax?
00:23:38.480
Yes, implementing macros would require some syntax changes. However, the details are still in the brainstorming stages.
00:24:16.720
I appreciate you sharing this information. I think attendees will be excited about the potential changes.
00:24:38.720
Thank you for having me. I look forward to seeing you in person at the next conference!
00:24:44.480
I also hope to see you next year. It’s always great to reconnect with you. Thank you!
00:25:19.679
See you later!
