 I'm going to introduce a man who needs no introduction, which seems odd. But I'd also like to do a couple of things. One is in the previous years, we've actually done kind of like sit-down, fireside chat, Matt's and I for Q&A. Because Matt's doing his keynote at the end this year, we're kind of going to do the more traditional Q&A. So we'll have some handheld mics and we'll kind of do some lineups on the side for people who want to ask questions. I've got some questions already seated in the old noggin. If no one gets up to ask questions, but I really would love for y'all to stand up and actually ask questions. So towards the end, as Matt's finishing up, we'll have some volunteers out with the mics. You'll find them, they'll sort of be in the aisles as per usual. And the other thing that I would like to do is give Matt's a little present. So a long time come Rubyist, who's actually not here this time, just coincidentally, is Bruce Williams. He actually did all of the design for a long time for RubyConf. And he recently started a very strange hobby. Recently he started gem cutting for fun. Which is like, he really wanted to just hunch over a diamond bit for 14 hours at a time, staring at a tiny little rock basically. But he loves it. And he wanted to make Matt's a Ruby. And so he did. So he sent it with us and he asked me if I would present it to Matt's on behalf of the present from the Ruby community. The plan originally was to have a nice display box. We actually didn't have time to get the display box. So we're still working on that and we'll get that to Matt's. I'm actually going to be in Japan in about three weeks. So I might bring it to him then. So it is an actual Ruby. Matt's, if you'd like, you can show it off to people later on, don't lose it. Bruce said that he was hunched over his machine for 14 hours at a time, cutting it. It's a very hard rock stone to cut. So I wanted to present you with that. It's been a wonderful having you here at RubyConf. So it feels like we're doing these forever now and we love, we want to keep doing them. So we thought it was a very nice present. And that without further ado, Matt's. Yeah, thank you for the present. Hello. Matt, who is the first timer? Raise your hand. First timer of the conference, right? We have many, the first time of the conference. Yeah, raise your hand. Who first saw my face? In real, you know, face to face. So, yeah, somebody, yeah, some, yeah. Nice to meet you, nice to meet you. Good to see, good to be here. I'm Yukihiro Matsumoto, or Matsumoto Yukihiro in Japanese. And of course you don't read this. And then I had the name in my Chinese characters. This is my name in Chinese characters. But these names are pretty difficult to remember. So just call me Matt. I am Matt. I'm a father of four children and a dog and a motorman. So some, yeah, some often treat me like a demigod or something like that. But I'm not. In reality, I'm the creator of this universe. Yeah, maybe you don't know that. But this is simulated reality, like the matrix. So in reality, we are living that graph. No, really. But I am nice. At least I am trying to be nice. But of course, I sometimes get mad. So I feel trying to be nice, but I feel sometimes anger. So being nice and anger, there are conflicts in my mind sometimes. The anger is a very problematic or troublesome emotion. So the Ladi wall, who is friend of mine and the creator of the pro-language, like this guy, once stated three virtues of a programmer, the first, the three virtues of a programmer, the three virtues, the laziness, impatience, and hubris. Laziness means the quality that makes you got a great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful and document that what you wrote, so you don't have to answer so many questions about it. This is laziness, impatience, the anger, the anger. You feel when the computer is being lazy. This makes you write programs that don't just react to your needs, but actually anticipate them, or at least pretend to do, and hubris. The quality that makes you write and maintain programs that other people want to say bad things about it. So the laziness, impatience, and hubris all related to anger. So these three virtues makes you a good programmer. So the anger itself is not really bad things sometimes. So controlled anger is a good thing sometimes. So it could be a source of motivation. So you can safely feel anger if it's kept inside of you. So anger, the publicized anger, is infectious. So if you feel anger, so your neighbors tends to be feel anger too. So that is kind of the source of conflict, war, or troubles. And the good news is, laziness also infectious. So being nice is Ruby's great virtue. So we often use the term minus one. So that stands for Matt is nice, and so we are nice. And then they may stick it like this. Am I look like that? I often use this kind of the animation avatar, though. But I'm not an inventor of minus one. The concept of minus one was embedded by this guy. You know him? He's a Martin Fowler, who is famous for the inventor of the refactoring and the microservices and many other concepts. And he also invented the concept of the minus one. So I like these terms, not only because it is kind of interesting term, but at the same time, that pronunciation sounds like a minasan in Japanese, which stands for everybody. So be nice. Everybody be nice. Together, each other. It's the greatest virtue of the Ruby community, I believe. Yeah, actually I really like the conference, this conference, just because everybody was so nice. Not only because I'm a creator of the language, but it's kind of like a feel of same nationality. Oh, the real nationality made different. I'm a citizen of the country of Japan, and then maybe you guys are from United States, Europe, some of the other countries, or even from the space, maybe. But in spirit, we belong to the same community and the same nationality, the geek community, geek national, geek nation. So I'm the creator of the Ruby, and the lead designer Ruby. So recently, I work less for C Ruby, but I still make decisions of the language, the behavior, and the specs. So I'm also the lead programmer of M Ruby, which we have several sessions in this conference, like Ruby for embedded devices and embedded in applications. So my recent news is, last week, we have released the Ruby 2.3, preview one. Yeah. And we will release Ruby 2.3 on coming Christmas. Yeah. As a Christmas, this Christmas, you mean? Yeah. We are not P community, unless something bad happens. We have done many things since the last release of 2.2. So highlights will be that we will have several methods, including M and N over all graph V, graph V, which stands for the graph minus V. So the non-unix people will confuse about that. But the minus V option invert the behavior of graph. So using the N over all graph V, so finds the elements that does not match to a pattern. So we also added the hash with the fetch values. So you can extract the values from the many multiple values from hash. So it's kind of a strict version of hash version. We also added the numeric, positive, and negative, which behavior is very obvious. So we added the hash comparison. So the less than, equal, less, greater than, equal, and greater operators. But they're not specific operators, just because they are not comparable in the sense of, say, numerics. We also added the hash to proc method, which is go like this. So that means that hash can be a treat as a map in real map, you mean mapping, as in the block parameters. I also added the did you mean gem as a default? So did you mean, means, so if sometimes you make a typo or a name error, so the Ruby interpreter guess your intention, then ask you, did you mean size? Or you made this right or something like that? So just like Google does. It's a small step toward the collaborative programming between man and machine. Anyway, and then we have added the frozen straight little pragma, which is that we can add a magic comment to say that all the strings, all the string literals in this file will be frozen. So in this example, A equal ABC, the string ABC will be frozen, so you cannot modify it. So you don't have to make a copy each time it evaluates. So modifying the string will be error. So this is kind of incompatible. But so only if you can add this magic comment at the top of the file. So it runs slightly better. It performs slightly better. But the biggest benefit of this magic comment is we can safely ignore free request, say Rails. Yeah. We also recently added the safe navigation operator, which is similar to question.inswift and Globic programming language. But instead of question., we added amp-sand dot. At the first time, we have added the dot question. But dot question, just because we cannot use the question dot, because question at the end of the method is the valid method name in Ruby, unlike other programming language. So we cannot use the question at the first hand. So we made it reverse to dot question. But after writing some sample programs with this new operator, it was like this one, user dot question, name dot question first, or something like that. So I find out it was very psychologically confusing. The question dot and dot question is too similar to distinguish and to memorize. So I just give up. And I introduce a very new operator, amp-sand dot, and which we called Lonely Operator. Just because, look at this figure, and you can see the someone sitting on the floor, looking at the dot on the floor by himself. Now you don't forget. Yeah. We used amp-sand dot as like this. Instead of writing amp-sand u dot name, amp-sand u dot name first. So we can say u amp-sand dot name amp-sand dot first. So much shorter, cleaner, and easier, I believe. In relation of this chain, so we have introduced that dig method in arrays and hash. Which is, for example, suppose we have the data structure like this, so from, say, JSON browser. So we want to retrieve the data, the symbol users, and then number zero, but that name. So that's what we want. But in reality, so any of them can be null. So we have to data dot users amp-sand, amp-sand, amp-sand, amp-sand. But instead of using that kind of lonely operator, so we introduced the dot dig method. So for array and hash, you can dig into the chain of arrays and hash. So it's kind of shorter and easier. These are highlights of the method, the language change in Ruby 2.3. And it's faster. So in fact, since Ruby 2.0 in 2013, so we released the version each year, 2.1 in 2003, 2.2 in 2004, 2013, and 2.1.3 in 2015 this year. And each year, each version, we improved the 5% to 10% faster. So this time, we improved a little bit. Not 30% faster, not 2 times faster, but 5% to 10% faster. So it's quite nice. So this has been done by co-developers, including Koichi, Nobu, and Eric Wang, whose handle is normal person, who is far from normal, though, and many others. So the Ruby is no longer my language. So in 1993, when I had started the Ruby project, that was my language. I'm the only one working on the language, or working on the virtual machine. Oh, I mean, interpreter. But now we have many, many people, many, many programmers, developers working on the language. Many people propose a new feature and come up with a new idea, which I haven't think of. So the Ruby is no longer my language, and it's a community effort now. So I really, really appreciate to the community and the developers that right now we have more than 90 co-committees, 90 people who have the privilege to access to the central repository of Ruby, C-Ruby, I mean. So then in addition, today, I released Ruby at 1.2, and we fixed a bunch of bugs. And we improved the build process of Ruby. And it's more stable than the previous versions. But that's all. No big syntax change on anything to the Ruby. And also, I recently worked for the language named Stream, which is kind of experimental toy programming language. So you can check out github.com.stream to see how my toy is. And I say, as I say, it's not usable. It's just a toy. It's a proof of concept tool. But it exists. So this is my introduction. So the last year, I gave a keynote presentation in this conference titled, The Feeling the Shock, which means we have to keep moving forward as an open source community. Otherwise, we have to keep moving forward to attract the community, so to encourage community to work together. Otherwise, we will eventually die, just because it's the nature of the open source software community. So we need change. We need change to survive. But yes, we can. We must make changes to keep going to survive. We have to make changes. There are a lot of them to keep moving forward. But at the same time, the changing itself is a cost and a pain. So how much pain do you suffer when you upgrade Rails 4 to Rails 5? Yeah, we normally don't like pain. Yeah, I know somebody like pain, though. But we normally don't like pain. Here's the contradiction. So we have to make changes even though it has cost. It costs pain. But we don't like pains. Users don't like pains. So we like changes. We don't like pain. Here's the challenge. I'm a language designer. The design is hard just because we have to address those kinds of contradiction and conflicts, conflicting demands. And the biggest challenge of designing something is we don't know what we should make. This is the poster in the Y-combinator office. And when Alan Kaye, the smolder of fame, visited their office, it originally says, make something people want. But he striked out, want, and write down the need. So we shouldn't make what they want. The famous Henry Ford once said, if I had asked people what they wanted, they would have said faster horses instead of cars. The users don't understand what they need. So they need a horse. They need a faster horse because their mindset is fixed with the horse and the cabins. But in reality, Henry Ford publicized. He did not invent it. But he produced a lot of cars in the cheap cars so that the horses were swept away from the world. So make what changes their lives. They create something that have never existed. So in that sense, design is hard because the future is unknown. We don't know about the future. We can't predict it. We can expect it. But in reality, the future is unknown. And because the situation changed. So when I released the movie in 1995, so Sam said, we don't need the object oriented features in scripting. So Sam said Ruby was too good to be a scripting language. What does it mean? I don't know. So too good to be a scripting language. Anyway, but they were wrong. They were wrong. So nowadays, almost every language, including scripting language or toy language, are object oriented programming language except for some functional programming language. Anyway, this is the evidence that is quite forecasting or telling the future is so difficult for most of the people. I didn't ask them what they want. So OK, do you want scripting language? I will make that. This is not the way I started Ruby. I created what I wanted to see in the future. So I wanted this. I want this in the future. And as Sam didn't understand what it's up, so object oriented, we created Ruby. This is quite nice language, it seems. But it's too good or we don't need it. So for the first 10 years of the Ruby's life, very few people find Ruby very useful. The many people find Ruby interesting, but they had never said useful for the first 10 years. But I didn't care. I kept working for 10 years. So then we had Rails, the tanks of DHH, or the web age has come. So the Ruby became new normal. And then my prediction was right. We have created new normal. It's not really I created the new normal, but we as a whole programming community, and the Ruby community, the Python community, Perl community, all the open source language communities created new normal. So that kind of new normal is we can't, we could prepare that kind of new normal. So this is a secret of Ruby's success. But suppose you have created great software, but it's not the end of the development. Because the future is unknown again, and because the situation changes, the system gets older soon after created. Too bad. A system will go bigger, more complex, as the time goes by, and we will become sick of maintaining old code. We have to adapt changing situations anyway. It is good excuse to slow away code. So we have to make changes, otherwise the system eventually dies. But changing is paying, changing is cost. But the users hate paying, contradiction comes again. Contradiction often cause problems, like unfinished systems, or slow adaptation of the new system. So we have that kind of symptoms, like temptation to slow away everything. Okay, I'm sick of this system, so I want to create everything from scratch. At that time, they have illusion that we could create cleaner systems if I try again, if we try again. Or illusion that we could create system that performs better. But that illusion caused you the enthusiasm to pursue the boss. So can I make this new system? The throwing away old system, and then strong enthusiasm. So if I try this time again, so I could, I should have create better system. But design problems are harder beyond expectation, schedule delays beyond estimation, developments cost beyond budget, angry clients, project failure. Ouch. This happens to slow away everything, so with a different severity. And at that time, and a lot of language, programming language suffer more often, just because the language lives longer, so that the world's first programming language is named Fortland, but it's still alive, alive. And the second programming language is Lisp. And that's still alive. The third of all this programming language is Cobble, that's still alive. So they are more than, they are almost 60 year old. Whoa. But they are still alive. So the programming language lives far more than, far longer than usual application. So that the programming language face that kind of programming, problems far more often than usual applications. Case one, power five bars of CX. How six projects started 2000? Yeah, 2000. Because they felt some kind of stuck, so the changes, the evolution, the slow down for long, long years at the time of the year 2000. So as I said, before the open source community, they eventually dies when they stop moving forward. So that is the reason behind they started Pro Six. So we have to do something new. They had to do something new. And then Pro Six inherited the pro philosophy, implemented from scratch, scratch, that is key. So they had the ambitious goals. And then they totally new syntax, totally new version machine. And 15 years has passed in this new year 2015. We don't have Pro Six yet. But finally this Christmas, hopefully. Yeah, I met a lot of you all in the last August in Tokyo in the Yacht End of the Power Conference. And where I was a guest speaker there, interestingly, though, and he declared the Pro Six, the first public version of the Pro Six gonna released in this coming Christmas, hopefully. Unless something very bad happened. Okay, probably need years to, but after releasing Pro Six, I guess it would need years to become widely used. But don't get me wrong. I respect power community. Power people are very smart. What I wanna say is that even they suffer. Design is hard. Case two. 5.2 versus 5.3. In pro community, they long had some, the dream of the something named the Pro 3000. The whole new Python, the better Python without any legacy features or something like that. So the Python 3000 design policy is a reduced feature duplication by removing all ways of doing things. So the power, I mean, Python language evolved in the history of, long history of its other language. And then in that history, they introduced the new new features that are overriding the old ones. But for the sake of the compatibility, so they have to keep old features, old design, old class, old behaviors. But so the core designers, at least, do not like those kind of legacy behaviors. So they wanted the chance to remove all the reduced duplications. So they wished they could release it before AD 3000. That's why they named it Python 3000. They discussed for years and then they finally started their project in 2006 and then they named it the virtual project Python 3000 to Python 3 and it was released in 2008. They didn't throw away old code. They improved and they removed old code. So in that sense, so they are the smarter in that sense. But they introduced a huge compatibility problem. In 2015, Python 3 is still widely used. You know, the Python 3.0 was released in 2008 and we are now in 2015, so by the Python 3.0 version is still used. Some even claim to give up Python 3.0 altogether. Whoa. But recently, Python 3.0 has adapted more widely, like compared to the two years ago or something. So finally, but don't get me wrong, I respect Python community. The virtual people are very smart, but even they suffer, design is hard. Uh, ph community, skip the php6. Yeah, they are smart. JavaScript cancels the ECMAScript 4 twice. Yeah, they are very, very smart. Some of the things happen all the time for the applications, for the systems, for the everything, including a programming language. Ruby is no exception. We had the issue where we had Ruby 1.8 and Ruby 1.9. So back then, we had the problem in performance. The Ruby 1.8 has very, very naive ASD traversal interpreter, which I wrote. That's why it was slow. And back then, the multilingualization, so handles the many, the character encodings, is an issue. So the idea of the new version of the Ruby 1.1 in year 2000, the project itself has started in 2004. And to address those kind of issues, so we into the new virtual machine, which is, which we named YALF, yet another Ruby virtual machine. That means that around the year 2004 or something, we have a lot of attempt to create a Ruby virtual machine to gain performance of the Ruby language. And then, but the writing simple virtual machine is fairly easy. It's a kind of practice for the CS students and the grad CS students. But the implementing real world virtual machine is the another story. The out of five or six attempt to create the Ruby virtual machine, only one survive, which is the YALF by Koichi Sasada. And I contacted him and I welcomed him in Core developer. And then it gradually formed into the Ruby 1.9. And the Ruby 1.9 was released in year 2007. And we had slightly slight compatibility problems. But yeah, even that, we take five or more years to be adapted. But we've done slightly better than Python 3. Slightly, but no one suggested, but at least no one suggested to give up Ruby 1.9 because of the compatibility problem. But how? How we have never thrown away everything and we have replaced one at a time, replace the string class to implement the multi-lingualization, replace the virtual machine, replace the object representation, object garbage collected. We kept compatibility as much as possible. So write test suite, so replace it, so check the test suite to satisfy the old code. So when we have to make incompatible change, we prepare the migration path. So never try to draft exchanges and then change it step by step. So the key we did to smoother, yeah, not really smooth though, but a smoother migration, we did several tricks. The first tricks is the versioning illusions, which means that Python 2 versus Python 3, the Pro 5 and Pro 6, but we had 1.8 and 1.9. That makes feel you, oh, this is nothing. No, we are little. The second trick is the migration bait. Moving to 1.9 had huge benefit of performance. So replacing it, replacing your Ruby into 1.9 outperform the old code by factor of two sometimes, maybe in the biggest case, the 50 times maximum. Well, great, so performance. So even though the migration change is pain, but if you knew, you can get the benefit. So you are, it's okay to pay the price. So that kind of benefit cause the motivation to move on. So as a rule of thumb, to create a new system, new version of language, don't throw everything. Don't push too hard. Provide you the benefit. Don't break compatibility for no reason. Now your own satisfaction, the cleaner syntax, the smaller syntax or the finer code or the debuggable, simpler structure of your program. The users don't care, but if you break compatibility, the user gives you a user the huge pain. So if you don't provide any benefit, don't change, at least from the outside. But we have to keep moving forward. So the Ruby 2.0 had almost perfect compatibility along with the Ruby 1.9.3. But as time goes by, the situation changed again and we have the multi-core. So at the time I started Ruby in 93, the old computer has only one CPU. And then at the time the project YALF had started in 2004, so the almost all the computer, at least for the personal computers, has one CPU per device. But these days we have dual core, quad core, octa core, or something, something core, the main cores. So this is a huge problem. So when we have only single core, no one cares about concurrency, just because concurrency is only for the program structure. But nowadays the concurrency is the key to gain performance. So if you split your task into two, then assign these two tasks for each cores, so it would run two times faster in theory. So the multi-core is very crucial to gain performance these days. But the Ruby itself and the YALF is not designed multi-core in mind. And the second part is called scalability. The old days the people called the object-oriented programming features doesn't need for scripting language, just because now these days the program in scripting language is only 10 lines, 100 lines, or maybe 1,000 lines of code. But these days the Rails application, including framework and the libraries, we have, I don't know, tens of thousands of lines of code or maybe the million lines of code, that's quite huge. So that kind of core scalability we have to address. Well, that scalability, we have the C-10K problem for a long time, and then we have a lot of access to our web servers. So we want to address those challenges. So we want to create a newer version of Ruby, named Ruby 3. But I say we don't forget that rule, that which is don't throw everything, don't push too hard, that provide you the benefit, don't play compatibility for no reason. So we have started working on Ruby 3, so we have no concrete idea yet, but we are experimenting ideas. Some of them are very crazy ideas. And we don't promise anything, but we do remember those rules again, don't throw everything, don't push too hard, provide you the benefit, don't break compatibility for no reason. So we are working for Ruby 3. The problem we want to address is having multi-core in the computers, the code scalability and the data scalability. So to address that, we do want to work on concurrency and the main machine collaboration and the performance. To utilize multi-core, we need concurrency. That should be abstract, simple, and easy to use. So we already provide thread, but there are threads too primitive. It's quite difficult to use and easy to make errors. And it often introduce the non-deterministic errors, so that is fixing that kind of error is kind of nightmare. So for concurrency, so we have several candidates, but we want to make concurrent programming more productive. So we have these ideas, active models, ownership models, STM, the streaming model. OctaModel stands for, you know, the OctaModel is pretty famous, shared nothing and the missing passing. It's down by the language like Euler, Euler, Elixir, Nescalar, and Go. The basic of it is quite easy, and it can be down by threads and mailbox. But the shared nothing is kind of hard for language like Ruby. So we have to address something like that. Ownership model is similar to the Rust memory model. They use Rust to use ownership to reclaim memory. We use ownership for concurrency. So only the thread owns objects. So every object belong to some thread. So when you have ownership of the object, so you can look inside of the object, you can modify the object. But you don't have the ownership, you cannot access inside of the object. So the every object is opaque. So when you pass your object to another thread through Q or mailbox or something like that, you pass ownership as well. So the target threads or target actor or target something can modify the object. But you cannot modify, you cannot see the object until the object get back to you with its ownership. Object can only be different by the thread that owns it. The pass an object to another thread or after along with its ownership. STM, I don't believe STM is a realistic solution for Ruby 3 though, but I introduce it anyway. STM stands for the software transactional memory which is embodied by the language named Closure. We can share and change states, but when there's conflict, everything rolls back. Great. But to implement this, so we have to re-implement every object system and everything which can be rolled back. So that's quite difficult. Insanely difficult to implement. So I cannot believe the Closure people that did that. Yeah, it's amazing. The STM also had a drawback which is slow write intensive programs. The streaming model, which is kind of the build data flow pipelines and pour data into pipelines. For example, in the streaming model, we introduce new operator like a pipeline arrow. Like this short program creates the pipeline from standard in to standard out. So this code only creates pipeline. Then after program ends, so the program automatically enter into the event loop. So event loop detect the input from the standard in to pass the data into standard out. So this is a simple echo server. So create a socket server socket, then create a map so that you can process the each socket from the server socket. Then connect the socket to socket to make an echo server. Okay, simple net client goes like this, creates client socket, then connect it from the standard in, then the output to the standard out, then enter into this event loop. So in this case, we introduced a new operator, this one, I don't know the name of the operator yet, that creates pipeline, then enter into the event loop. So the normal will be called that creates pipeline, then let's say the event loop, the event-driven loop. So I call it the loop global programming. So I create the pipelines, then enter in the event loop, the ball goes like this, da da da da da, or maybe okay go programming. It provides a threat safety, the object immutable. In the event loop, we have the second virtual machine runs, which treats every object as immutable so that you don't have to worry about the shared data. So we don't have to worry about the new jail, in the second virtual machine. Everything immutable, not covered 100% of the currency, but at least we need the proof of concept. So I played with the experimental language, which is stream, I name it. So the performance, we made the five to 10% faster each year, and then we have improved the garbage collector, we have improved the adapt virtual machine, we have improved the object representation, but no one complains faster, right? So we need the goal to be reached. So that we come up with the goal, which I name it by Ruby three by three, which stands three times three. So that stands for Ruby three, Ruby three times faster than Ruby two. But two data tools, I have no concrete plan. But it's a goal. We do everything we can. We can address by concurrency, better destruction algorithm or just in time compiler, or maybe a head of time compiler, not because they are easy, but because they are hard. In this decade, blah, blah, blah, blah, blah. This decade, I want to make it Ruby three, three times faster than Ruby two, in the year of the Tokyo Olympic year. Make it three times faster than Ruby two. But I lies, don't lie at the pitch marks. And we have some tricks and conscience. We will compare it with Ruby two, oh, just because we have made improved a lot in the last few years, so we want to count them in. And we will pick some benchmarks, small but not too artificial. It may consume more memory to gain performance, but it's minimum memory consumption should be comparable to Ruby two, oh. We need more power. So we go as a symbol of Ruby three times three. So that some companies are willing to sponsor us. So for example, Apfolio, and yeah, thank you. In fact, powerful Apfolio come up with the term Ruby three times three, and it impressed me a lot, so I took it as if it's my own idea. And Apfolio is willing to sponsor us about Ruby three times three. And of course, Heroku, Heroku hired small, the three main core developers. Yeah, thank you. Thank you, Heroku. And recently I've heard IBM working on the technology named J9, which can be integrated into the MRI. And they said it can run Rails with JIT, with CRuby. That sounds terrific. And I contact them so that they are going to give a presentation in Ruby Keige next month, so that I have to wait until December to know the whole detail, but I'm pretty wait for them. So maybe we could have other sponsors, so welcome to help us. So a lot of people contributed to Ruby, the community. So many people were gems, so many people contributed to the code, the pull request. And as I said before, Ruby is no longer my language. It's a community effort, but we still have a lot of things to do. So the making benchmarks, providing knowledge, and any crazy ideas to improve the Ruby three times faster than Ruby two. So I really appreciate the sessions like Ruby in depth. So the we, I knew, I know that many people are willing to help us. So there are so many things you can do to improve Ruby, Ruby itself, faster, better, so we are welcome. And we do see, so the CRuby is written C, so that you do not have to work on C, so I do, we do. So but I invite some of you who are willing to work in C and to fight with the performance, data structures, operating systems, and then very tough tasks in C and in Ruby too. So the welcome to the world of the real. So the C is very real, it's hard, but working on this desert of real world, so that we can protect many people from suffering in the desert. So if you have any idea, opinion, and the willingness, so you contact me or Paul to make Ruby better, faster. So we do, we will do, make Ruby better, faster, cleaner, more powerful, but we have less power, so we need your power, thank you. So we have about 10 minutes for questions. I hope we have questions. Please don't get up and go out yet. We still have a lot of questions. We're not done here, so I'm here and Marty's there. Who has questions for Matt? Okay, come line up right here. Nathan, you can go first. So Matt, if Ruby 3.3, 3x3 meets its goals and you get three exit performance, that means that you can do lots of things that users don't like as well, right? So do you have plans to break some compatibility or things that you want to remove from the language in Ruby 3? Yeah, in Ruby 3 we will break some compatibility, but I don't think it will be big. Just circumvent all up here. Hello, I'm Benjamin. Hi. I try to be nice to you. So my question is that a lot of the development that I do is on GitHub and I think most people here are familiar with the GitHub development flow working on large applications such as Rails and that there is a Ruby repo, but in order to truly get involved with even reporting issues on Ruby Core, I believe that it's a different workflow that involves both using the RedMind application and also understanding Japanese. Oh, and subversions. I was wondering if you could give a very brief description for everyone here just how we can even open an issue on the Ruby language itself. You don't have to speak Japanese to involve the Ruby development. Most of the discussion is held in RedMind, RubyLang.org, and for the historical reason we have developed wrong before the GitHub happened. So it's okay to create some poor requests and the issues in GitHub as well, but we encourage you to use the RedMind outside. Mostly because in our core developers we have some kind of open source fanatic. According to them, the GitHub is not really open source. GitHub is open source, but GitHub is not. So some refuse to create account to the proprietary services. So for that reason, we cannot fully move into the GitHub. But we will move into the Git, at least, and use Git as the primary repository in the near future. So we have to set up some kind of tools surrounding the issue trackers and something like that. Soon we will migrate from Subversion to Git. Will you consider immutable persistent data structures for Ruby 3? That... A closure map. Yeah. We need more knowledge. So if we could have your contribution. We have some criteria, so if that new data structure has satisfied that kind of criteria, I'm willing to adopt that. I have a follow-on question, because I have the mic. Are there any things that you've seen happen in the Ruby community in the last however long, few years, that you want to bring into and make them part of the core language? Like gems that you thought, oh, we should really make this part. Like you said, did you mean was or was not an external piece? Are there any other things that you, gems that you want to bring into the core language? Like there are some persistent data structure gems, for instance. You know, the biggest things I want to have in Ruby is something like the single binary things, like our M-Ruby CLI or maybe gold one, so that we can create the single binary, everything bundled together in one binary. So that kind of things could happen. But at the same time, I know that we have a lot of things to do to accomplish that, so we're working step by step. So not so much a question, but a reminder of a project that I did that actually had a little bit of software transactional memory behavior for Ruby, if anybody wants to explore how we might do it in Ruby itself, and that's transaction simple, for which a modification of 1.9 was made to make that work better because it used, it deep cloned everything in order to have the levels to transact. So that can give people a starting point to explore STM in Ruby if they want to play with that. I'll give a halo statue, transaction simple dash in there. I would check out. Why did you make parentheses optional in Ruby? To aspect possible. That was too good. I can't follow that. So I know a lot of people just getting started programming don't necessarily have the same hardware like computers. I think I have not, I've only seen mostly Macs here. But people getting started to have a lot of different systems. So you had an invitation for like, hey, we need more people looking into C, and I also know that there's very few people who are C programmers who also focus on Windows platform compatibility. Do you have any ideas how maybe we could increase that? Increase what? Diversity? Just the Ruby experience on other platforms. Yeah, at least we have the maintenance for each platform we support. So we have the Windows guy and the Mac OS guy and the Linux guy. And we have even the AIX guy. So we are trying to do that. If the many people are willing to help us, so I'm pretty happy. So for example, our AIX guy is pretty busy in IBM. So if they are willing to help and possess the AIX machine, that is the problem. We are very welcome to work together. Hi, I was at the M-Ruby Birds of a Feather and the roadmap for M-Ruby came up and you mentioned that you keep it in your head. Is there anything that you could sum up about where that project is headed and what the big goals are? Yeah, the M-Ruby itself has done what we wanted to provide. Basically, so as a core, we only improve a little bit. For example, adopting Ruby 2 features or something like that. So this is kind of a small problem. The issue is the application. So the many people use M-Ruby for many purposes like embedding M, say, vending machine or in the internet router or web servers or your application or maybe some, say, editor extension language or something like that. So that kind of usage is very crucial. So I want to help somebody who is coming up with the ideas so that if they need help, so we are willing to help them. So if they feel some kind of obstacle or problem issues, so we are willing to fix them or improve M-Ruby for them. Yeah, we are even micro-satellized embedding M-Ruby. So a related question. Is there any plan to bring the syntax, build some sort of correspondence between the C-Ruby syntax and the M-Ruby syntax so that we have some way of having code that corresponds in some cases? Yeah, currently M-Ruby is 1.9 compatible, so it's quite old. So yeah, it's gradually adapting Ruby 2 syntax. So the next year I'm going to work on adding the keyword argument in M-Ruby. So gradually we are moving forward. Hi, Matt. I was wondering in Ruby 3.3, what syntax are you going to use for the macro system? Okay. I seldom say promises about my software just because the future isn't known, the situation changes. But I promise we're going to have, we're not going to have macros anymore. All right, I think this is going to be our last question. But at least we, it's okay for me to provide AST from Ruby code. I just want to say I'm Paul from Apfolio and as Matt mentioned, we're interested in making Ruby faster and we're currently looking for C-programmers or people who are into VMs or have worked on JVMs or V8. And if you're interested in making Ruby faster, Matt's had my email up there. So get in touch with me and we'll see what we can do. Yeah, he's even willing to hire. I think that's a good place to stop. Let's give Matt some big hand.