 So we're going to move on to the Q&A with Matt's. We have a ridiculous number of books. Thank you to the publishers. So we have The Rails Way, Ruby in Practice, Refactoring in Ruby, which I hadn't heard of, which is cool. Design Patterns in Ruby, Refactoring Ruby Edition. Ruby in Practice, Distributed Programming with Ruby and David Allen Black's Well-Grounded Rubyist, all up here. Normally, we would do some sort of a random drawing, but we have so many books that that would take the rest of the morning. So instead of doing that, what we're going to do is give each person who asks a question the book of their choice. Yeah? I think we can let people come up. We were trying to decide logistically, should we walk around or should we let you come up? And really, if you're gonna get a book, you should have to walk at least, right? So, please welcome Matt's. So do you want to have people queue up over here? Or do you want to run down the hall? So if anyone has a question, come on up here. And we'll hand you the mic. Oh, come on. Don't be shy. You get to ask him a question. There has to be something that someone wanted to ask. You get a book. Okay, so I saw the Python talk yesterday and I left with Quargs envy. So I'm wondering if there's any plans to add real keyword argument support to Ruby? I don't think, yeah, I'm not sure what is real, but I'm real planning about if you would add anything with Ruby 2.0. Okay. That was my question. Cool. So what's the state of Ruby to Ruby on 1.9.1 or 1.9 Ruby? What's the state of Ruby? Yeah, is it going away? Are we removing it? Of what? Ruby 1.9. Ruby 1.9? Okay. I'd like to introduce you Ruby with the release manager. And she told me that she wanted to say something here. So is this, oh, this is. Rhythmically. Come here, come here. Come here guys. You gotta be staying, you're few orders. If you wanna. Thank you. My name is Yogi. I have managed the release of Ruby 1.9. Good question. Hi, I'm sorry. So Ruby 1.8.7 had a great library called Ruby2Ruby which gave access to the AST. And apparently that library isn't being supported anymore in 1.9 and I was just wondering why that was. Yeah. It's not supported just because we removed the AST from the core just because we prepared the AST inside then compare it to bytecode then we throw away the AST. So we normally keep the AST inside so it's quite difficult to have Ruby2Ruby in that way. But we are still, yeah, Ruby2Ruby is very useful. So we are trying something about keeping source code somewhere or, I don't know, transfer it to get the Ruby source code back from bytecode or something. So we have vaguely planned about reviving that, that no concrete plan yet. And it isn't okay for you. Yeah. And yeah, let me, let her explain about Ruby 1.9. Thank you. It's a pretty good question. I'm fortunate not to talk. Dozo. Thank you. I'm sorry. I'm sorry. What? Yeah. I just screwed up and speaking Japanese. It's kind of difficult to switch the language. Ruby 1.9 is gradually accepted. Ruby 1.9.2 will be the complete version of Ruby 1.9 series. The web is stable. Ruby 1.9.1, 1.9.1, 1.9.1. 1.9.1. 1.9.1 showed what Ruby 1.9.9 is. I aimed it and I succeeded. As a result, Ruby 1.9.2 will be not so different from 1.9.1, 1.9.1 at least as a programming language. Internally, as Sasada-san talked yesterday, internally, it changed more fast, more customizable, less memory, many improvements. But on the level of Ruby 1.9.1, Ruby 1.9.1 will be the complete version of Ruby 1.9.1. For Ruby 1.9.2 is just a better 1.9.1. This shows success of 1.9.1. I aimed 1.9.1 show different what 1.9 series. 1.9.2 will be complete. I will release 1.9.2 after it will pass Ruby spec. Do you know Ruby spec? It means 1.9.2 is enough described formally. So it, J-Ruby and Ruby News and Iron Ruby, Ruby and so can be comfortable to Ruby 1.9.2. I'm always communicate with J-Ruby team and Ruby News team and Rails team. So when 1.9.2 and Rails 3 are released, they will work together, fine. Ruby 1.9.2 will be very usable and stable fast. Thank you. On two days ago, you mentioned in your presentation about you had a slide that said MBM on it. MBM on it. Yes, but you didn't really talk about it. And I guess maybe yesterday, Koichi may have mentioned it, but I missed that one. Oh, too bad. Yeah, I was pretty sad, but I was tired and went to sleep. Yeah, more tall. Yeah, so I guess for me, I don't know if anyone else missed it. Really, what are we expecting with MBM and how is it going to make us be faster? Yeah, just because some part of the Ruby core, it will be virtual machines and some libraries are not let's say, so we just need to put the global lock inside the virtual machine, but separating virtual machine, so making it object-fied and having multiple virtual machines in the process, you can assign the virtual machine into the independent thread, native paths, so that we can run the virtual machines stimulatively so we can utilize the multi-core which is available with machines. So basically, it's kind of like a process in our language, but much heavier. And so the virtual machines can communicate more efficiently than the communication between processes. So that we can use it as a multi-core and we can communicate with each other so that we can utilize the power of the recent machines. And one last follow-up for that. When is that coming? I don't know. Okay. That is a fair answer. At least not for 192. All right, that's cool. Thank you. Hello. Well, I attended the West Media talk and I left the talk a little, I wouldn't say worry, but with deep questions about the Ruby main, Ruby spec, and MRI implementation, seeing like a bunch of resources thrown at other implementations of Ruby and seeing a very little core doing all of it. So my question is like, do you have some of that worrisome about it? Is it wrong? No, I don't think it's not wrong. The diversity is very important for the language evolution as a whole. So as a community, we had to keep diversity, like having J Ruby on the Java platform and have Ion Ruby on .NET. At the same time, a little bit about the lack of resources. We have limited resources as a community. It will be a community. So we need to distribute our resources into J Ruby people, J Ruby and MRI and Ruby and so on. So just sometimes we lack the precious human resources of the people who can work on the Ruby internals. But still, I think it's better not to restrict anything to keep diversity. Rather, I often have the community and invite more people from outside of the community. Thank you. So I think that next year at RubyConf we should have a class where we should teach on Japanese for programmers so that we could learn how to say things like you know, Ruby is both a functional and an object-oriented language. Because I've met a bunch of people here this weekend who speak some Japanese, but they don't know how to talk about programming stuff. Yeah, probably Alan Patterson could do. I think that would be awesome. I'm always curious what in Ruby you would take out if you were redesigning it again? If there's anything in there that you wish you hadn't put in. Yeah, everyone asked that question and it's quite tough for me. But you know, I have several answers, but here's the new one. One divided by two would be, yeah, one and a half. Yeah, half, 0.5, or that's rational. Yeah, two, two, two, one half. Excellent. Excellent. You ready? One slash two equals, not zero, but 0.5 or something. Yeah. Hi. During your keynote, you talked about how you want Ruby to be the perfect language for domain-specific languages. Yet when you look at real domain-specific languages that, for example, people were showing at this conference, you can see that they had many problems with representing mathematical expressions, so they had to use either string constants, like one plus two in quotes, or symbols like colon GT and something. And do you have any plans to make it easier and have expressions in a more natural way, perhaps similar to Lincor or something like that? I'm not going to, apart from the Ruby syntax. So in that case that you have more syntax for expression, I encourage you to create the external DSL. And it is my mere wish for now, but I'd like to prepare some kind of libraries to encourage making some of the DSL as well for some kind of pausing library, adding some kind of pausing library in the standard distribution. Yeah, that would be great. Thanks. I'd like to ask a less technical question, but a more personal one. My blood type is old. Do you feel that the success of the Ruby language changed you, and if so, how? Yeah, it doesn't, it hasn't changed my internal, but it changed my external life, you know what I mean? I was paid by making Ruby for the last 10 years, and I can decide what to do each day by myself, so no one forced me to do anything. So it changed my life a lot, but it hasn't changed my personality, I hope. You know, in other words, you're living a programmer's dream. I really love Ruby. The only thing that gives me a little pain or a little bit of frustration is the adding things to the load path with the file expand path, file base, you know, DER, you know, underscore file, I mean, the length and the amount of stuff that has to be typed, and I know you've added require relative to 1.9, which helps, but are you still open to us adding underscore, underscore DER just to simplify some of that syntax, just like underscore, underscore file, but it's actually the directory that the file lives in? Did Ruby did anything? Yeah, we are planning to add it. Okay. So besides Ruby, what's your favorite language? Go language. As Ruby community is much larger now than it has been in the past, and I was wondering what your continued role in the actual language core itself is. Like, do you actually implement all this stuff, or are you just kind of taking all the patches and synthesizing them? What's your main role? Yeah, my role is still improving Ruby by coding by myself, but, you know, last time I counted, I was dropped down into the fourth major contributor, so my, yeah, my priority is getting lower and lower. Yeah, but I still keep the responsibility of designing it. Do you like it less as you move down, or do you like that more kind of? You know, if I was smart enough, I can do all the stuff by myself, but actually I am not, so I need more help. Thanks. Hi. Hi. So I was curious about your take on agile process and design pattern. Design process? Yeah, and the design pattern. How did you track it? Design process. As a language designer, I need to be, I need to be conservative. Like, we are not going to any drastic change, and we all usually wait a year or so before adding some brand new stuff. And we keep to keep the emerging new idea only after it has proven by other more experimental language like what I'm saying, more smaller language. So we, as a design principle, we should be conservative about adding new stuff. At the same time, we like to, we don't want to hinder the motivation of the contributors, so we are, we are conservative, but still open for new changes. Hi. I wanted to thank you first for such a beautiful programming language that we all get to use every day. And I want to know, from your perspective, what's some of the most beautiful ruby code that you've seen? I don't know. You are cool. Any hints? Yeah, beauty is very subjective, so I don't define any beautiful ruby code that, you know, I often see some kind of the, I don't know, beauty as a something understandable. You know, it's quite difficult to define beauty. We sometimes feel beauty when we see something of first gated. So, I don't know, I'm sorry. This question is kind of building on queries earlier. Is there anything that you wish you would have implemented or included in the initial ruby release that, in hindsight, you wish you would have done? Like better concurrency stuff like actors with removing their stuff. That would be better. That could have been better. Thanks. Hi. I came here to ask a question from Japan. Why don't you introduce a list comprehension syntax like Haskell or Python into ruby? I think you don't like the syntax, but I'd like to ask the reason why do you, why don't you like the syntax? It's ugly. And it makes syntax complex. Thank you. So, beauty is subjective, but ugliness is not. No, ugly is subjective too. But for language design, my subject is the best. That's right. You've brought up go a couple of times. We mostly program in ruby, or a lot of us do all day, and you program in a systems programming language C to build ruby. What do you like about go, and what things do you not like about go? Well, I like go, just because the go is not really complex at a system program, object oriented system programming language, like something started with C, or something started with J. But, you know, I like this thing better. It has some kind of the better object oriented in system programming, like duck typing the interface, and embedding other object into structure, and I like them. I like them. But still, the things in go I don't like, it's still immature, and I can wait for a little bit. And I feel something weird about that reverse type declaration, like a variable name, pointer, an integer, or something like that. It just gets reversed from C, so I feel weird. But, you know, it's rational if I get used to that kind of format of declaration. So, I like it. Maybe sometimes I rewrite the ruby in go. Oh, that bad point of go is the name. I like the name, but it's quite difficult to Google. What direction would you like to see the community go? Like, where do you see us ending up in five years? Yeah, after five years, I attended Ruby conference 14, and I want to see everyone smiling. So, the current stable release of Ruby is 191. We're rapidly approaching 192, and all of the developers that I know are developing on 1.8.6 and 1.8.7 were deploying to 1.8 series Ruby. When should we stop doing that? Why are we doing that? I think I've cargo-culted the version of Ruby. I don't know. Yeah, so we should be deploying to 1.9.1 now? So, at least the 191 is very... The rest of it is stable, even comparable to 1.8.6 or 1.8.5 or something. So, when you start the new project from scratch, you just can try 1.9.1 first to see if your critical gems are available or not. So, that's really the deciding factor is whether or not the libraries that you're depending on are compatible. Right, right. As long as the recent 1.9.1 pass level is quite good enough. Okay, great. Thank you. So, just try it. Okay. Can you talk about the future of performance in Ruby? Faster. By JRuby or Rubinius or even Yao. Since JRuby is very conservative about the C extensions, so it's quite difficult to make it even faster than something like Rubinius. But we're trying, and we have a lot of things we can do yet. So, like adding some kind of JIT stuff by using LLVM or other libraries or like a ZLVJIT, we can even try some kind of inlining or the tracing JIT, and we can improve the somewhat garbage culture. So, I think there are plenty of blooms that we can improve the performance of JRuby, so we will keep improving the performance. Koichi is the performance guy, so he will do anything to make it faster, and I will help. There's a follow-up question. So, there are a lot of patches floating out there, which make Ruby faster for some applications. Pardon? There are a lot of patches for Ruby that make it faster for some applications. The simplest one would be just increasing the threshold for garbage collection. Is there a plan to integrate some of those, possibly in some modified form into the mainline interpreter? Yeah, we will try some of them, just because... You know, the most famous patches is Ruby Enterprise Edition patch, which is a copy-on-write friendly GCE, which slows down the other environments, like a desktop application or scripting program. So, we just cannot merge in... Unlike Ruby Enterprise Edition, the plain Ruby is not web-simpling, so we cannot merge in the garbage collection that only works well with web applications. So, we were planning... The basic guide is taken, so we are planning to make it work well with non-web applications, but until that, we cannot merge in the data. Rob will be the last question, by the way. My question is, what's the difference between building and designing a language versus building and designing an application and what skills lend themselves to one or the other? It's quite similar. Designing a language is kind of similar to designing APIs. Imagine the way that is used, and designing the syntax and the pattern of the usage, and I imagine the face of the users. It's quite similar. But since languages use more widely, so we have... Language designers need to consider a little bit more things. Can I just follow up? What are these other things that they have to consider? I mean, is it just the API, or is there more to it than just that? You know, for example, when you design some database API, you need to consider the accessing data but when designing a language, the language might be used in web application, might be used in the scripting program or even on the program for supercomputers, so we have to consider the various situations that the language would be used. So I've also been intrigued by Go, lately. Go. You brought it up in your keynote. Can you... Well, particularly Go Routines and Channels, and its support for concurrency. Could you talk a little bit about plans for that type of concurrency support in future versions of Ruby? You know, the concurrency support for Ruby is right now, it's Fed, and which is quite difficult to control. You know, you have non-determinist behavior. So sometimes, like actors, are much better in the aspect of designing the concurrency application. So in the future plan, we provide some kind of more abstract concurrency feature on top of threads or multiple VM or fibers so that the ordinary programmer does not need to touch the very lower level like threads. So keeping the concurrency abstract is our future goal. Great. Thank you. Hey, Matt, a couple of years ago when we hit 1.9, it used to be that the 1.odd was a development release and the 1.even was the stable production release. Yeah, I still doubt that. You weren't ready to go to 2, so you went to 1.9. So in five years, are we going to be at like 1.9.9.0.0.0 something or when will we be ready to make Ruby 2.0? Well, first of all, when 1.9.0 came in, so I changed the version scheme which is the 1.0 should be the development version and 1.9.1 is a stable version. So I changed the version scheme. So 1.9.2 is not development or unstable version. So that we will have the 2.0.0 that would be a development version and when we have 2.0.1, that should be the stable version of the 2.0 series. And that will be when or conditioned on what? That's an important question. Right after we release the 1.9.2, I will start working on Ruby 2.0. So I will promise that. I will not promise when it's to be released. No, we... Is one of the conditions of or one of the limitations you felt going from 1.8.1.9.2 is are there things that you expect to not be backward compatible between Ruby 2.0 and 1.8.1.9? 1.9 would be introduce somewhat incompatibility. Yeah, right. So that's why we put up the ritual. But that incompatibility would not be big as big as the gap between 1.8.1.9, much smaller. All right. I would like us all to give a round of applause to Matt's.