Ruby Conference 2016 - Matz Q&A
Matsumoto, Yukihiro 'Matz'
Part of our annual tradition, Matz answers questions from Evan as well as the audience
 How's everything going? Great. Good. How's everything going? Oh good! Tired? I'm a little tired. I won't lie. Good conference so far? Yes. I missed several ones. I'm sorry. That was fine. No, not at all. So we'll jump right in at the questions. So people have some questions about your presentation from the first day. One of the questions was when you talk about doing the type inference, people were interested if you could talk a little bit more about that and maybe talk about how do dynamic methods and metaprogramming fit in with that. So when would the type checking happen or would the program ever type check itself? Would it just be a database? The database stuff and the type checking stuff is done in compile time so that we cannot check the things that happen dynamically like eval and defined method things. So in that case, we just ignore them. At the beginning, I'm going to create some kind of prototype of the independent type checker like a lean things so you can consider these type errors as a warning to your program. So that might be false positive just because of the method missing stuff or the eval stuff. And at least the type checker can warn you that we cannot detect that kind of error in compile time information. So I mean compile time is such a vague term with Ruby. Right? Because it's not like C where we know that there's this time where we're compiling and there's this time where we're running. Compile time is sort of this strange time while we're running the code that sets up the other code. So like do you think that will the stuff that runs at compile time be able to see through require statements? Yes. So the require... Would it be able to see into gems for instance, that kind of thing? Yeah. The reference is pretty limited but the compile time type checker sees require that look for the library source code. So then include read them, read the source code into the software. Do you think of the type checker as part of the normal loader or is it a separate thing that's looking at the code? A separate thing at the beginning. Okay. Okay. Cool. Again, if this is too vague, you can ask a question. We've got people. Oh, we have people. We have questions already. Is it related to this topic or is it another topic entirely? It's on GILS. It's on GILS. That's fine. All right. Go ahead and ask your question and then we'll let math turn you down. 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 with regards to type checking. So with your type checking methodology, I believe you had said during your talk that you were looking at this but you could throw it out just like you did from last year. What other methodologies have you considered that are number two or say number three on the list or are there no number two or number three at this point? You mean for type checking? For type checking. What crazy idea do you have when you go walk the dog? That's when I have all my crazy ideas at the shower. So for type checking, I have no that kind of crazy idea though. The usual compile time information is very limited at least for Ruby programs because we have nothing. So we can infer something by say assignments or from the literals. You can't know string literal is a literal but otherwise we have no information, no argument types, no return variable types. We don't have enough information to complement that. So we add some kind of database things like gathering one time information or maybe so putting out the method set information out of the running program. So then check this kind of the inconsistency out of those information. Did you when you were thinking and working about this, did you look at the other attempts that people have made for it? I know that a conversation I have had over the last couple of days, someone brought up was do you remember the old diamond back? Yeah, yeah, yeah, soft diamond. I mean do you feel like those, I remember in your presentation you said that you felt like they forced people to type annotations too much and is that your main takeaway from a lot of those other attempts is that they're always forcing people to try and type their type? Yeah, I did a little survey about the previous research or something. And the two things I can tell is the gathering component information out of the non-typed no-type annotation software is not really good enough. So the previous attempt including diamond backs and say type to scheme, I remember that word. Yeah, with all failed and gave up. Yeah, give up, I mean. But so the one thing I want to assure is we need something in addition. These kind of runtime type information gathering by database things is my attempt to add info to the programming structure information. So how would you think we can, we'll change the topic here in a second. How do you think people would interact with it? Would it, when I run code, would it complain at me or would I have to decide, oh, you know what, I'll do my type checking before I check it in to get. How would you want people to interact with the type checking? The fundamentally, so I want the compiler or type checker to read our intention from the code so that you don't have to make some kind of interaction. But at the same time, for at least for the short term, so we can try to read our documents like a yard things, then we can add the information back and forth to, with yard documentation. Like we often, we write the yard documentation with the return value and the argument value. So we can take information from that in the short term. And maybe in the future, we can, in reverse, we can put that kind of those information into the yard documentation. Okay. We have questions. We're swapping. Yes. Okay. This question is on Mrooby. Is now a good time to change the topic. That's fine. Yeah, absolutely. Okay. So Matt, I know that Mrooby is not a fork. I learned it just today of 1.9, it is a brand new code base, correct? Of 1.9? Mrooby is a brand new code base. He wasn't forked from 1.9. No. No. I took the description from 1.9 source code base, but I modified a lot. So I don't consider Mrooby to be the fork of 1.9. Okay. So my question is, what would it take to get some of these improvements, performance and GC improvements from the current Ruby into Mrooby? Or is that not even on the plan? The biggest improvement on top of the 1.9, after the 1.9, was the making it generational and making it incremental. And the Mrooby garbage collector is generational and incremental from day one. So we don't have to put in that kind of improvement on Mrooby GC. But what about some other improvements, like making hash faster? In general, how do I get the code that is in Ruby into Mrooby? Yeah, it's quite possible. But for Mrooby, we have somewhat different criteria about including that. For example, Mrooby should reduce the memory consumption so that some improvement that consumes more memory cannot be integrated into Mrooby. But yeah, addressing hash is one idea that should be getting into Mrooby. So I know that C-Ruby and Mrooby are both your children, so you can't pick a favorite. But do you ever feel like, as you work on Mrooby, that some of the things that some of the, I won't call them mistakes, some of the decisions that were made in C-Ruby that you made different decisions in Mrooby and that you like those decisions better. Do you find yourself feeling that way? Yeah, I have two favorite things in Mrooby that are better than C-Ruby, which is one is that Mrooby drops some legacy cryptics, the dollar variables, like a comma, a symbol, something like that. And then the second thing is that Mrooby has the embeddable API, which is slightly better to embed something, embed the Ruby version machine into your application. So one thing, we have people that are raising, like raise hands in the middle of the seats, like the rows as well. Well, if we're lining up, then we're lining up. Okay, so are we lining up? I think we're lining up now. Apparently, this is the easiest mic runner job ever. Thank you. I do what I can. Now Mike has the mic. Hello, gentlemen. Hello. Matt, I was wondering if you could, I think you gave, or you announced the Ruby 3x3 last year. Could you give us an update on that, the progress that's been made and positives and negatives that have come out in the last year? Last year, we improved some. So for example, the forthcoming Ruby 2.4 in next Christmas, we will have the hash and the faster rational numbers. We have made several performance improvements, including those improvements. Ruby 2.4 will be slightly faster than Ruby 2.3. So we will add up those kind of improvements until we will get the 3x3 3x3 comparing to Ruby 2.0. So that's good. So you feel like the releases are the status reports for Ruby 3. So as we get 2.4, we see it's however many times faster on whatever relevant benchmark we're using, opt-carat or whatever we're using. We're preparing to do some kind of web application benchmark along with opt-carat, which is kind of different from the normal usage. It's very interesting. Yeah, it is very interesting. We can only run the end body simulation so many times before we realize it's not, no one really does that. People do play Nintendo though, so that's a much better event for us. Yeah, it does sense to be with it. Yes, we can go to another question. You are very intent in your talk on not breaking backwards compatibility, which I think is great. But I wanted to ask you, if you could, if there was no drawback to it, what are your top three Ruby features that you would get rid of? Top three? You get this question every year. You should just be, whop, whop, whop, whop, whop. Yeah, the par, yeah, the variable is inherited from parole and then threads. Maybe I should make evolve a keyword. Oh, that's a good one. The old dollar one, dollar two. Yeah, dollar one, dollar two things. And the G-Star broke to take a much, much data instead of the much the result of story. So some of my friends have suggested there's maybe a one word answer to this question. And if that's true, that's fine. I just wanted to know for the new concurrency model, why didn't you use actors? We decided to make no breaking, compatibility breaking, breakage so that we have to keep a thread model inside of something we are going to introduce. The name actor is not fit in that kind of model. That's only me. It's very loaded at this point too, the term actor. I'm wondering what the one word answer is that? Because. Of compatibility. Okay, okay. I would have liked because personally. But I have a five-fold. Just because. Yes? Hey, so contributing to Ruby as a new contributor is a little tricky to wrap your mind around sometimes. I've heard a lot of people talk about that being there's a lot of friction in that process. Is the core team thinking about ways to make that easier for new contributors or think about other ways to try and bring more people into contributing to Ruby core? Since Ruby has long history of development and we have a lot of constraints. But we have improved the things a lot better. For example, we have GitHub repository already and then we accept the progress to there. I'm not sure what else we can improve that. If you have an idea, submit to the Ruby bugs. We should track her. I think I'll follow up on that real fast. Are there places that I think people wonder where, what parts of Ruby if they want to contribute that they could contribute to? Does CGI.rb need a new maintainer or whatever? Like a good example. Do you have any of those offhand? I mean, we could. I'm not putting you on the spot here at all, obviously. That might be a good thing to have as a list somewhere. I know that Ruby core has been very good about finding and just accepting new maintainers for old things in the standard library, for instance. Any thoughts there? From time to time, we have some kind of developer meeting mostly in Tokyo. We listed up the things we do and things we have to do. We put our agenda and what logs on top of our Wiki. By checking those Wiki pages, you can find things we can't cooperate. I know that at one point there was a big push. I mean, that was Rails. Was there a big push? There was a big push at one point to really try and improve a lot of the documentation. Do we feel like that was a successful push? Yeah, sure. Okay. If you have some kind of undocumented things, you can explain the things. Just submit the pull request to the source code. That's always a good and easy place to start, too. Especially now accepting pull requests that helps people get involved, I think. We don't directly accept the pull request, but we can easily convert the pull request into the subversion. I think many folks here might be surprised to understand that Ruby actually technically supports tail call optimization. I don't think you could have made it harder to use. Any chance you're going to make that more accessible? I think it's up to him. Yeah, ask him, maybe. I mean, I think we've talked about this before, too. Oh. Yeah, it's fine. So actually, we ignored our request about the tail call optimization, but we already implemented, but it default disabled. So it depends on the request, the voice of the request. So I don't have, so only a few voices. Yeah, very few people are required. Okay, raise your hand. Only a few. We have some people raised their hands. I will follow up with a very technical question then, just to quell the minor uprising that's going on right now. Yeah. Do you want self tail recursion or mutual tail recursion? It's not a recursion, but only a tail call. So it's not depends on the tail call. So it would be mutual. So do you like stack traces? Yeah, yeah, that is a technical program. Because that's the main reason that they don't get turned on. Sometimes the stack traces are very important for debugging. So we need to keep all of the stack traces. So another idea is introduce a new syntax to a two-force tail call. So like if we use a go to and call function. So for example, it can be a tail call. So it is intentional. But of course, go to is not acceptable by that. So maybe it is a discussion we need. Let's see where we're going. Yes. I'll go from radically technical to radically non-technical. I'm wondering if you still enjoy maintaining Ruby and what do you do to keep your interest and passion? Yeah, I'm still enjoying maintaining Ruby. At least for Ruby, I don't code for a long time. Koichi and other commenters do code. But as a language designer, design and making decisions is quite enjoyable. And I have some other projects to work on as a programmer. Howdy. I was wondering what kind of documentation you might have had back when you were a user of one and future you. Or I was afraid of that response. Were any documentation, once you had that email list where people started to get involved, any documentation at all? Even one code comment? Were all the Git commits? I know there was no Git. I'll ask a similar follow between question. I remember this, you said that those first few posts you were working on, Ruby, and you put it on like a BBS or an FTP or something like that, and then you told people, hey, you could download it. Was it just download it and was there even a make file? It has make file. But it was just a make file with a bunch of C? And they was just like, have fun? Yes. Okay. Fundamentally. Refresh my memory. Was it online before or after the name? Was it online before? Was it still Matz's list? No, it was online as a Ruby. I named Ruby way before I put it on the web. Internet. So no, no documentation. No documentation. Okay. So Akina Matsuda in RubyConf Brazil talked a little bit about that some of the standard library is requiring maintainers and that you are making some effort to extract the standard library from core Ruby into their own repositories in order to make it easier. What's the update on that and how can we stay up to date on what are those libraries? Yeah. Back to one eighth era, so we didn't have the proper RubyGEM systems, ecosystem. So I made some kind of decision, we put everything we need into one distribution. So once you install the Ruby, so you can do the XML processing, the web application or whatever, for everything. I still love RxML. I'll just put that out there. But go ahead. Yeah. And then we gather those kind of library out of the Internet. And as time passed, so some maintainers just disappeared, some maintainers just graduated from school and no longer work for Ruby and no time for work for the maintainer standard libraries. So for those kind of reasons, so that we have some are maintained the library in the standard distribution. So the two resolved, and then yeah, for those kind of reasons, so we gradually moved that kind of standard library out of the standard distribution to GEMs. For example, we recently put the TK out of standard distribution. I don't know, I mean, we made the TK as a bundle GEM, so you can update the TK GEM, the independent from the Ruby versions. So then we gradually moved those GEMs out of the standard distribution gradually. And so I think we have the list of maintainers in our Wiki pages. And so you can find the un-maintained standard library there. And yeah, I'm happy you raised your hand to pick up your mentor. I have a question for you as a language designer. So Ruby 2 has been remarkably easy to upgrade to, at least for my company. And I'm just wondering if, you know, basically I just see improvements every time we upgrade. Do you have any bigger regrets about Ruby 2 that you haven't been able to address and that you want to address in Ruby 3 that you haven't mentioned yet? Other than threads. I don't know. But I said I tried to keep compatibility for no reason. I mean, if there's a reason, so we make some incompatibility. So what? But those kind of incompatibility should be minimal and should not harm many people. Like maybe two, three people. Well, I have this question as well. Like in 2.4, the integer unification has some backwards incompatibility because before you could have a method on 6num that wasn't on big num if you added it yourself. And in 2.4, it will be in both places because 6num and big num are just, they all point to the same class now, right? So you're okay breaking some, like fixing some things and breaking some incompatibility. Do you feel, do you kind of look at the feature and kind of say like, well, you know, no one should have been depending on this. I know that this is many years now, but I know that for instance, redo, remember we decided that the redo keyword, this is like five years ago now, we decided the redo keyword was too problematic and it was okay to break backwards compatibility, right? So you kind of have to look, you want to look at all of those little ones and decide that's small enough or dangerous enough to break, right? Yeah. I don't think we can remember redo keyword if we have now. In the block. In the block. Yeah. I don't think it works in, Koichi doesn't work in? No. In 2.0? It doesn't. Yeah, I didn't think so. So, I mean, it was, I guess it was removed in 2.0 anyway, so never mind. Yeah, that's kind of, yeah. So there's no, you know, there's no rule that can be breakable, but the compatibility is one of them. So we break compatibility sometimes, but very few times for the sake of compatibility. During the discussion about the possibly adding a code of conduct to Ruby, you said that you never wanted anyone to be permanently banned from the Ruby community. Yeah. Can you just explain why you feel that way? Wait, that long, long discussion was kind of confusing. So the Ruby community is a vague thing. So one can consider yourself as a member of the Ruby community without any, say, initiation or anything. Membership fees. Yeah, membership fees or anything. So how can we ban those kind of things? No, no. So for that reason, so I cannot accept the banning from anyone from the community. So there is some kind of the community or the group of people with that kind of boundary. For example, RubyConf has the attendee or non-attendee. We can have some kind of strict boundary. So we can ban anybody who behaved very bad from the conference. That's okay. But we cannot ban anyone from the big membership. So for that reason, I refuse the banning. What about from, but you would consider it maybe from the CRuby, the CRuby core team, right? Because that's a separate, very small thing. Yeah, if the discussion was to set up the code of conduct among the CRuby development team or something like that, it could be possible. But that discussion was setting up the code of conduct for the whole Ruby community so that we cannot set up that kind of code. Yeah. And Ruby development committee itself is still vague, though. Yeah. I mean, you'd have to start there. You'd have to start and say, like, what is the boundaries that we're talking about here? So this is a little bit a futuristic question, but do you have any big, long-term big vision for Ruby, like maybe five, 10 years from now? And how do you think it's going to transform over that long? Wait, before you answer that question, I want him to answer your question. It's hard. I know this is a hard question. So what I will say instead is five years ago, so 2011, RubyConf, do you feel like that the things you thought about then that you've actually made good progress to where we are now, right? Let's start with that question. So think back five years. Where were we five years ago and where we are now? Do you feel like we've accomplished a lot? Five years ago, 2011? Let's see, we were in New Orleans. We were in New Orleans celebrating the 10th anniversary of the RubyConf. And then we have somewhat 500-ish attendees. And then we haven't had two or yet. One, nine, two, or one, three or something. Yeah, Ruby2 is the biggest accomplishment in the last five years. Ruby2, we implemented several new things like the module prepend and the refinement. From last, say, five years, Ruby runs much, much faster. So say, at least 50% faster for most of the cases. Mostly due to the improvement on the garbage grotto and somewhat of the internal structure, improvement on the internal structure. So Ruby became faster and Ruby became more powerful. And Ruby community became bigger and Ruby positioned in the technical industry. IT industry is more established. So yeah. Okay, so now thinking forward five years, do you feel like we are on a good trajectory to continue those things? Keep doing those things? Do you put your future-sea glasses on? Yeah. So in five years, we will have the Ruby3 in some form. And then we will have the even faster Ruby. And by the future Ruby utilize the multi-core, in that time, we have some 128 cores on the PC. Maybe. Yeah, maybe. And in addition, so the Ruby should be still. I mean, the technology comes and goes. So Ruby is no longer shiny language at the present time even. So my point is Ruby is keep improving and keep becoming more and more powerful so that Ruby can survive in five, 10 years. So I'm not really able of the phrase that the slogan from Intel, the only is that the last can survive, so I try to be paranoid to survive. So surviving last two and 20 years is kind of a big challenge. And surviving next 10, coming this 10 years will be even harder. But I try to survive after those kinds of challenges. Sure. Yeah. Hi, I've always been confused about the use of private and protected methods. I think you've mentioned in the past having some regrets about the naming. Are there private and protected? Is there any plans for fixing that in some ways in the future? Yeah, to confess that, I regret other things, especially protected. But I don't think we can fix them without breaking compatibility. So I don't think I can remove them for the sake of beauty at the cost of the pain in the community. Let's do a quick survey. Who uses protected methods? There's two of you. Three. We'll figure out an option. Something to consider. Who uses protected correctly? Yeah, who uses it correctly? Do you ever use protected methods? No. Yeah. So. Koichi, do you ever use protected methods? No. Koichi doesn't use them either. So I bet Nobu doesn't use them. Yeah, probably we have to bring Shugo here. Shugo? He added. Yeah, he probably still uses them. He's probably the only one. Probably he's not using. All right. Yeah, I've heard he said he regret. Oh, okay. Well, something to consider for Ruby 3. Yes. So often in RubyConf we see a lot of other languages being displayed on slides and talking about other languages. I'm curious if there are any other languages that you're playing with or getting inspiration from? I'm a language geek. I love to study about the programming language in general. So recently I studied, I checked Elixir and Closure, the Scholar, what else? A little bit of a hot scale, which is kind of difficult for me. I'm not sure if it's in some streaming programming language like Pony or I don't remember them. I just read through the social, which is the Google streaming language. And we don't have implementation out onto Google. Yeah, but those kind of languages. I think we've got one last question here. Pearl was one of your languages that inspired you, some of the features in Ruby originally. And Pearl 6 came out just last year. Besides taking 10 years to come out, is there anything you can learn from Pearl 6? Actually I'm pretty satisfied that I see influence from Ruby in Pearl 6. And besides that, I'm pretty impressed by their rules, which is kind of their internal DSL to define some new syntax or grammar into the language or something. And it is a different form of the regular expression. So I'm quite impressive. It was quite impressive, but I'm not sure we can add it to Ruby. All right, well, we have 30 seconds left, so we're right on time. So I want to thank Matt. I want to thank all of you for all of your questions. And I want to thank you for a really great RubyConf. And that RailsConf COP is open right now. So time's ticking. Thanks everybody for coming. We've got social available right outside those doors. Go out there, have a good time, talk with your fellow Rubyists, and we'll see you next time. Bye.
 How's everything going?  Great.  Good.  How's everything going?  Oh good!  Tired?  I'm a little tired.  I won't lie.  Good conference so far?  Yes.  I missed several ones.  I'm sorry.  That was fine.  No, not at all.  So we'll jump right in at the questions.  So people have some questions about your presentation from the first day.  One of the questions was when you talk about doing the type inference, people were interested  if you could talk a little bit more about that and maybe talk about how do dynamic methods  and metaprogramming fit in with that.  So when would the type checking happen or would the program ever type check itself?  Would it just be a database?  The database stuff and the type checking stuff is done in compile time so that we cannot  check the things that happen dynamically like eval and defined method things.  So in that case, we just ignore them.  At the beginning, I'm going to create some kind of prototype of the independent type  checker like a lean things so you can consider these type errors as a warning to your program.  So that might be false positive just because of the method missing stuff or the eval stuff.  And at least the type checker can warn you that we cannot detect that kind of error in  compile time information.  So I mean compile time is such a vague term with Ruby.  Right?  Because it's not like C where we know that there's this time where we're compiling and  there's this time where we're running.  Compile time is sort of this strange time while we're running the code that sets up  the other code.  So like do you think that will the stuff that runs at compile time be able to see through  require statements?  Yes.  So the require...  Would it be able to see into gems for instance, that kind of thing?  Yeah.  The reference is pretty limited but the compile time type checker sees require that look for  the library source code.  So then include read them, read the source code into the software.  Do you think of the type checker as part of the normal loader or is it a separate thing  that's looking at the code?  A separate thing at the beginning.  Okay.  Okay.  Cool.  Again, if this is too vague, you can ask a question.  We've got people.  Oh, we have people.  We have questions already.  Is it related to this topic or is it another topic entirely?  It's on GILS.  It's on GILS.  That's fine.  All right.  Go ahead and ask your question and then we'll let math turn you down.  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 with regards to type checking.  So with your type checking methodology, I believe you had said during your talk that you were  looking at this but you could throw it out just like you did from last year.  What other methodologies have you considered that are number two or say number three on  the list or are there no number two or number three at this point?  You mean for type checking?  For type checking.  What crazy idea do you have when you go walk the dog?  That's when I have all my crazy ideas at the shower.  So for type checking, I have no that kind of crazy idea though.  The usual compile time information is very limited at least for Ruby programs because  we have nothing.  So we can infer something by say assignments or from the literals.  You can't know string literal is a literal but otherwise we have no information, no argument  types, no return variable types.  We don't have enough information to complement that.  So we add some kind of database things like gathering one time information or maybe so  putting out the method set information out of the running program.  So then check this kind of the inconsistency out of those information.  Did you when you were thinking and working about this, did you look at the other attempts  that people have made for it?  I know that a conversation I have had over the last couple of days, someone brought up  was do you remember the old diamond back?  Yeah, yeah, yeah, soft diamond.  I mean do you feel like those, I remember in your presentation you said that you felt  like they forced people to type annotations too much and is that your main takeaway from  a lot of those other attempts is that they're always forcing people to try and type their  type?  Yeah, I did a little survey about the previous research or something.  And the two things I can tell is the gathering component information out of the non-typed  no-type annotation software is not really good enough.  So the previous attempt including diamond backs and say type to scheme, I remember that  word.  Yeah, with all failed and gave up.  Yeah, give up, I mean.  But so the one thing I want to assure is we need something in addition.  These kind of runtime type information gathering by database things is my attempt to add info  to the programming structure information.  So how would you think we can, we'll change the topic here in a second.  How do you think people would interact with it?  Would it, when I run code, would it complain at me or would I have to decide, oh, you know  what, I'll do my type checking before I check it in to get.  How would you want people to interact with the type checking?  The fundamentally, so I want the compiler or type checker to read our intention from  the code so that you don't have to make some kind of interaction.  But at the same time, for at least for the short term, so we can try to read our documents  like a yard things, then we can add the information back and forth to, with yard documentation.  Like we often, we write the yard documentation with the return value and the argument value.  So we can take information from that in the short term.  And maybe in the future, we can, in reverse, we can put that kind of those information  into the yard documentation.  Okay.  We have questions.  We're swapping.  Yes.  Okay.  This question is on Mrooby.  Is now a good time to change the topic.  That's fine.  Yeah, absolutely.  Okay.  So Matt, I know that Mrooby is not a fork.  I learned it just today of 1.9, it is a brand new code base, correct?  Of 1.9?  Mrooby is a brand new code base.  He wasn't forked from 1.9.  No.  No.  I took the description from 1.9 source code base, but I modified a lot.  So I don't consider Mrooby to be the fork of 1.9.  Okay.  So my question is, what would it take to get some of these improvements, performance and  GC improvements from the current Ruby into Mrooby?  Or is that not even on the plan?  The biggest improvement on top of the 1.9, after the 1.9, was the making it generational  and making it incremental.  And the Mrooby garbage collector is generational and incremental from day one.  So we don't have to put in that kind of improvement on Mrooby GC.  But what about some other improvements, like making hash faster?  In general, how do I get the code that is in Ruby into Mrooby?  Yeah, it's quite possible.  But for Mrooby, we have somewhat different criteria about including that.  For example, Mrooby should reduce the memory consumption so that some improvement that  consumes more memory cannot be integrated into Mrooby.  But yeah, addressing hash is one idea that should be getting into Mrooby.  So I know that C-Ruby and Mrooby are both your children, so you can't pick a favorite.  But do you ever feel like, as you work on Mrooby, that some of the things that some of the,  I won't call them mistakes, some of the decisions that were made in C-Ruby that you made different  decisions in Mrooby and that you like those decisions better.  Do you find yourself feeling that way?  Yeah, I have two favorite things in Mrooby that are better than C-Ruby, which is one  is that Mrooby drops some legacy cryptics, the dollar variables, like a comma, a symbol,  something like that.  And then the second thing is that Mrooby has the embeddable API, which is slightly better  to embed something, embed the Ruby version machine into your application.  So one thing, we have people that are raising, like raise hands in the middle of the seats,  like the rows as well.  Well, if we're lining up, then we're lining up.  Okay, so are we lining up?  I think we're lining up now.  Apparently, this is the easiest mic runner job ever.  Thank you.  I do what I can.  Now Mike has the mic.  Hello, gentlemen.  Hello.  Matt, I was wondering if you could, I think you gave, or you announced the Ruby 3x3 last  year.  Could you give us an update on that, the progress that's been made and positives and negatives  that have come out in the last year?  Last year, we improved some.  So for example, the forthcoming Ruby 2.4 in next Christmas, we will have the hash and  the faster rational numbers.  We have made several performance improvements, including those improvements.  Ruby 2.4 will be slightly faster than Ruby 2.3.  So we will add up those kind of improvements until we will get the 3x3 3x3 comparing to  Ruby 2.0.  So that's good.  So you feel like the releases are the status reports for Ruby 3.  So as we get 2.4, we see it's however many times faster on whatever relevant benchmark  we're using, opt-carat or whatever we're using.  We're preparing to do some kind of web application benchmark along with opt-carat, which is kind  of different from the normal usage.  It's very interesting.  Yeah, it is very interesting.  We can only run the end body simulation so many times before we realize it's not, no  one really does that.  People do play Nintendo though, so that's a much better event for us.  Yeah, it does sense to be with it.  Yes, we can go to another question.  You are very intent in your talk on not breaking backwards compatibility, which I think is  great.  But I wanted to ask you, if you could, if there was no drawback to it, what are your  top three Ruby features that you would get rid of?  Top three?  You get this question every year.  You should just be, whop, whop, whop, whop, whop.  Yeah, the par, yeah, the variable is inherited from parole and then threads.  Maybe I should make evolve a keyword.  Oh, that's a good one.  The old dollar one, dollar two.  Yeah, dollar one, dollar two things.  And the G-Star broke to take a much, much data instead of the much the result of story.  So some of my friends have suggested there's maybe a one word answer to this question.  And if that's true, that's fine.  I just wanted to know for the new concurrency model, why didn't you use actors?  We decided to make no breaking, compatibility breaking, breakage so that we have to keep  a thread model inside of something we are going to introduce.  The name actor is not fit in that kind of model.  That's only me.  It's very loaded at this point too, the term actor.  I'm wondering what the one word answer is that?  Because.  Of compatibility.  Okay, okay.  I would have liked because personally.  But I have a five-fold.  Just because.  Yes?  Hey, so contributing to Ruby as a new contributor is a little tricky to wrap your mind around  sometimes.  I've heard a lot of people talk about that being there's a lot of friction in that process.  Is the core team thinking about ways to make that easier for new contributors or think  about other ways to try and bring more people into contributing to Ruby core?  Since Ruby has long history of development and we have a lot of constraints.  But we have improved the things a lot better.  For example, we have GitHub repository already and then we accept the progress to there.  I'm not sure what else we can improve that.  If you have an idea, submit to the Ruby bugs.  We should track her.  I think I'll follow up on that real fast.  Are there places that I think people wonder where, what parts of Ruby if they want to  contribute that they could contribute to?  Does CGI.rb need a new maintainer or whatever?  Like a good example.  Do you have any of those offhand?  I mean, we could.  I'm not putting you on the spot here at all, obviously.  That might be a good thing to have as a list somewhere.  I know that Ruby core has been very good about finding and just accepting new maintainers  for old things in the standard library, for instance.  Any thoughts there?  From time to time, we have some kind of developer meeting mostly in Tokyo.  We listed up the things we do and things we have to do.  We put our agenda and what logs on top of our Wiki.  By checking those Wiki pages, you can find things we can't cooperate.  I know that at one point there was a big push.  I mean, that was Rails.  Was there a big push?  There was a big push at one point to really try and improve a lot of the documentation.  Do we feel like that was a successful push?  Yeah, sure.  Okay.  If you have some kind of undocumented things, you can explain the things.  Just submit the pull request to the source code.  That's always a good and easy place to start, too.  Especially now accepting pull requests that helps people get involved, I think.  We don't directly accept the pull request, but we can easily convert the pull request  into the subversion.  I think many folks here might be surprised to understand that Ruby actually technically  supports tail call optimization.  I don't think you could have made it harder to use.  Any chance you're going to make that more accessible?  I think it's up to him.  Yeah, ask him, maybe.  I mean, I think we've talked about this before, too.  Oh.  Yeah, it's fine.  So actually, we ignored our request about the tail call optimization, but we already  implemented, but it default disabled.  So it depends on the request, the voice of the request.  So I don't have, so only a few voices.  Yeah, very few people are required.  Okay, raise your hand.  Only a few.  We have some people raised their hands.  I will follow up with a very technical question then, just to quell the minor uprising that's  going on right now.  Yeah.  Do you want self tail recursion or mutual tail recursion?  It's not a recursion, but only a tail call.  So it's not depends on the tail call.  So it would be mutual.  So do you like stack traces?  Yeah, yeah, that is a technical program.  Because that's the main reason that they don't get turned on.  Sometimes the stack traces are very important for debugging.  So we need to keep all of the stack traces.  So another idea is introduce a new syntax to a two-force tail call.  So like if we use a go to and call function.  So for example, it can be a tail call.  So it is intentional.  But of course, go to is not acceptable by that.  So maybe it is a discussion we need.  Let's see where we're going.  Yes.  I'll go from radically technical to radically non-technical.  I'm wondering if you still enjoy maintaining Ruby and what do you do to keep your interest  and passion?  Yeah, I'm still enjoying maintaining Ruby.  At least for Ruby, I don't code for a long time.  Koichi and other commenters do code.  But as a language designer, design and making decisions is quite enjoyable.  And I have some other projects to work on as a programmer.  Howdy.  I was wondering what kind of documentation you might have had back when you were a user  of one and future you.  Or I was afraid of that response.  Were any documentation, once you had that email list where people started to get involved,  any documentation at all?  Even one code comment?  Were all the Git commits?  I know there was no Git.  I'll ask a similar follow between question.  I remember this, you said that those first few posts you were working on, Ruby, and  you put it on like a BBS or an FTP or something like that, and then you told people, hey,  you could download it.  Was it just download it and was there even a make file?  It has make file.  But it was just a make file with a bunch of C?  And they was just like, have fun?  Yes.  Okay.  Fundamentally.  Refresh my memory.  Was it online before or after the name?  Was it online before?  Was it still Matz's list?  No, it was online as a Ruby.  I named Ruby way before I put it on the web.  Internet.  So no, no documentation.  No documentation.  Okay.  So Akina Matsuda in RubyConf Brazil talked a little bit about that some of the standard  library is requiring maintainers and that you are making some effort to extract the standard  library from core Ruby into their own repositories in order to make it easier.  What's the update on that and how can we stay up to date on what are those libraries?  Yeah.  Back to one eighth era, so we didn't have the proper RubyGEM systems, ecosystem.  So I made some kind of decision, we put everything we need into one distribution.  So once you install the Ruby, so you can do the XML processing, the web application  or whatever, for everything.  I still love RxML.  I'll just put that out there.  But go ahead.  Yeah.  And then we gather those kind of library out of the Internet.  And as time passed, so some maintainers just disappeared, some maintainers just graduated  from school and no longer work for Ruby and no time for work for the maintainer standard  libraries.  So for those kind of reasons, so that we have some are maintained the library in the standard  distribution.  So the two resolved, and then yeah, for those kind of reasons, so we gradually moved that  kind of standard library out of the standard distribution to GEMs.  For example, we recently put the TK out of standard distribution.  I don't know, I mean, we made the TK as a bundle GEM, so you can update the TK GEM,  the independent from the Ruby versions.  So then we gradually moved those GEMs out of the standard distribution gradually.  And so I think we have the list of maintainers in our Wiki pages.  And so you can find the un-maintained standard library there.  And yeah, I'm happy you raised your hand to pick up your mentor.  I have a question for you as a language designer.  So Ruby 2 has been remarkably easy to upgrade to, at least for my company.  And I'm just wondering if, you know, basically I just see improvements every time we upgrade.  Do you have any bigger regrets about Ruby 2 that you haven't been able to address and  that you want to address in Ruby 3 that you haven't mentioned yet?  Other than threads.  I don't know.  But I said I tried to keep compatibility for no reason.  I mean, if there's a reason, so we make some incompatibility.  So what?  But those kind of incompatibility should be minimal and should not harm many people.  Like maybe two, three people.  Well, I have this question as well.  Like in 2.4, the integer unification has some backwards incompatibility because before  you could have a method on 6num that wasn't on big num if you added it yourself.  And in 2.4, it will be in both places because 6num and big num are just, they all point  to the same class now, right?  So you're okay breaking some, like fixing some things and breaking some incompatibility.  Do you feel, do you kind of look at the feature and kind of say like, well, you know, no one  should have been depending on this.  I know that this is many years now, but I know that for instance, redo, remember we  decided that the redo keyword, this is like five years ago now, we decided the redo keyword  was too problematic and it was okay to break backwards compatibility, right?  So you kind of have to look, you want to look at all of those little ones and decide that's  small enough or dangerous enough to break, right?  Yeah.  I don't think we can remember redo keyword if we have now.  In the block.  In the block.  Yeah.  I don't think it works in, Koichi doesn't work in?  No.  In 2.0?  It doesn't.  Yeah, I didn't think so.  So, I mean, it was, I guess it was removed in 2.0 anyway, so never mind.  Yeah, that's kind of, yeah.  So there's no, you know, there's no rule that can be breakable, but the compatibility is  one of them.  So we break compatibility sometimes, but very few times for the sake of compatibility.  During the discussion about the possibly adding a code of conduct to Ruby, you said that you  never wanted anyone to be permanently banned from the Ruby community.  Yeah.  Can you just explain why you feel that way?  Wait, that long, long discussion was kind of confusing.  So the Ruby community is a vague thing.  So one can consider yourself as a member of the Ruby community without any, say, initiation  or anything.  Membership fees.  Yeah, membership fees or anything.  So how can we ban those kind of things?  No, no.  So for that reason, so I cannot accept the banning from anyone from the community.  So there is some kind of the community or the group of people with that kind of boundary.  For example, RubyConf has the attendee or non-attendee.  We can have some kind of strict boundary.  So we can ban anybody who behaved very bad from the conference.  That's okay.  But we cannot ban anyone from the big membership.  So for that reason, I refuse the banning.  What about from, but you would consider it maybe from the CRuby, the CRuby core team,  right?  Because that's a separate, very small thing.  Yeah, if the discussion was to set up the code of conduct among the CRuby development  team or something like that, it could be possible.  But that discussion was setting up the code of conduct for the whole Ruby community so  that we cannot set up that kind of code.  Yeah.  And Ruby development committee itself is still vague, though.  Yeah.  I mean, you'd have to start there.  You'd have to start and say, like, what is the boundaries that we're talking about here?  So this is a little bit a futuristic question, but do you have any big, long-term big vision  for Ruby, like maybe five, 10 years from now?  And how do you think it's going to transform over that long?  Wait, before you answer that question, I want him to answer your question.  It's hard.  I know this is a hard question.  So what I will say instead is five years ago, so 2011, RubyConf, do you feel like that the  things you thought about then that you've actually made good progress to where we are  now, right?  Let's start with that question.  So think back five years.  Where were we five years ago and where we are now?  Do you feel like we've accomplished a lot?  Five years ago, 2011?  Let's see, we were in New Orleans.  We were in New Orleans celebrating the 10th anniversary of the RubyConf.  And then we have somewhat 500-ish attendees.  And then we haven't had two or yet.  One, nine, two, or one, three or something.  Yeah, Ruby2 is the biggest accomplishment in the last five years.  Ruby2, we implemented several new things like the module prepend and the refinement.  From last, say, five years, Ruby runs much, much faster.  So say, at least 50% faster for most of the cases.  Mostly due to the improvement on the garbage grotto and somewhat of the internal structure,  improvement on the internal structure.  So Ruby became faster and Ruby became more powerful.  And Ruby community became bigger and Ruby positioned in the technical industry.  IT industry is more established.  So yeah.  Okay, so now thinking forward five years, do you feel like we are on a good trajectory  to continue those things?  Keep doing those things?  Do you put your future-sea glasses on?  Yeah.  So in five years, we will have the Ruby3 in some form.  And then we will have the even faster Ruby.  And by the future Ruby utilize the multi-core, in that time, we have some 128 cores on the  PC.  Maybe.  Yeah, maybe.  And in addition, so the Ruby should be still.  I mean, the technology comes and goes.  So Ruby is no longer shiny language at the present time even.  So my point is Ruby is keep improving and keep becoming more and more powerful so that  Ruby can survive in five, 10 years.  So I'm not really able of the phrase that the slogan from Intel, the only is that the  last can survive, so I try to be paranoid to survive.  So surviving last two and 20 years is kind of a big challenge.  And surviving next 10, coming this 10 years will be even harder.  But I try to survive after those kinds of challenges.  Sure.  Yeah.  Hi, I've always been confused about the use of private and protected methods.  I think you've mentioned in the past having some regrets about the naming.  Are there private and protected?  Is there any plans for fixing that in some ways in the future?  Yeah, to confess that, I regret other things, especially protected.  But I don't think we can fix them without breaking compatibility.  So I don't think I can remove them for the sake of beauty at the cost of the pain in  the community.  Let's do a quick survey.  Who uses protected methods?  There's two of you.  Three.  We'll figure out an option.  Something to consider.  Who uses protected correctly?  Yeah, who uses it correctly?  Do you ever use protected methods?  No.  Yeah.  So.  Koichi, do you ever use protected methods?  No.  Koichi doesn't use them either.  So I bet Nobu doesn't use them.  Yeah, probably we have to bring Shugo here.  Shugo?  He added.  Yeah, he probably still uses them.  He's probably the only one.  Probably he's not using.  All right.  Yeah, I've heard he said he regret.  Oh, okay.  Well, something to consider for Ruby 3.  Yes.  So often in RubyConf we see a lot of other languages being displayed on slides and talking  about other languages.  I'm curious if there are any other languages that you're playing with or getting inspiration  from?  I'm a language geek.  I love to study about the programming language in general.  So recently I studied, I checked Elixir and Closure, the Scholar, what else?  A little bit of a hot scale, which is kind of difficult for me.  I'm not sure if it's in some streaming programming language like Pony or I don't remember them.  I just read through the social, which is the Google streaming language.  And we don't have implementation out onto Google.  Yeah, but those kind of languages.  I think we've got one last question here.  Pearl was one of your languages that inspired you, some of the features in Ruby originally.  And Pearl 6 came out just last year.  Besides taking 10 years to come out, is there anything you can learn from Pearl 6?  Actually I'm pretty satisfied that I see influence from Ruby in Pearl 6.  And besides that, I'm pretty impressed by their rules, which is kind of their internal  DSL to define some new syntax or grammar into the language or something.  And it is a different form of the regular expression.  So I'm quite impressive.  It was quite impressive, but I'm not sure we can add it to Ruby.  All right, well, we have 30 seconds left, so we're right on time.  So I want to thank Matt.  I want to thank all of you for all of your questions.  And I want to thank you for a really great RubyConf.  And that RailsConf COP is open right now.  So time's ticking.  Thanks everybody for coming.  We've got social available right outside those doors.  Go out there, have a good time, talk with your fellow Rubyists, and we'll see you next  time.  Bye.
