Ruby Video
Metaprogramming
Q&A with Matz
Yukihiro "Matz" Matsumoto
@matz
#ruby
#type-checking
#metaprogramming
#garbage-collection
#ruby-community
#concurrency
#ruby-3
Summarized using AI

Q&A with Matz

by Yukihiro "Matz" Matsumoto

In the Q&A session at RubyConf 2016, well-known Ruby creator Yukihiro "Matz" Matsumoto discusses various aspects of Ruby's development and functionality with an audience. The session covers topics such as type checking, the introduction of MRuby, upcoming improvements in Ruby 2.4, and the overall future of the Ruby programming language.

Key Points Discussed:

- Type Inference and Checking:

- Matz elaborates on how type checking in Ruby will operate at compile time, acknowledging that dynamic aspects of the language, such as eval or define_method, are difficult to validate.

- He discusses the prototype of a type checker that aims to deliver warnings about potential type errors.

- The type checker will not only check for compile time errors but will look into libraries and methods used in programs to some extent.

  • MRuby Development:

    • Ms. Matsumoto explains that MRuby is built on a modified codebase from Ruby 1.9, and stresses that it is not a direct fork.
    • Improvements like generational garbage collection are built into MRuby from the outset, ensuring a cleaner integration of features and optimizations compared to CRuby.

  • Ruby's Performance Enhancements:

    • Matz provides an update on the Ruby 3x3 performance plan initiated last year, promoting faster hashes and rational numbers in Ruby 2.4, aiming to achieve three times the performance enhancement in Ruby 3.
    • He also stresses the importance of maintaining backward compatibility while discussing which features might be considered for removal.

  • Community Engagement and Contributions:

    • Matz reflects on the journey of contributions in Ruby's evolution and encourages new contributors to engage with the community actively.
    • He acknowledges the successful initiative of improving documentation and highlights the need for sustained efforts in this direction.

  • Future Vision for Ruby:

    • Matz expresses his ongoing passion for Ruby's development, mentioning interests in retaining the language’s adaptability in the changing tech landscape over the next 5 to 10 years.
    • He is open to improvements in design aspects such as private and protected methods as well as inspiration drawn from contemporary languages like Elixir.

In conclusion, the Q&A reveals Matz’s dedication to Ruby’s growth and community involvement while emphasizing the balance between innovation and preserving familiar experiences for developers using the language.

