 Okay. So, hi. Hi. How are you? Great. You have fun? Fun in the LA this year? Yeah, great venue. Yeah. You've been traveling a lot. You might as well be Ghostbusters. Yeah. Oh, I was going to mention that. I don't know if you've all had heard, but the crystal ballroom upstairs, that particular room, if that looked familiar to you, that is the room where they catch slimer in. And they destroy the chandelier and it falls to the floor and they get a giant bill and they walk out covered in goo. So, go home, watch, go watch Ghostbusters on. It's probably not on Netflix anymore. I don't know. Somewhere. And watch for that scene because that's that ballroom. So, yeah. Anyway. Yeah. Thank you for reminding me. So, let's see. I have a couple of questions. Let's see. What should I do first? So, I think around this time last year, you had talked a lot about Ruby 3x3. Yeah. How do you feel that's going, that effort, thus far? I first mentioned the 3x3 in two years ago, the Recall 2016. And at that time, I have no idea to implement that. I just said that. Sure. That's fine. Yeah. But ambitious. Yeah, ambitious goal, indeed. But it is, I had no plan or no particular technology to improve the 3x3. But saying that and encouraged the community. So, the Vlad, Vladimiro Markov, came to the technology named MZ, which is three to four times faster in some cases. But it requires the VM replacement, which is kind of heavy. And it's pretty difficult to make it compatible to the current implementation. So, the Takashi Kokubun, where he is now, and he's there and had a presentation this year. He used the MZ technology and framework to implement the JIT compiler for Yelp write code. Now, for the OptiCarrot, which is the NES emulator, the CPU bound benchmark, it is 2.5 times faster than it would be 2.0. So, it's kind of close to ARB3. Do you feel like OptiCarrot is the thing that you're using as the benchmark? Actually, we are using the Rails benchmark as well. But it is difficult to improve the performance of the Ioban applications because the time is mostly consumed in the operating system. The universal machine is just waiting for the IO. In that sense, we have the decent improvement for the CPU bound applications like OptiCarrot. But I hope we have some improvement for the Rails application. Okay. And it's been a couple of years now. Do you have any rough feelings about when, I mean, do you, two and a half times is a big improvement over two years? So, I'd say that's been a big success. So, kudos to everybody who's been working on that. Do you feel like, what does your gut say? Is it another two years before Ruby 3? We're not going to hold you to it. It's not on camera, tape, broadcasts of the world or anything like that. Don't tell anybody. It's just you and me. Okay. The famous, the Kennedy speech was in this decade or something like that. Well, that's good. That's two years. So, not two years though. Because in this decade, it has to be released before 2020. That means the next year. Okay. Sure. At the beginning, I thought it was going to be released on December 2020 at 19, I mean. But it turns out it is too short for us right now. That's basically a year away. Under the current plan, it's going to be released on the December 2020. Okay. You heard it here first, folks. 10, 20, 2020. It's good. It's good numerology. It's a good one. I like that one. That's great. It's good to hear. I mean, I've been having worked on those kinds of things before. It's been great seeing how the progress and how it's been going and everything. So, I'm excited. How are we doing? Any questions yet? Anybody questions? Yeah, come on in the aisles. I wasn't joking about lining up. All right. Hi, I'm Yuri. I work at Square. Before that, I was working on Twitter. I've been working with Ruby for more than 70 years. And it was very interesting to see your talk when you was talking about the popularity of Ruby when we were on the peak and then we're currently either within the deep or maybe on the plateau in the middle part. And so here's my question. One of the concerns that I hear from lots of people who decide which language to use to adopt for like new projects or whatever is like one of the concerns that they have for Ruby is that there are not that many people work on the core team technically. And then, for example, Python, they're way better sponsored and they have more people working on it. So there might be some concerns regarding the future. And I know that Oracle Labs, for example, currently working on Truffle Ruby. And I was wondering if there are any plans to maybe cooperate the MRI, which is still the main implementation of the Ruby, main lab adopted. Is there any plans to do any interaction and cooperation between the teams for maybe Truffle Ruby from Oracle Labs or maybe some other companies who have like full time staff teams and MRI or team in order to like for better God, for common God? You know, I care a little about the popularity so that maybe in the future, JR Ruby or Truffle Ruby will be the mainstream so that most people use those, might use those implementation in the future. But actually, I don't care, you know, as long as they are compatible. So that the point is, so that me, the longest designer, need some kind of the canonical implementation that I can play with. So which is the CRuby, because I have the longest experience of the CRuby, that it is quite difficult for me to work an experiment on top of the JRuby or Truffle Ruby. And so that that's it, so that new design, new language feature, new library, should come to the CRuby first. But the people in the community might use the different implementation for their application, but that's okay. I guess that let me follow up question. You know, if a company came to you and said, we want to hire four people and we'd like them to work on CRuby and be on the CRuby team, you wouldn't say no. I wouldn't say. You wouldn't say no. But I think maybe the question is, has that happened? And like, how do I phrase this question? Yeah, it did. I mean, it did. Okay. I mean, Heroku basically did that. Yeah, for example, a few years ago, so that only me was hired, worked full-time, paid full-time. But Heroku came in and hired three of us. And then we are working for Ruby for full-time. Then the Cookpad came in, and they hired two guys, including Koichi from Peroku, actually. And then we have several other companies who money for, yeah, money for the speed, which is the all-day Japanese company. And who has no gifts? I remember, I'm sorry. Codefolio. Codefolio has no gifts in charge of the performance benchmark. And then that kind of thing happens all the time. And then the other companies allow their employee to work on Ruby in their business hours. Not full-time, though, but they're allowing to work with improving the language. It is quite valuable for us. We often, yeah. And you don't have to be Japanese to work on. Hi. My question is, I'm curious about what made the next one, two, three versions of Ruby, what are you most excited about for future-wise? We know we got some improvements to garbage collecting, we got the JIT, and we got concurrency coming up. But outside of those, what are you most excited about in the next year or two? And Ruby 2x? Maybe easier question. What things do you have in branches on your laptop that you haven't committed yet? Weird things. I can't wait to show people this. Yes, that question. I have 2.5, and then 2.6 compiled, but not installed. But what about weird features? Have you ever, like, interesting methods or interesting, like... Well, I have a bunch of experiments on the patches on my laptop, for example, having... What? Yeah. A few years ago, I modified to Ruby to modify the scoping rule, which is the... In Ruby, the local variables, the scope of the local variables is limited to the most internal block or method or class. But I wanted to hoist them if you referenced after the block. But I implemented that, and I concluded it caused confusion, so I just gave up. Yeah, I had those kind of silly ideas a lot, and the experiment I gave up most of them. I have one question before you go back to the audience, since I'm sitting here. Have you thought... One thing that we've seen in the last few years is other languages adopt formatters, like style formatters. There has been discussion at Ruby Cop this year a lot about linters and Ruby Cop and Justin Sorrel Standard and all that kind of stuff. Have you given any thought to having a Ruby formatter, a more standard program that would format Ruby code in a more standard way, such that the community said, okay, this is the way? Yeah. My big plan... Until Ruby 3, we were focusing on working on improving the language. But after that, I have some kind of idea to work more on tools, like the formatters and linters, or maybe like things, linters, or maybe the code analysis tool, or maybe the language server protocol things. That's kind of... Probably we should work on those kind of tools. Okay. So you think that they have value, it's just you personally aren't putting much energy in and doing yet. Yeah, tooling. Okay. Yeah, let's go over here. In previous years, you've mentioned that you might consider gradual typing for Ruby 3. Are you currently thinking that a gym might, like Steep, might actually make it into Ruby 3? Yeah. Last year we had a long discussion in our matriarch room, and then we are working on some kind of that type analysis tool, like... And then the endosum from Cookbot is working on the abstract interpretation, the type analysis using the abstract interpretation of the program. And then the team from Stripe is working on the static type checking tool named Solved. Everyone has its pros and cons. We are going to combine them to make the one great type analysis tool for the better gradual typing. Yeah, some kind of the static type. Yeah, do you think that it will have... Do you think it will be more tool-based? So it will be around from the outside? Or will there be like annotations that you do in the... We are not... Actually, I hate annotations in any sense. I know you do. Yeah. And then we are not going to add the type annotation like PHP or Python 3 does. And then I try to avoid the type annotation using comments as well. But it is my homework from the meeting yesterday. We had at least three experimental implementations of the static typing checking for Ruby language. Those languages have... Each implementation has some kind of a notation to the program. But I hate that. So that it was my homework to avoid those things in the actual program. Just because adding type annotation changes the nature of the language. It is pretty convenient if we can check more. We find more bugs. But I don't want to change the nature of the language. It is kind of contradicting. But yeah, we have to address something. Sure. Yeah. I mean, that's really interesting to hear. I think that it seems like the trend in languages, like dynamic languages is to add some kind of annotations. Yeah. Type script for JavaScript. And then the typed closure. And then they start to get crazy. And then like abstract data types and they really go down the type wagon. Yeah. Type wagon? Sure. Sure. The type wagon. Actually, I don't hate the static type programming languages in general. I mean, you write a lot of C. Yeah. I grew out of C, which is the weakly typed... Typed. Typed. Programming language. And then, yeah, I value the function of programming, like a hot scan or a caramel. But there is plenty of room for those languages in the world. But yeah, my language has different laws. Yeah. I had down as one of my questions, which was a good time to ask it, which is, are there any... Other than C and Ruby, people always are interested to hear if you've been playing and dabbling with any other languages as of late. Anything else you've been writing? I recently surveyed about the Elixir, which is kind of close to Ruby community. Yeah. And then say, what else? And then Rust and Go. Yeah. Yeah. Rust and Go. Cool. Yeah. I think over here. Yep. Hi, Matt. And I want to ask a question about the changes which you introduced in MRI in recent years or something like that. What did I... I think you did a commit to change the code, not version number, in recent years. Yeah. I think that is an interesting thing, so I want to hear about it. Well, in recent years, most of the C Ruby development is done by the others, the novice genius, so that I don't have to... Patch monster. Yeah, patch monster. And then so that, yeah, last four, five years, the only commits I made is updating the version. That one line in the head file? Yeah, one line in the head file. Okay. 2.5 is released. We are now start 2.6 development or something like that. But this year, I committed another patch which implements the kernel then. Okay. I don't know about this. Which is... Have you heard about the yield self? Oh, no. Which yield self? Okay. Oh, yeah. Yeah. Oh, right. Okay. Got you. It's kind of like a top method. Okay. Yeah. It yields self, then you can process them, and then the block returns the last value of the block. Oh, I got you. Yeah. Yeah. You can process these things in the method chain way. Yeah. Yeah. For example, in JavaScript, so that they can chain them by using promises. But in Ruby, we don't have to use promises, but we can do the method chaining using them, which I think is quite expressive. Yeah. Yeah. On that, I had down... Have you been working on M-Ruby much lately? Yeah. As a programmer, yeah. Yeah. And have you... I think we'd all been interested to hear, what are some interesting places you've seen M-Ruby? M-Ruby has shown up in toasters. Am I not? Has it shown up in a toaster yet? No. Or how about a gas pump? Yeah. Well, the M-Ruby is the embeddable implementation of the Ruby, which is kind of the outcome of the implementation, like JRuby or Rubinius or something. Sure. Yeah. And it has some... The different is M-Ruby has the embeddable CAPI, which can be embedded in systems. Now, in CRuby, CAPI is to bridge to the library, so that you have to implement your software in Ruby, and you can use the... Library is implemented in this other language through the CAPI. But M-Ruby, you can call the interpreter from the C system, so that the system written in C or C++ is the master, and M-Ruby is the servant. For example, we have the nginx plugin, which embeds M-Ruby into the web server. So, instead of writing some kind of the mod-re-write regular expression... You're showing your pro roots with the mod-re-write. Instead, you can use the rewriting rule in Ruby, so that's much easier to read, easier to maintain. So, that kind of things can be done by M-Ruby. And then, in... Some company embeds M-Ruby into some kind of payment device, like a swipe... You can pay even by the bitcoin. Oh. Do you have to implement bitcoin mining in order to pay? Is that what the rubies used for? Probably, you have to enter some kind of that. QR code on your wallet or something. Anyway. That's interesting. Do you have... When it first started, I think that there were some companies that were looking to be able to embed it in switches or routers. Did that happen? Yeah, they shipped their router. It's routing rule, and the CUI menu is implemented in Ruby. Oh, cool. I forget where we were. I think over here, yeah. So, with JIT, Ruby got a lot faster, but is it as fast as it will get, or are there any fundamental hurdles? Whereas, this will always be two times slower than C because we're doing xyz. So, in the JIT, what are the other things that could be added to the JIT to make it faster? Or do you feel like that the JIT is as fast as we'll ever get the JIT? I'll show my roots here for a moment. Is the JIT doing any type feedback yet in order to try and optimize the code to be able to do stuff like hotspot, that kind of thing? It's got it. Okay. So, we've got that ahead of us. Yeah, probably. And then, you know, our JIT is pretty heavyweight because we kick spawns the GCC synchronizer as a process. It's kind of heavyweight. And then the GCC or the optimizer of the GCC and the clone is pretty much heavyweight. So, it can run faster in some cases, but it requires more time to compile and more memory to load. So, the VLAD, which originally written, originally wrote MZ, so now working on something named MEO, which is the more lightweight JIT compiler. So, maybe future Ruby has two different JIT engines, one for lightweight, one for heavyweight. Oh, okay. Oh, that makes sense. Okay. Yeah, let's go back over here. I wanted to ask, we've been hearing about guilds at this conference, but I was wondering if there were any plans to add asynchronous primitives to the core Ruby language rather than spinning up separate processes or separate threads, keeping it all in one thread? I'll ask a slightly mini precursor question. There's a patch that I saw to make fibers be able to be in the scheduler so that you could switch between fibers and have those be schedulable, not just threads. So, something similar to that or, yeah. Yeah. We have several options and we are still discussing. And then the one option is, yeah, like he said, something named auto-fiber. This is not the final name, but yeah, our code name is auto-fiber. Auto-fiber is the fiber which does switch the context on the IO blocks. It's kind of similar to Ruby 1.8. Yeah, asynchronous process in JavaScript or Node.js or something like that. This is one option. The Koichi working on something named guild, which is the isolated shared nothing model of the concurrency. He is trying to make it more lightweight than the previously planned so that we can do some kind of asynchronous communication using the lightweight guild. There are a bunch of existing async gems, celluloid and a bunch of other ones to do that kinds of things. I guess it's a question of what would those need from Ruby at the base to make them better, right? It's kind of trade-off. Having the guild, which is the totally different model of concurrency, which is more difficult to adapt, but at the same time, we can utilize the fully of the multi-course and the threads and the parallelism. It is one option. At the same time, for example, we have the IO bound task of concurrency and the CPU bound task of concurrency. In the language like JavaScript, we have the promises for IO bound and the web workers for the CPU bound. That might be an option as well. For our case, the auto-fiber for the IO bound and the guild for the CPU bound or something like that. Makes sense. We don't have any final decision yet. We're not working on it. Somebody asked my question about typing earlier, so let me ask a follow-up question. You said you hate type annotations, so that's a strong word. It seems to be coming from both an intellectual and maybe an emotional place. I was wondering if you talk from a philosophical perspective. From a philosophical perspective, why do you hate type annotations and maybe talk about your thoughts about typing in Ruby? Does it not belong at all? Is there a future where we'll have type options? Yeah. I hate type annotations for some reasons. First of all, it's not dry. The program that runs without type annotation, it should run. It's adding type annotation is kind of redundant. Sure. Yeah. According to the dry principle, we have to remove that. Remove them. This is one thing. The other thing is the adding type annotation, especially the type annotation which we see in language like TypeScript or Python 3, we tend to think about the nominal, so that we are going to give up some kind of duck typing principle from the language, and then that is kind of pity. We are doing pretty well with the duck typing in the past, so that I want to utilize the duck typing for the future as well. Then by adding type annotations, so that the type is pretty much useful, but if I allow the type annotation to the language, so that I believe everyone would add type annotations, even though we can run programs without them. That is kind of, at least change the nature or characteristic of the language, which I don't want to see that situation. The place that I always, having looked at a few of the type annotation implementations that are languages, the place that I always struggle with them, when I see them in a language that was dynamically typed and it's getting them, is when you get to containers. It's like you have an array, and in Ruby you can have an array, you can have a bunch of different things in it. Do you want to be able to express all of a sudden, I want an array of only integers, because that assumption at some level falls out in every single place and every single line in Ruby code then. I never see the annotations ever deal with how do I annotate what's inside a container, other than just adding a bunch of guards in places. Yeah. Implementation-wise, we are going to introduce some kind of the type definition file, external file, which we see for the TypeScript, like a different type. You can write that kind of the type definition, kind of similar to the ones in OCaml, so that we can add the parameterized type, or a generic type, or even that kind of what. Derived type, container. Yeah, some kind of things. If you want to write down. Sure, yeah, it makes sense. Okay, that's cool. At the same time, the abstract interpretation tools we call the type profiler, so that can generate the boilerplate of the type definition file. Gotcha. Okay, let's go over here. Keeping on the subject of types and type annotation, sorry. Okay. What are your design goals for the type system? Because coming from using TypeScript in languages like JavaScript, they're often optimized for something. In that case, it's really easy to write really simple types, but as soon as you start doing metaprogramming, the types become impossible to read, and I wouldn't want to have to try and hand write out the types for some crazy metaprogram in Ruby. So how are you guys thinking through what are your goals for the type system when it comes to more complicated types? Okay, my goal is we write Ruby program as they are now, and then we find more bugs static time, compile time, so that it doesn't have to be sound, it doesn't have to be complete, so that we find more bugs, it's okay for us. Usually we don't step into that kind of the very complex container type generics or parameter type things, so that, yeah. But by writing type definition file manually, you can get in to that field, but it's for type hackers. I'd like to experiment some with adding some features to Ruby. How would you suggest I get started with that? How should someone, if they want to add a new feature to Ruby, how should they get started? The best way for me is to submit your proposal to the bug tracker, which is red mining. Are you even at that stage, or do you want to be pre that stage? No, what's beyond that? After the bug tracker? Yeah, what's beyond that? What should I do to go further? Do people advocate for their features outside of the bug tracker, like talk on IRC? I don't think so. Just be concrete. Most of the proposals are very vague, so they don't describe their intention, their motives or anything. What if we have these things? It wouldn't be cool or something like that. You want some analysis. We want more concrete analysis or requirement or use case. If Ruby has this feature, my program would be like this, and then this would be better for anyone or something like that. Some more examples. Yeah, more examples, more use case, more motivation, more analysis. Most ideas are okay to have, but we cannot add all of the teeny bit ideas to the language, but most of them can be implemented in the active support or maybe in the gem, but not in the standard. The proposal means adding to the standard, which is to the language which gradually becoming bigger and bigger. We have to be very conservative about adding things. Sure. Let's go over here. Yeah. Hi. My question is very casual. You have money of programming language, and so what language are you interested in recently, and especially what feature are you interested in? Well, I'll ask you one similar. Yeah, Elixir and its pipeline operator. You like the pipeline operator. I was going to ask you about the pipe operator. Yeah. The pipe operator is pretty inspiring. Actually, I designed my toy programming language Extreme, which is inspired by the pipeline operator. Do you want to explain the pipe operator for your home? Yeah. In Elixir, they have the pipeline operator, which is the bar the greater than or something. Yeah. It looks like an arrow. Yeah. Elixir is not object-oriented programming language. It's a functional programming language. We have the expression pipeline and the expression, which is a function call. That is the kind of macro that put the left-hand side expression as the first argument of the next function call. So it's kind of like the method chain in Ruby. Yeah. You do dot map dot dot group dot sort dot yeah. Yeah. That kind of things. Yeah. Ruby does not mean that that's kind of the pipeline operator because we have that method chain. The appearance and the process model of the pipeline operator. It seems like we define kind of the stream of the functions and the pipeline of the functions of the data stream or something like that. That appearance is pretty much inspiring. Okay. So one of the big problems with Python going from two to three is all the backwards compatibility they broke. Are you planning on breaking backwards compatibility or to what extent are you planning to do that in Ruby 3? Yeah. Yeah. So in the past, the language designers broke the compatibility. Like we did in 1.9 and then like they did in Python 3. But at the same time, that could cause the community division. Like for 1.9 we have the community division. Some people kept using Ruby 1.8 for years, maybe five years I think. Yeah. Five to seven years. In a while. Yeah. And Python 3 was released in 15 years ago or something. Yeah. And then they still use Python 2. And then yeah, the end of life of the Python 2 is 2020, which is two years ahead. And then the people, some people still using Python 2 and declare, okay, go ahead. We will maintain Python 2 after its end of life or something like that. Whoa. That kind of community division is pretty much tragedy for the language. Because the community is pretty crucial for the open source software, open source language. And then some part of the community is kept away from the newer technology or the virtual machine improvement or something or maybe the making language better so that they kept isolated from those kind of discussions. So that is kind of petty. So I don't want that kind of situation. So the compatibility is pretty much important so that I'm not going to make that kind of big incompatibility in the Ruby 3. At the same time, there is some interesting change which could lead to the incompatibility, the breakage, for example, so that the frozen string literals, so that I have no final decision after years of consideration. But it is useful and it improved the performance a bit. But at the same time, you have to modify your applications. I'm not sure how big is the damage to the community or how big is the cost that the community users have to pay. So before making final decisions, we have to make some kind of survey. I think we got time for one more and then ice cream. Hello, Matt. These are two questions that you could either answer either or both, but they're about the organization of the Ruby core team. One is sort of revisiting a question from years past. Do you have any interest in extracting the rest of the standard library into its own sort of development and release cycle? And then also, do you have any interest or plans to moving to get off of Subversion? We'll do the easy one first. Do you want to move any more thoughts on moving off of Subversion? Okay. We are in the process of moving to get, not get, but get in general. Yeah, get in general. We are pretty close to the migration to the get. Actually, the hostage in the server. But we have the GitHub mirror of that, our GitHub repository, and synchronizing the bi-directional sync. I like asking you this question. I know the answer, but what was the first year you started using Git for development with SVN to Git, too? It was like 10 years ago, maybe? When did you start using Git for actual your own personal development? At least six years, I'm not sure. Okay. It seems like it was longer. Did you use Quilt? Do you still use Quilt? Do you still use Quilt? No, I use Git. What was your first question? I forget. Any more thoughts on breaking the standard library, like the rest of the standard library, like Net-HCP into its own gem, that kind of thing, so that it can have a different release cycle? Yeah. I'm not sure which, but we are moving toward the gemification of the standard library, so that maybe we gemify some other standard libraries as well. Yeah, in the age of 18, we had many, many standard libraries, like battery included things. Actually, I regret. Yeah, because of the, you know, some the library also retired or gone away, that they kept un-maintaining for years. So having separate gem is much better. Yeah, but at the age of 18, we don't have Ruby gems yet. Yeah, exactly. Yeah, absolutely. Yes. More questions. We're sort of over time. Quick question. Okay, go ahead. It's a long one, but it's really important. Okay, go ahead. Thank you so much. So speaking of type annotations and other features that just won't happen. Speaking of what? Type annotations and other features that just won't happen. So Ruby is a very popular language. We have more than a million people who adopted it, and there's an entire industry behind it, lots of companies who bought into Ruby and like love to use it. And you are the leader, and also Ruby still remains one of the top 10 languages in GitHub by either number of contributions or number of repositories. And so my question is, as an individual, and by definition, like humans all, like we have a limited scope of interest, right? Aren't you afraid of like, you have a very strong veto power for the features, and aren't you afraid of personal biases? And the second question is, does Ruby Core team do, what does Ruby Core team do in order to make sure that the interest of the industry and the community, the very big Ruby community of people who trust you, are being taken into account and represented somehow? Okay. Regarding bias, so that I'm biased, the Ruby is, every corner of the design is decided by me, so that means the Ruby reflects my bias, so that it's different from Python, it's different from JavaScript, it's mostly because of my bias in some way. So I admit that, and I don't afraid that. So Ruby reflects my preference, and then I try to keep that kind of the following preference or bias forever, if it's possible. And, I guess that the other thing, that means that, I am not the expert for everything, so that maybe the people in the community can influence me for the future path of Ruby language, but still I need to make decision before changing the language. And you still feel like, well, obviously, but things still come to you, you're still the arbiter through the top of that pyramid. Any company or any community member could ask me to change the language, and if I agree with that, Ruby will be changed. Okay. Okay. All right. Well, that's all we've got. We've got some more treats upstairs, I know you haven't had one in, like, half an hour. So thanks, everybody.