Matz_Q_A_0_191.png Matz_Q_A_192_407.png Matz_Q_A_408_587.png Matz_Q_A_588_863.png Matz_Q_A_864_971.png Matz_Q_A_972_1055.png Matz_Q_A_1056_1259.png Matz_Q_A_1260_1355.png Matz_Q_A_1356_1559.png Matz_Q_A_1560_1739.png Matz_Q_A_1740_1859.png Matz_Q_A_1860_2267.png Matz_Q_A_2268_6563.png Matz_Q_A_6564_6683.png Matz_Q_A_6684_7655.png Matz_Q_A_7656_8567.png Matz_Q_A_8568_8843.png Matz_Q_A_8844_9275.png Matz_Q_A_9276_9935.png Matz_Q_A_9936_10427.png Matz_Q_A_10428_10679.png Matz_Q_A_10680_12011.png Matz_Q_A_12012_13163.png Matz_Q_A_13164_15575.png Matz_Q_A_15576_19199.png Matz_Q_A_19200_22391.png Matz_Q_A_22392_25235.png Matz_Q_A_25236_25967.png Matz_Q_A_25968_26207.png Matz_Q_A_26208_27011.png Matz_Q_A_27012_27359.png Matz_Q_A_27360_31355.png Matz_Q_A_31356_33083.png Matz_Q_A_33084_33215.png Matz_Q_A_33216_34019.png Matz_Q_A_34020_35999.png Matz_Q_A_36000_36107.png Matz_Q_A_36108_39395.png Matz_Q_A_39396_39491.png Matz_Q_A_39492_44315.png Matz_Q_A_44316_46019.png Matz_Q_A_46020_46079.png Matz_Q_A_46080_47459.png Matz_Q_A_47460_50195.png Matz_Q_A_50196_51539.png Matz_Q_A_51540_55907.png Matz_Q_A_55908_57023.png Matz_Q_A_57024_58667.png Matz_Q_A_58668_58787.png Matz_Q_A_58788_58827.png
How's everything going? Great. Good. How's everything going? Oh good! Tired? I'm a little tired. I won't lie. Good conference so far? Yes. I missed several ones. I'm sorry. That was fine. No, not at all. So we'll jump right in at the questions. So people have some questions about your presentation from the first day. One of the questions was when you talk about doing the type inference, people were interested if you could talk a little bit more about that and maybe talk about how do dynamic methods and metaprogramming fit in with that. So when would the type checking happen or would the program ever type check itself? Would it just be a database? The database stuff and the type checking stuff is done in compile time so that we cannot check the things that happen dynamically like eval and defined method things. So in that case, we just ignore them. At the beginning, I'm going to create some kind of prototype of the independent type checker like a lean things so you can consider these type errors as a warning to your program. So that might be false positive just because of the method missing stuff or the eval stuff. And at least the type checker can warn you that we cannot detect that kind of error in compile time information. So I mean compile time is such a vague term with Ruby. Right? Because it's not like C where we know that there's this time where we're compiling and there's this time where we're running. Compile time is sort of this strange time while we're running the code that sets up the other code. So like do you think that will the stuff that runs at compile time be able to see through require statements? Yes. So the require... Would it be able to see into gems for instance, that kind of thing? Yeah. The reference is pretty limited but the compile time type checker sees require that look for the library source code. So then include read them, read the source code into the software. Do you think of the type checker as part of the normal loader or is it a separate thing that's looking at the code? A separate thing at the beginning. Okay. Okay. Cool. Again, if this is too vague, you can ask a question. We've got people. Oh, we have people. We have questions already. Is it related to this topic or is it another topic entirely? It's on GILS. It's on GILS. That's fine. All right. Go ahead and ask your question and then we'll let math turn you down. 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 with regards to type checking. So with your type checking methodology, I believe you had said during your talk that you were looking at this but you could throw it out just like you did from last year. What other methodologies have you considered that are number two or say number three on the list or are there no number two or number three at this point? You mean for type checking? For type checking. What crazy idea do you have when you go walk the dog? That's when I have all my crazy ideas at the shower. So for type checking, I have no that kind of crazy idea though. The usual compile time information is very limited at least for Ruby programs because we have nothing. So we can infer something by say assignments or from the literals. You can't know string literal is a literal but otherwise we have no information, no argument types, no return variable types. We don't have enough information to complement that. So we add some kind of database things like gathering one time information or maybe so putting out the method set information out of the running program. So then check this kind of the inconsistency out of those information. Did you when you were thinking and working about this, did you look at the other attempts that people have made for it? I know that a conversation I have had over the last couple of days, someone brought up was do you remember the old diamond back? Yeah, yeah, yeah, soft diamond. I mean do you feel like those, I remember in your presentation you said that you felt like they forced people to type annotations too much and is that your main takeaway from a lot of those other attempts is that they're always forcing people to try and type their type? Yeah, I did a little survey about the previous research or something. And the two things I can tell is the gathering component information out of the non-typed no-type annotation software is not really good enough. So the previous attempt including diamond backs and say type to scheme, I remember that word. Yeah, with all failed and gave up. Yeah, give up, I mean. But so the one thing I want to assure is we need something in addition. These kind of runtime type information gathering by database things is my attempt to add info to the programming structure information. So how would you think we can, we'll change the topic here in a second. How do you think people would interact with it? Would it, when I run code, would it complain at me or would I have to decide, oh, you know what, I'll do my type checking before I check it in to get. How would you want people to interact with the type checking? The fundamentally, so I want the compiler or type checker to read our intention from the code so that you don't have to make some kind of interaction. But at the same time, for at least for the short term, so we can try to read our documents like a yard things, then we can add the information back and forth to, with yard documentation. Like we often, we write the yard documentation with the return value and the argument value. So we can take information from that in the short term. And maybe in the future, we can, in reverse, we can put that kind of those information into the yard documentation. Okay. We have questions. We're swapping. Yes. Okay. This question is on Mrooby. Is now a good time to change the topic. That's fine. Yeah, absolutely. Okay. So Matt, I know that Mrooby is not a fork. I learned it just today of 1.9, it is a brand new code base, correct? Of 1.9? Mrooby is a brand new code base. He wasn't forked from 1.9. No. No. I took the description from 1.9 source code base, but I modified a lot. So I don't consider Mrooby to be the fork of 1.9. Okay. So my question is, what would it take to get some of these improvements, performance and GC improvements from the current Ruby into Mrooby? Or is that not even on the plan? The biggest improvement on top of the 1.9, after the 1.9, was the making it generational and making it incremental. And the Mrooby garbage collector is generational and incremental from day one. So we don't have to put in that kind of improvement on Mrooby GC. But what about some other improvements, like making hash faster? In general, how do I get the code that is in Ruby into Mrooby? Yeah, it's quite possible. But for Mrooby, we have somewhat different criteria about including that. For example, Mrooby should reduce the memory consumption so that some improvement that consumes more memory cannot be integrated into Mrooby. But yeah, addressing hash is one idea that should be getting into Mrooby. So I know that C-Ruby and Mrooby are both your children, so you can't pick a favorite. But do you ever feel like, as you work on Mrooby, that some of the things that some of the, I won't call them mistakes, some of the decisions that were made in C-Ruby that you made different decisions in Mrooby and that you like those decisions better. Do you find yourself feeling that way? Yeah, I have two favorite things in Mrooby that are better than C-Ruby, which is one is that Mrooby drops some legacy cryptics, the dollar variables, like a comma, a symbol, something like that. And then the second thing is that Mrooby has the embeddable API, which is slightly better to embed something, embed the Ruby version machine into your application. So one thing, we have people that are raising, like raise hands in the middle of the seats, like the rows as well. Well, if we're lining up, then we're lining up. Okay, so are we lining up? I think we're lining up now. Apparently, this is the easiest mic runner job ever. Thank you. I do what I can. Now Mike has the mic. Hello, gentlemen. Hello. Matt, I was wondering if you could, I think you gave, or you announced the Ruby 3x3 last year. Could you give us an update on that, the progress that's been made and positives and negatives that have come out in the last year? Last year, we improved some. So for example, the forthcoming Ruby 2.4 in next Christmas, we will have the hash and the faster rational numbers. We have made several performance improvements, including those improvements. Ruby 2.4 will be slightly faster than Ruby 2.3. So we will add up those kind of improvements until we will get the 3x3 3x3 comparing to Ruby 2.0. So that's good. So you feel like the releases are the status reports for Ruby 3. So as we get 2.4, we see it's however many times faster on whatever relevant benchmark we're using, opt-carat or whatever we're using. We're preparing to do some kind of web application benchmark along with opt-carat, which is kind of different from the normal usage. It's very interesting. Yeah, it is very interesting. We can only run the end body simulation so many times before we realize it's not, no one really does that. People do play Nintendo though, so that's a much better event for us. Yeah, it does sense to be with it. Yes, we can go to another question. You are very intent in your talk on not breaking backwards compatibility, which I think is great. But I wanted to ask you, if you could, if there was no drawback to it, what are your top three Ruby features that you would get rid of? Top three? You get this question every year. You should just be, whop, whop, whop, whop, whop. Yeah, the par, yeah, the variable is inherited from parole and then threads. Maybe I should make evolve a keyword. Oh, that's a good one. The old dollar one, dollar two. Yeah, dollar one, dollar two things. And the G-Star broke to take a much, much data instead of the much the result of story. So some of my friends have suggested there's maybe a one word answer to this question. And if that's true, that's fine. I just wanted to know for the new concurrency model, why didn't you use actors? We decided to make no breaking, compatibility breaking, breakage so that we have to keep a thread model inside of something we are going to introduce. The name actor is not fit in that kind of model. That's only me. It's very loaded at this point too, the term actor. I'm wondering what the one word answer is that? Because. Of compatibility. Okay, okay. I would have liked because personally. But I have a five-fold. Just because. Yes? Hey, so contributing to Ruby as a new contributor is a little tricky to wrap your mind around sometimes. I've heard a lot of people talk about that being there's a lot of friction in that process. Is the core team thinking about ways to make that easier for new contributors or think about other ways to try and bring more people into contributing to Ruby core? Since Ruby has long history of development and we have a lot of constraints. But we have improved the things a lot better. For example, we have GitHub repository already and then we accept the progress to there. I'm not sure what else we can improve that. If you have an idea, submit to the Ruby bugs. We should track her. I think I'll follow up on that real fast. Are there places that I think people wonder where, what parts of Ruby if they want to contribute that they could contribute to? Does CGI.rb need a new maintainer or whatever? Like a good example. Do you have any of those offhand? I mean, we could. I'm not putting you on the spot here at all, obviously. That might be a good thing to have as a list somewhere. I know that Ruby core has been very good about finding and just accepting new maintainers for old things in the standard library, for instance. Any thoughts there? From time to time, we have some kind of developer meeting mostly in Tokyo. We listed up the things we do and things we have to do. We put our agenda and what logs on top of our Wiki. By checking those Wiki pages, you can find things we can't cooperate. I know that at one point there was a big push. I mean, that was Rails. Was there a big push? There was a big push at one point to really try and improve a lot of the documentation. Do we feel like that was a successful push? Yeah, sure. Okay. If you have some kind of undocumented things, you can explain the things. Just submit the pull request to the source code. That's always a good and easy place to start, too. Especially now accepting pull requests that helps people get involved, I think. We don't directly accept the pull request, but we can easily convert the pull request into the subversion. I think many folks here might be surprised to understand that Ruby actually technically supports tail call optimization. I don't think you could have made it harder to use. Any chance you're going to make that more accessible? I think it's up to him. Yeah, ask him, maybe. I mean, I think we've talked about this before, too. Oh. Yeah, it's fine. So actually, we ignored our request about the tail call optimization, but we already implemented, but it default disabled. So it depends on the request, the voice of the request. So I don't have, so only a few voices. Yeah, very few people are required. Okay, raise your hand. Only a few. We have some people raised their hands. I will follow up with a very technical question then, just to quell the minor uprising that's going on right now. Yeah. Do you want self tail recursion or mutual tail recursion? It's not a recursion, but only a tail call. So it's not depends on the tail call. So it would be mutual. So do you like stack traces? Yeah, yeah, that is a technical program. Because that's the main reason that they don't get turned on. Sometimes the stack traces are very important for debugging. So we need to keep all of the stack traces. So another idea is introduce a new syntax to a two-force tail call. So like if we use a go to and call function. So for example, it can be a tail call. So it is intentional. But of course, go to is not acceptable by that. So maybe it is a discussion we need. Let's see where we're going. Yes. I'll go from radically technical to radically non-technical. I'm wondering if you still enjoy maintaining Ruby and what do you do to keep your interest and passion? Yeah, I'm still enjoying maintaining Ruby. At least for Ruby, I don't code for a long time. Koichi and other commenters do code. But as a language designer, design and making decisions is quite enjoyable. And I have some other projects to work on as a programmer. Howdy. I was wondering what kind of documentation you might have had back when you were a user of one and future you. Or I was afraid of that response. Were any documentation, once you had that email list where people started to get involved, any documentation at all? Even one code comment? Were all the Git commits? I know there was no Git. I'll ask a similar follow between question. I remember this, you said that those first few posts you were working on, Ruby, and you put it on like a BBS or an FTP or something like that, and then you told people, hey, you could download it. Was it just download it and was there even a make file? It has make file. But it was just a make file with a bunch of C? And they was just like, have fun? Yes. Okay. Fundamentally. Refresh my memory. Was it online before or after the name? Was it online before? Was it still Matz's list? No, it was online as a Ruby. I named Ruby way before I put it on the web. Internet. So no, no documentation. No documentation. Okay. So Akina Matsuda in RubyConf Brazil talked a little bit about that some of the standard library is requiring maintainers and that you are making some effort to extract the standard library from core Ruby into their own repositories in order to make it easier. What's the update on that and how can we stay up to date on what are those libraries? Yeah. Back to one eighth era, so we didn't have the proper RubyGEM systems, ecosystem. So I made some kind of decision, we put everything we need into one distribution. So once you install the Ruby, so you can do the XML processing, the web application or whatever, for everything. I still love RxML. I'll just put that out there. But go ahead. Yeah. And then we gather those kind of library out of the Internet. And as time passed, so some maintainers just disappeared, some maintainers just graduated from school and no longer work for Ruby and no time for work for the maintainer standard libraries. So for those kind of reasons, so that we have some are maintained the library in the standard distribution. So the two resolved, and then yeah, for those kind of reasons, so we gradually moved that kind of standard library out of the standard distribution to GEMs. For example, we recently put the TK out of standard distribution. I don't know, I mean, we made the TK as a bundle GEM, so you can update the TK GEM, the independent from the Ruby versions. So then we gradually moved those GEMs out of the standard distribution gradually. And so I think we have the list of maintainers in our Wiki pages. And so you can find the un-maintained standard library there. And yeah, I'm happy you raised your hand to pick up your mentor. I have a question for you as a language designer. So Ruby 2 has been remarkably easy to upgrade to, at least for my company. And I'm just wondering if, you know, basically I just see improvements every time we upgrade. Do you have any bigger regrets about Ruby 2 that you haven't been able to address and that you want to address in Ruby 3 that you haven't mentioned yet? Other than threads. I don't know. But I said I tried to keep compatibility for no reason. I mean, if there's a reason, so we make some incompatibility. So what? But those kind of incompatibility should be minimal and should not harm many people. Like maybe two, three people. Well, I have this question as well. Like in 2.4, the integer unification has some backwards incompatibility because before you could have a method on 6num that wasn't on big num if you added it yourself. And in 2.4, it will be in both places because 6num and big num are just, they all point to the same class now, right? So you're okay breaking some, like fixing some things and breaking some incompatibility. Do you feel, do you kind of look at the feature and kind of say like, well, you know, no one should have been depending on this. I know that this is many years now, but I know that for instance, redo, remember we decided that the redo keyword, this is like five years ago now, we decided the redo keyword was too problematic and it was okay to break backwards compatibility, right? So you kind of have to look, you want to look at all of those little ones and decide that's small enough or dangerous enough to break, right? Yeah. I don't think we can remember redo keyword if we have now. In the block. In the block. Yeah. I don't think it works in, Koichi doesn't work in? No. In 2.0? It doesn't. Yeah, I didn't think so. So, I mean, it was, I guess it was removed in 2.0 anyway, so never mind. Yeah, that's kind of, yeah. So there's no, you know, there's no rule that can be breakable, but the compatibility is one of them. So we break compatibility sometimes, but very few times for the sake of compatibility. During the discussion about the possibly adding a code of conduct to Ruby, you said that you never wanted anyone to be permanently banned from the Ruby community. Yeah. Can you just explain why you feel that way? Wait, that long, long discussion was kind of confusing. So the Ruby community is a vague thing. So one can consider yourself as a member of the Ruby community without any, say, initiation or anything. Membership fees. Yeah, membership fees or anything. So how can we ban those kind of things? No, no. So for that reason, so I cannot accept the banning from anyone from the community. So there is some kind of the community or the group of people with that kind of boundary. For example, RubyConf has the attendee or non-attendee. We can have some kind of strict boundary. So we can ban anybody who behaved very bad from the conference. That's okay. But we cannot ban anyone from the big membership. So for that reason, I refuse the banning. What about from, but you would consider it maybe from the CRuby, the CRuby core team, right? Because that's a separate, very small thing. Yeah, if the discussion was to set up the code of conduct among the CRuby development team or something like that, it could be possible. But that discussion was setting up the code of conduct for the whole Ruby community so that we cannot set up that kind of code. Yeah. And Ruby development committee itself is still vague, though. Yeah. I mean, you'd have to start there. You'd have to start and say, like, what is the boundaries that we're talking about here? So this is a little bit a futuristic question, but do you have any big, long-term big vision for Ruby, like maybe five, 10 years from now? And how do you think it's going to transform over that long? Wait, before you answer that question, I want him to answer your question. It's hard. I know this is a hard question. So what I will say instead is five years ago, so 2011, RubyConf, do you feel like that the things you thought about then that you've actually made good progress to where we are now, right? Let's start with that question. So think back five years. Where were we five years ago and where we are now? Do you feel like we've accomplished a lot? Five years ago, 2011? Let's see, we were in New Orleans. We were in New Orleans celebrating the 10th anniversary of the RubyConf. And then we have somewhat 500-ish attendees. And then we haven't had two or yet. One, nine, two, or one, three or something. Yeah, Ruby2 is the biggest accomplishment in the last five years. Ruby2, we implemented several new things like the module prepend and the refinement. From last, say, five years, Ruby runs much, much faster. So say, at least 50% faster for most of the cases. Mostly due to the improvement on the garbage grotto and somewhat of the internal structure, improvement on the internal structure. So Ruby became faster and Ruby became more powerful. And Ruby community became bigger and Ruby positioned in the technical industry. IT industry is more established. So yeah. Okay, so now thinking forward five years, do you feel like we are on a good trajectory to continue those things? Keep doing those things? Do you put your future-sea glasses on? Yeah. So in five years, we will have the Ruby3 in some form. And then we will have the even faster Ruby. And by the future Ruby utilize the multi-core, in that time, we have some 128 cores on the PC. Maybe. Yeah, maybe. And in addition, so the Ruby should be still. I mean, the technology comes and goes. So Ruby is no longer shiny language at the present time even. So my point is Ruby is keep improving and keep becoming more and more powerful so that Ruby can survive in five, 10 years. So I'm not really able of the phrase that the slogan from Intel, the only is that the last can survive, so I try to be paranoid to survive. So surviving last two and 20 years is kind of a big challenge. And surviving next 10, coming this 10 years will be even harder. But I try to survive after those kinds of challenges. Sure. Yeah. Hi, I've always been confused about the use of private and protected methods. I think you've mentioned in the past having some regrets about the naming. Are there private and protected? Is there any plans for fixing that in some ways in the future? Yeah, to confess that, I regret other things, especially protected. But I don't think we can fix them without breaking compatibility. So I don't think I can remove them for the sake of beauty at the cost of the pain in the community. Let's do a quick survey. Who uses protected methods? There's two of you. Three. We'll figure out an option. Something to consider. Who uses protected correctly? Yeah, who uses it correctly? Do you ever use protected methods? No. Yeah. So. Koichi, do you ever use protected methods? No. Koichi doesn't use them either. So I bet Nobu doesn't use them. Yeah, probably we have to bring Shugo here. Shugo? He added. Yeah, he probably still uses them. He's probably the only one. Probably he's not using. All right. Yeah, I've heard he said he regret. Oh, okay. Well, something to consider for Ruby 3. Yes. So often in RubyConf we see a lot of other languages being displayed on slides and talking about other languages. I'm curious if there are any other languages that you're playing with or getting inspiration from? I'm a language geek. I love to study about the programming language in general. So recently I studied, I checked Elixir and Closure, the Scholar, what else? A little bit of a hot scale, which is kind of difficult for me. I'm not sure if it's in some streaming programming language like Pony or I don't remember them. I just read through the social, which is the Google streaming language. And we don't have implementation out onto Google. Yeah, but those kind of languages. I think we've got one last question here. Pearl was one of your languages that inspired you, some of the features in Ruby originally. And Pearl 6 came out just last year. Besides taking 10 years to come out, is there anything you can learn from Pearl 6? Actually I'm pretty satisfied that I see influence from Ruby in Pearl 6. And besides that, I'm pretty impressed by their rules, which is kind of their internal DSL to define some new syntax or grammar into the language or something. And it is a different form of the regular expression. So I'm quite impressive. It was quite impressive, but I'm not sure we can add it to Ruby. All right, well, we have 30 seconds left, so we're right on time. So I want to thank Matt. I want to thank all of you for all of your questions. And I want to thank you for a really great RubyConf. And that RailsConf COP is open right now. So time's ticking. Thanks everybody for coming. We've got social available right outside those doors. Go out there, have a good time, talk with your fellow Rubyists, and we'll see you next time. Bye.
our agenda and what logs on top of our Wiki. By question as well. Like in 2.4, the integer