00:00:15.679 How's everything going? Great, good. Do you have a good conference so far? Oh, good, tired. I'm a little tired, I won't lie.
00:00:22.599 It’s been a good conference so far, yes? Yeah, good. I missed several sessions, so... yeah, I’m...
00:00:35.879 I’m sorry. No, it's fine. Not at all. So, we'll jump right into the questions. There are some questions about your presentation from the first day.
00:01:08.400 One of the questions was about type inference. People were interested if you could talk a little bit more about that. Maybe discuss how dynamic methods and metaprogramming fit in with that.
00:01:14.640 And sort of when would the type checking happen? Would the program ever type check itself, or would it just be a database? The type checking will be done at compile time, so we cannot check things that happen dynamically, like `eval` or `define_method`. In those cases, we just ignore them.
00:01:51.360 At the beginning, I'll create something like a prototype of the independent type checker. You can consider these type errors as warnings for your program. They might be false positives due to missing methods or dynamic evaluations. But the type checker can warn you that we cannot determine those kinds of errors at compile time.
00:02:22.560 Compile time is such a vague term with Ruby, right? It's not like C where we know there's a specific time for compiling and another for running. In Ruby, compile time is this strange time while we're running the code that sets up the other code.
00:02:37.120 So do you think that the stuff that runs at compile time will be able to see through `require` statements?
00:02:49.720 Yes, it would be able to see into gems, for instance. But the reference is quite limited. The compile time type checker requires looking for the library source code and reading into it.
00:03:20.080 Do you think of the type checker as part of the normal loader, or is it a separate thing looking at the code? It's a separate thing, at the beginning.
00:03:37.120 Okay, cool. If this is too vague, feel free to ask more questions. We have some audience questions already.
00:03:57.199 Is this topic related, or is it something different entirely? It's on `gills`. That's fine. Well, go ahead and ask your question.
00:04:09.239 Can they all be this close? This is not easy. Yeah, I didn’t want to make you run. I could ask a similar question regarding type checking. In your presentation, you mentioned you were looking at this but could throw it out, similar to what you did last year.
00:04:41.320 What other methodologies have you considered that are number two or three on the list? Or are there no contenders for number two or three at this point?
00:05:16.640 You mean for type checking? Like what crazy idea do you have when you walk the dog? That’s when I have all my crazy ideas, usually in the shower.
00:05:54.639 For type checking, I don't have any crazy ideas right now. The usual compile time information is pretty limited for Ruby programs because we generally have very little data available.
00:06:40.120 We can infer something from assignments or literals, but otherwise, we don't have information regarding argument types, return value types, or enough data.
00:07:09.800 To complement that, we could add some kind of database to gather runtime information or pull method set information from a running program, checking for inconsistencies.
00:07:44.480 Did you look at other attempts that people have made?
00:08:00.760 In your presentation, you said that past research or attempts, like Diamondback for example, tended to force too many type annotations. Is that your main takeaway from those past attempts?
00:08:42.560 I did a bit of survey of the previous US research, and the two takeaways are: gathering compile time information from non-typed, non-annotation code isn't really good enough.
00:09:21.520 I saw that the previous attempts, including Diamondback, ultimately failed or gave up. We clearly need something additional, like a gathering of runtime type information.
00:09:50.860 This is my attempt to provide more detailed programming structure information.
00:10:23.320 How do you expect people to interact with type checking? Would the check occur while running code or before checking it into Git?
00:10:54.440 Fundamentally, I want the compiler or type checker to read our intentions from the code. You don’t have to interact at all. At least in the short term, we can read the documentation, which often includes return and argument value types.
00:11:30.660 We can extract that information, and in the future, we can reverse this process to enhance documentation.
00:11:59.260 Now, we can open the floor for more questions. Is it a good time to change topics? Absolutely.
00:12:25.160 So, Mats, I know that MRuby is not a fork but a brand new codebase off of 1.9, correct? It wasn’t forked from 1.9?
00:12:47.680 Right. I utilized some description from 1.9’s source code, but modified it a lot. So, I don’t consider MRuby to be a fork.
00:13:16.320 So what would it take to integrate performance and GC improvements from the current Ruby into MRuby?
00:13:53.839 The biggest improvement made after 1.9 was having a generational and incremental garbage collector from day one. We don’t have to revisit that improvement in MRuby.
00:14:45.200 What about other improvements, like making hashes faster? How do we transfer Ruby code into MRuby?
00:15:08.600 It's certainly possible, but we have different criteria for including things in MRuby. For example, the MRuby design should minimize memory consumption, so improvements that consume more memory may not be integrated.
00:15:42.520 Open addressing for hashes, however, is one idea that should be considered for MRuby.
00:16:21.240 You can’t pick a favorite between CRuby and MRuby, but do you find that you've made decisions in MRuby that you like more than CRuby?
00:16:30.520 Yes, I have two aspects in MRuby that are better than in CRuby. One is that MRuby drops the legacy cryptic variables like dollar-variables.
00:17:07.000 And the second improvement is MRuby has an embeddable API that makes it better to embed a Ruby VM into your application.
00:17:44.400 We have people raising their hands in the middle of the seats. If we're lining up, let’s start.
00:18:17.680 Hello! Mats, can you give an update on your Ruby 3x3 plan announced last year? What progress has been made?
00:18:43.760 For example, the upcoming Ruby 2.4 will feature faster hashes and faster rational numbers, including various performance improvements.
00:19:10.400 Ruby 2.4 will also be slightly faster than Ruby 2.3. So we’re adding those improvements until we achieve the targeted three times speed performance.
00:19:49.320 Would releases serve as a status report for Ruby 3? As new releases come out, we should see improvements in performance for our benchmarks, correct?
00:20:22.760 Yes, we’re also preparing a web application benchmark alongside the previous benchmarks for Ruby’s performance.
00:20:48.080 While we can run the benchmarks repeatedly, no one really uses them during real application development.
00:21:11.560 You might consider an interesting question: you are very intent on not breaking backwards compatibility, which is commendable.
00:21:35.140 If there were no drawbacks, what are your top three Ruby features you would remove?
00:21:57.200 I'd remove the following: the inherited variables from Perl, threads, and perhaps turn `eval` into a keyword.
00:22:16.240 So some of my friends suggested that there should be a one-word answer to this question.
00:22:58.960 Regarding the new concurrency model, why didn't you adopt actors?
00:23:31.280 We aimed to keep compatibility without breaking prior versions. We need to maintain a consistent thread model.
00:23:58.920 Ask him later. Personally, I would have liked actors to be used, but that wasn’t feasible.
00:24:32.880 Contributing to Ruby as a new contributor seems a bit tricky, with talk of friction in the process.
00:24:59.520 Is the core team considering ways to ease the contribution process for new contributors?
00:25:27.680 Indeed, Ruby has a long history of development with multiple constraints. We've made improvements, such as having GitHub repositories.
00:25:51.960 While I'm not sure what else we can improve, if you have ideas, just submit them to Ruby's issue tracker.
00:26:28.240 Are there particular areas of Ruby that need attention from contributors?
00:26:54.840 Sometimes we have developer meetings, and we identify areas where we can cooperate and contribute.
00:27:20.320 At one point, there was a big push to improve documentation. Do you think that initiative was successful?
00:27:40.680 Yes, that push was quite successful. If you encounter undocumented aspects or need clarification, please submit a pull request.
00:28:04.320 Ruby technically supports tail call optimization but is difficult to access. Will you make it more straightforward?
00:28:38.760 We ignored all requests for tail call optimization because we've implemented it but kept it disabled by default.
00:29:08.680 We have few requests regarding it, and most don't require it.
00:29:33.680 Do you prefer self-tail recursion or mutual tail recursion?
00:30:06.680 We're focused on the stack traces as this is important for debugging, and we need to keep all function calls.
00:30:34.480 It’s still up for discussion how to introduce a new syntax or feature for tail calls.
00:30:57.760 Are you still passionate about maintaining Ruby, and what keeps your interest alive?
00:31:22.440 I still enjoy maintaining Ruby. I don't code myself consistently for CRuby, but I enjoy designing and making decisions for the language.
00:31:43.160 Back when I was an early user of Ruby, I was afraid of the lack of documentation.
00:32:07.360 When I first started, I was concerned at the absence of any form of documentation, even on code comments.
00:32:29.760 I once circulated Ruby in a limited format, and even then, there was a make file.
00:32:55.920 However, it wasn't comprehensively documented, and users were basically on their own.
00:33:15.240 In the context of Brazilian Ruby developers, there's movement to extract parts of the standard library into their own repositories for ease of maintenance.
00:33:51.720 To achieve a proper RubyGems ecosystem, I decided to bundle everything into one distribution, enabling users to install Ruby and access the necessary libraries for web applications.
00:34:28.160 As time progressed, some maintainers disappeared, which resulted in unmaintained libraries in the standard distribution.
00:35:05.560 To resolve this, we've gradually moved certain libraries from the standard distribution to RubyGems.
00:35:35.240 For instance, we've recently placed `tk` outside the standard distribution, allowing for independent updates.
00:36:02.200 We have a list of maintainers and could use more volunteers for unmaintained libraries. If anyone is interested, please raise your hand.
00:36:27.240 As a language designer, Ruby 2 has provided a smooth upgrade path for many users.
00:37:02.200 Are there any regrets from Ruby 2's design that you wish to address in Ruby 3?
00:37:36.680 I’d say that I try to maintain compatibility for no reason, and if there's no compelling reason to break it, I'd like to avoid unnecessary changes.
00:38:06.560 In terms of performance unification, we've noticed backwards incompatibilities in Ruby 2 and ongoing tweaks to fix them.
00:38:43.040 If we can effectively reduce the nitty-gritty of compatibility issues, we should consider targeting the features that minimize user frustration.
00:39:09.560 During discussions about a potential code of conduct for Ruby, you mentioned a desire not to permanently ban anyone from the community. Can you explain why?
00:39:50.880 The Ruby community is expansive, and no one truly initiates or gains membership, so I cannot see the justification behind banning someone from such a broad community.
00:40:30.680 However, if we have a stricter definition, like attendees of conferences, it's possible to manage those scenarios.
00:41:05.000 Is it conceivable that we could ban people from the core team if they participated unfavorably?
00:41:51.000 Indeed, that discussion revolves around establishing conduct within the Ruby core team, contrasting the broader Ruby community.
00:42:30.480 For returning questions, it's essential to reflect on where Ruby sees itself in the next 5 to 10 years.
00:42:58.720 The Ruby language will keep improving and adapt to the shifting technological landscape.
00:43:03.999 With advancements in technology, like accommodating multicore processors, Ruby aims to remain a powerful, adaptable programming language.
00:43:45.438 Mats, I’ve always been confused about the design of private and protected methods. There have been mention of regrets about naming. Will there be changes to clarify this?
00:44:18.260 I confess regret around private vs protected methods. However, I believe fixing naming without breaking compatibility may be challenging.
00:45:15.220 To conclude our session, we must consider how many people effectively utilize protected methods.
00:45:38.200 If you aren’t using them, there could be room for refining or possibly transitioning to different paradigms.
00:46:09.640 Have you drawn inspiration from languages like Elixir, Closure, or Scala while working on Ruby’s design?
00:46:42.280 Yes, I'm very interested in various programming languages, including Elixir for concurrency and Closure for functional features.
00:47:06.680 Perl, which influenced Ruby originally, has released Perl 6 recently. Anything noteworthy you've learned from Perl 6?
00:47:59.280 I'm quite impressed with how Ruby has influenced Perl 6 and their design features, such as internal DSLs that introduce new syntax.
00:48:30.640 As we approach the end of our time, I want to thank you, Matz, for your insights and our engaged audience for the questions.
00:49:03.640 Our RubyConf has been a great experience, and we appreciate everyone's participation. Thank you for joining us!
Edit
Explore all talks recorded at RubyConf 2016
+78