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.
