 Hello, everyone. Oh, hello. This is Matt. Yeah. Great to see you. Let me ask you some questions. First time I've raised my hand. Oh. Oh, this is so cute. Thank you. Welcome to the RubyConf. Yeah, the first speakers. No, really. I don't see them. OK, there you are. OK, welcome to the RubyConf. As always, I have to start with some little bit complain about speaking, giving a keynote presentation in English. So I wish everyone could speak Japanese. Anyway, but still, I try to be nice. So it's working. Yes. There's some coined phrase like a mean-less one. That stands for... Oops. And so we are nice. And then we have this kind of stickers on some laptops. Actually, I like this phrase because that sounds like a minasan in Japanese, which means everyone. So that term shows our inclusive attitudes of the community. Yeah, that's quite a nice phrase. So it's kind of embarrassing for me. So I know me. I'm not really a nice person. Yeah, inside. So because the phrase minasan is so embarrassing for me, so I coined... The last year, you know, I coined up the words like a mean-less one, which stands for Ruby is nice, Ruby is nice. Okay, it's a generated shell of things. So it is nice. At least it's trying to be nice to you, unless you look into the source code. But this year, we don't need excuse. So be nice. Yeah, shake hands with your next person. Yeah, be nice. Yeah. Yeah, that makes me proud. Very nice, very nice. Try keeping being nice. That's the community. That's where our community shines. Ruby is no longer a new kid on the corner. A new kid on the corner. What new kids? New kid on the corner. Ruby has grown older. It's born in 1993. According to the definition of the birthday of the language. I believe for the software, it is quite important. The name is pretty important for the software because the software is the virtual entity. So the name is the only thing. We can grab that kind of virtual abstract thing. So the date I named my language, Ruby, is February 24, 1993. So it will turn 25 soon on this date. So that means Ruby has grown older. Actually, it's as old as Java. Java project was started in 1993, and Java was released to the public in 1995. Ruby project was started in 1993. Ruby was released to the public in December 21, 1995. So that Ruby is as old as Java. But recently, new language came in. For example, TypeScript, Swift, Go, Elixir, and a lot more. Some people tried to try new language or even went to, gone to new language. Some people claim that Ruby is dead. No one used Ruby. Or really. But I believe the people here use Ruby, right? So that so many people, maybe millions of people, still using Ruby and writing the numerous applications all over the world. So I attended some conferences. Some conferences have even thousand attendees. This one is so big, and we have, I don't know, 700, 800 people here. And it is fantastic. And Ruby is still alive. But if I made some kind of think possible change that breaks your software, the people will scream. So the tendency, the language designers make mistakes. So no one perfect. So the language designers want to fix those kinds of mistakes in the past. So a lot of language made some kind of fix and the incomparable changes. Like we did in Ruby 1.9. So we had a huge compatibility gap between 1.8 and 1.9. I don't regret that. But that made some kind of the community division. That is kind of trusty. And then Title II and Title III has a compatibility gap. And they suffered some kind of huge division for more than 10 years. The community suffered that kind of problem. And then the people, the PHP developers may try to create the better PHP language as Ruby's PHP 6. But they made so drastic changes so that the community did not follow. So the project was cancelled. So we don't have PHP 6. It was cancelled. So we have PHP 7, which is more modulated. It came with a more moderate change. So ECMAScript 4 has also cancelled. So ECMAScript 4 has the kind of things like the name spacing things, class things, a lot of things, but no one followed. No one in the community followed the changes. So the project was cancelled. So they restarted ECMAScript 5 from ECMAScript 3. They added classes. So they took the gradual changes. So ECMAScript 6 and 7 gradually getting close to ECMAScript 4, which was cancelled, but it took years to get there. So it's something called the second system syndrome. So we are not perfect. So we made mistakes. So we start the mistakes like technical debt. So at some point we got net and we wanted to throw everything away. Then start from scratch, which is the second system. But the very few second system runs well. It will succeed. Because the second system introduces a huge compatibility problem. So put the burden on the users. So Ruby should be stable because Ruby is matured. Ruby is run out. So if we don't keep compatibility, the community suffers a migration cost. Users are using old versions, causing community division like we did. In the past, Ruby 1.8.3 introduced a slight compatibility problem, but it crossed rails. And some part of the community boycotted the version. Yeah, it was shocked. I put my effort to create Ruby 1.8.3 at the time, the best Ruby ever. At that point. So I released it. And then at least a part of the community refused that Ruby because of the compatibility issue. Or, you know, part of the cities have the same things. So the part of the community, part of the developers, create the best languages they can imagine. But the community refused to use the new version of the languages. Or, like I said, some project was cancelled like 5.6 and 4.6. So some people leave the community for the new language. So the community is a kind of real thing. So it's a group of people, but we have no legit membership. We don't have the membership initiation of the Ruby community or anything like that. So it's non-exclusive. You use Ruby, but at the same time you use JavaScript, right? Although I don't. Yeah, you use Ruby. Probably sometimes you might use other languages like Elixir, Go, Swift, or whatever. So the membership is non-exclusive. So we cannot expect a strong loyalty to the community. Yeah, actually the Ruby community has, the member of the Ruby community has a strong loyalty, but we cannot force them to stay. So if something happens, or if some other new technology is so attractive, so people will leave. So yeah, we cannot stop them. So we need to attract community by making some kind of the breaking change. So we might push our community members away from our language. So otherwise community members go away. So in general, it is quite difficult to make a breaking change to keep our community active. But to keep our community active, if we keep compatibility, it's boring. Usually we live for more attractive languages or technologies or whatever, like a full-time couple. It's kind of contradiction. We want our community pretty active and growing to keep them active. So if we keep compatibility, it's boring. People will leave. If we make progress, if we make changes, some of them should be, could be breaking change. And then people will scream and people will leave. No matter which way we go, people will leave. Too bad. So the problem is changes. So we like changes. Like yes, we can change them. Yeah. But at the same time, we hate changes. So we have to manage changes. So there are good changes and bad changes. Bad changes? Changes that bring frustration. Right? So what kind of changes do you feel frustrated? For example, changes that make you work. No, you love to work. Changes that make you work unwillingly. So when you don't want to work, when you're forced to work, you upset. Right? So changes that surprise you. The bad change? No, you love to surprise. Don't you? Yes. So the changes that make you angry, that is bad change. So in short, changes with a benefit is bad changes. So benefit. Performance, better performance, better productivity, or the changes that make you excited, or make you joy. So benefit, the growth form, the change. Clean language is not a benefit. For me, yes, but not for you. So you don't care. You don't care Ruby's clean language or not? Yeah, basically, unless you thought the big enough. So that, you know, but making language clean or simpler is kind of the self-satisfaction of the designer. So we, I have to forget about that kind of self-satisfaction. So avoid bad changes. That is an important design principle that can be applied to your software. So forget about yourself. Make, try to satisfy your users. Try not to make your users scream. So how about the good changes? The performance is a good change. So that, you know, no one complains about the faster Ruby, right? So Ruby essentially is not designed as a fast language because, you know, my primary focus in designing Ruby is, you know, the enjoyable, satisfactory, or something like that. So that, yeah, I want the programmer's burden pushed away from humans to the computers. So I want computers to work more and humans to work less. So in that sense, so language has to be slow because so the language has to do more things. So the Ruby tends to be slower than, say, some language, the Java, C++ or whatever. But that's kind of intentional because I push these buttons to the virtual machine, to the language, to the computer. But we try to make Ruby faster. So since we released Ruby 2.0 in 2013, so every year the Ruby is getting faster and faster. In average, we have made Ruby faster by 5% to 10% each year. So Ruby 2.x, 2.0, 2.1, 2.2, and we are going to have the 2.5 this year. So every Ruby to release improves 5% to 10% each year. And that's not enough, that's not enough. So two years ago in this keynote, so I present the phrase that is the Ruby 3.3, that means the Ruby 3.0 will be 3 times faster than Ruby 2.0. So it's two years ago, it was kind of a dream. I didn't really believe it was possible, but we have to motivate us, the community, to make Ruby faster, so dramatically faster. So it has been a dream until this year. We had some new technology in mjit. mjit stands for MRIJIT. So MRI means the mass Ruby interpreter, which is not true for Ruby 2.0 any longer. So we call it, I call MRI as a theory from now on. So it is kind of a jit compiler for CRT. So the adding jit compiler makes Ruby faster. So Ruby has a lot of constraints because of its history, because of the past users, because of the capability. These are constraints, the memory usage and dependency and the portability. So memory usage means that CRT with jit should run on a smaller circle, which has 500 megabytes. It is quite small in today's standard, but it should run on this. So that you cannot consume as much memory as possible to make it faster, but at the best minimum, so the CRT must run on a smaller circle. Mostly because I was hired by a hairdresser. So jit can be turned off. So CRT without jit consumes as much memory as Ruby 2. And the dependency. So CRT should not depend on the huge CRT library. That we cannot maintain by ourselves. So we cannot control them. Third-party libraries, they may have bugs. They may not put our issues in priority. So the product may be upon them. So women need to fork it and things like that by ourselves. But the most jit libraries are so complex and so difficult to make. So we are using third-party jit libraries. So there are some kinds of jit libraries out there. So for example, LVNJIT or GNU Lightning or LibJIT. So those have some issues for the sake of the maintainability or controllable or licensing issues. So the latter two comes with the LGPL, which is okay but not ideal. So portability. Ruby runs on many, many, many platforms. So the MGS should run as many platforms as it does now. So it should run on the next OSN or macOS or Windows or sometimes. I don't know. Even older ones on the AIX and the sound noise and then on many CPUs. Intel, NIPS, whatever. So regarding those constraints, it's nearly impossible until this year that it's done by our hero, the blood, Neal and Makarov from Letpad. So who is the OSN of the Op-Enter task table, which we proved a lot in last year. So he is the father of MGS. So you can check out the current status of MGS here. The VN Makarov, Ruby, 3LPLMJIT brush. So the important thing is it is LPL. It is GCC ground and it uses method. Let me explain those things. So LPL stands for the registered transfer language. So it's a registered based internal representation. So the stack IR and the register IR is the hot topic in the implementation of the virtual machine. So the current implementation of the Ruby virtual machine, uses the stack IR, like this. Get local from local variable B, they push into the stack. Get local from the local variable C index, then push into the stack. Then up there, the plus, it took the two operands from a stack, then push the result. Then they push the result into the local variable A index. That is the stack-based IR used by Yelp. The RTL uses the registered-based IR. So the plus, the local variable B and C, they push the result into A in one instruction. So Yelp uses the stack-based IR, and the stack-based IR is simpler and shorter, and the registered-based IR creates less instruction, registered-based IR creates less memory traffic, and it's kind of controversial about the registered-based IR runs faster, and the people in the stack-based camp will complain about that. Then the block replaced Yelp by his RTLVM. This is quite the past, and he did it in a year. That's quite amazing. And then, which is as fast as 2.4? The current release of Ruby Suite 2. And then which consider as much memory as 2.4? That is pretty important thing. That means if we count of the shed, the syrupy with RTL, which is the baseline of the jet compiler, that runs as fast as Ruby 2.4, the current implementation, and it will be consumed as much memory as Ruby 2.4. So since the Ruby 2.4 runs on the smallest dinel, so the syrupy with RTLVM runs on the smallest dinel if we count of the jet compiler release. Then here we prevent the jet, so that compile those RTL to the native code. So RTLVM... RTL can be jet-compiled into C files. Then those C files are compiled to machine code inside of the .Social4G file. Then the compiled with the command line GCC and so on, or CLAN, then dynamic loaded. So which is kind of complex aspect, but it makes the implementation of jet pretty much simpler and maintainable. So the current implementation is generated in memory, then execute the output in memory. That's simple. But the baseline RTLVM, generate RTL instead of the YARP bytecode, so then execute the RTL as an interpreted way. Then mjet, generate RTL, which is the same as the previous states, then generate it from RTL, then compile C.C file by GCC or CLAN, then load.compiled.so file, then execute. So it's pretty complex, but he out-throwed most of the completion work into the worker friend. So it runs quite fast. So actually the mjet is far from completion, so that it doesn't run rails yet, but it runs most of the Ruby tests and Ruby steps, but it does not run rails yet. So our benchmarks are pretty complete. Still it's multiple benchmarks, not real world ones. But the mjet runs six times faster than Retro enablers in micro benchmarks. So then mjet comes in four times more memory than Retro. In micro benchmarks, it tends to be exaggerated, the result tends to be exaggerated. So the AutoCarrot, which is a little bit more realistic task, which AutoCarrot is the kind of nest Nintendo Entertainment System Emulator. So it has some kind of benchmark mode, so it runs as fast update, the screen update, as fast as possible without screen drawing. So in those benchmarks mode, mjet runs 2.8 times faster than the Ruby tool. 2.8 times faster than the Ruby tool. Not bad. So the AutoCarrot is the CPU intensive software, so it is pretty easy to make faster by adding JIN. Anyway, so 2.8 times faster. And the important thing is mjet consumes 1.16 times more memory, so 20% more. So 2.8 times faster with 2.2 times memory. It's quite a number. It's quite promising. So not bad. So we have clear benefit. So we are going to add that kind of improvement, which is technically attractive to the community and developers. So in addition, we are going to add a better tool set. For example, Faster Tracing. So by Faster Tracing, we are going to have a better developer, a better profiler, or we can have a better coverage. Or we are trying to make Ruby errors more understandable. For example, we recently added the Jumin Jam in 2.4, so we made some kind of typo in our software. The error message includes the right, did you mean this? What's that? Things so that you can easily fix that kind of simple typo. So these kinds of things, the tool set changes and the performance things is keeping compatibility. It's quite nice. And Mi Addition is also nice and good changes. Mi Addition rarely reflects compatibility. So adding classes, adding methods. So we are keeping doing that kind of things. So we will add convenient methods and convenient classes to the language and the standard libraries. So for example, in Ruby 2.5, we are going to add this method. Things Graphene Clusters. Which is, you know, in the past, the strings are sequence of bytes. It's quite simple. We only have the 128 characters, including the controlling characters, at most 128. But the country or culture like us has the thousand characters. So the single byte is too small for a character. So that we introduce something in the code point, which is that we can represent the thousand of the characters in multi byte sequences. Sometimes the variable lengths. So that ASCII-A has the lengths of a byte or maybe the Japanese characters have three bytes lengths or something. But it's not enough. So the people, after Unicode, people open the box of control. Name is Moji. Yeah, and Unifamily and Moji. So the parents and children. But do you know that you can't combine these things? So it used to be this character. This is one code point thing. But recently we added the centric marriage. The ladies and ladies can get together. Or maybe the guys together. Or maybe skin colors, yellow, white, black, whatever. Maybe we are going to have some blue skins. So that if you add a male character, then combine the blue skin. Okay, yellow skin. So you can have the yellow skin male emoji. So you can combine them. It isn't one character, but consists of the two code points. The combination of the two code points is called in graphene in Unicode. So we recently supported Unicode 10 in Ruby 2.5 so that we have to handle those kind of combined code points in the graphene. So if you want to split up the strings according to the graphene, you have to use the graphene, I mean the graphene clusters. And we also added the strings, each graphene character, each graphene cluster so that you can have each graphene cluster at the same time. So that's quite complex though. There's no clear difference between good and bad in some cases. So we have some kind of controversial changes in the future. So I'm going to introduce some kind of controversial changes we are somewhat wondering if the future would be enough. So for example frozen string letters by default. So some praises, oh thank you, some nods. We have benefit, it's faster and we don't have to generate the string object for each string literal reference. So it's faster and it consists less memory. That's a good point. And also making string frozen, you can find some kind of errors very early. But we have disadvantages, like it's going to be uncomfortable. So it would break some code or many code. So for example in Ruby 2, Ruby 2.2, we introduced some kind of magic comment which is the frozen string literal, true. So that makes the string literal frozen if you specified it. And that breaks your software. That breaks your software. That broke so many software. So I'm not sure how much of you freeze or not after seeing that kind of errors. So that's one thing we are wondering. Many things sound nice but introduce some kind of that. So real keyword arguments. So right now the Ruby keyword arguments are somewhat fake. Because you can specify the keyword argument like this. But in reality, in semantics, this is a kind of like this. So the hash table at the end of the argument list. Which is the real semantics of the keyword argument. It's called in size. It makes language simpler. But the implementation or semantics of the keyword arguments, very complex. So making a real keyword argument to the Ruby. It makes Ruby simpler, faster and smoother. That's the thing. But it will be incompatible. It will break the software. Especially C functions. We are considering adding pattern matching to the language. As function language has. And then, yeah, the problem is we are lacking the characters and syntax. So we have no idea what kind of language we are using. Or tail call optimization. Which some language has. So it will make some Ruby programs faster. And there are no recursion limits. And then we have disadvantage for tail call optimization. Which is confusing backwards. Because the tail call removed the call site. So the back trace will be reduced from the actual call site. Or we are trying to investigate in the automatic concurrency model. So Koichi, who is in charge of the Yelp. The working on designing something in Guild. So the benefit is clear. So by adding that kind of new, better concurrency model, we can be multi-core aware. So you can utilize the multi-core. The recent computer has. But we have disadvantage as well. So adding. We are not going to remove threads. So adding new concurrency model along with threads has two concurrency models in the language. And it makes the language more complex, more less understandable. So we are researching on the static type analysis. So by adding that kind of static type analysis, finding more errors in our time. Which is good. But it makes the language more complex and less flexible. So for the up-to-date research, so we have tomorrow before lunch, Python Ruby programming language session in room argument. So whatever room by a social model. We share our family name, but we are not aware of this. Yeah, Masmode is pretty common family name in Japan. So there's no clear decision in those changes. So we might add them, we might not. Not clear. So we have conflicts right now. So good things and bad things at the same time. So we might take the changes for the sake of good things. Or we might abandon the changes for the sake of bad things. So the design of Ruby language. I am fully responsible. I am a lead designer. Every language change requires my approval still. After 25 years, I am responsible. So blame me. But at the same time, I am not an expert of everything. So I don't know, I know a little about the concurrency for example. I know a little about web applications. Yeah, ask the HH. So that means we need to hear from you. Because Ruby is a tool for you to write software. You are an expert of your domain. Not me. So don't ask me for the guidance of your domain. But I'd like to ask you about your domain. So no more one entry. No more avoid one. So the strategy is here, minimize the impact, maximize the benefits, and form agreement. So the minimize impact is the emphasize compatibility. That strategy works most of the time. So that I try to minimize the impact of the upgrading. So we try to allow you to safely upgrade to newer versions from say 2.2.2.3 or 2.3.2.4 or even 2.2.5. So yeah, it's a responsibility about your technology. But at the same time, it's over. So we have to sometimes make breaking change. So for those kind of breaking change, we have to maximize the benefit. And the clear language or simpler syntax or something is not among those things. So for example, Ruby 1.9 introduced some breaking changes. But at the same time, Ruby 1.9 runs 3.2.5 times faster in libraries than Ruby 1.8 due to the new version machine. So the Ruby 1.9 has a clear benefit of the performance. So the people, gradually, it took time. Unfortunately, it took five years. But the gradually community have said that can change with the clear benefit. Or the third strategy is form agreement. Yeah, for like Ruby on Rails. Yeah, they made breaking change all the time. But yeah, as I've heard, so the web technology is changing so quickly. So if they took the conservative strategies, they left behind from the up-to-date technology. So they try to make the breaking changes and the up-to-date technology. So yeah, if the community agrees with it, that's okay. But the technical language is pretty mature of the domain of the computer science. So I don't think we can form that kind of agreement for the languages. Yeah, but we try. There's no clear-winning strategy, so we picked the best strategy for each changes. So we need more input from you. Time, place, and occasion. So time means our release schedules. So as you might know, we release the new Ruby version each year on Christmas Day as a Christmas gift from the community. So that means from January to August, we discuss about the new features, new technologies, new implementations. Then September to October, so we release candidates. Then in November, we freeze the features, so no new features after November, so that we just expect. So that we have those kinds of time frames for the new version. And there are places, so we, on the internet, so we have the site, which is Rubylang.org, which is our issue tracker, runs on Christmas. So that we can discuss about the new features, bugs and proposals and things. So that if you have any ideas, proposals, feel free to submit issues on this site. So that we can discuss about that. And then, yeah, I'm sorry that I have to refuse most of them, I'm sorry. Yeah, mostly because, you know, the consistency for, you know, constraint for some just redundant ideas. But yeah, you have to send that. But besides that, we have the, we have had a lot of value input from those kind of proposals. So the last five years, most of the Ruby improvement progress had come from the proposal from the community. So I'm pretty glad that. So I still am a lead designer of the language, but the ideas of new changes, new features, a new improvement most of them came from the community. I'm proud of that. So the occasions, so that by looking at our wiki, so we have the Ruby developer meetings each month, face to face. So in Tokyo. I'm sorry. But we are talking about the, you know, the richness of what we discuss and what we are going to discuss in English so that you can see what we discuss and you can propose what to discuss in the meeting so that sometimes we forget about the discussing and your issues. So that ping us by writing these week pages so that, okay, you, I submit this nifty proposal but you don't pass them for a month or two so that what do you think about that? That kind of ping things can be done in our issue trackers or on the week pages. So that you can even proceed me to writing down to the wiki page so that it's a community effort. So the term language designer no longer means I design everything. So instead the community design most of the language then I make decisions. So the definition of the designer has been changed for those years. In summary of this talk so there are good changes about the changes in design. So every design. Ruby design, of course, your application design, your framework design, your library design, every design, that's a good change about the changes. You have to manage your changes. So that we try to maximize the good changes and the minimizing bad changes. We need more input from me just because the Ruby is for you. It's original for me. So I just wanted to create my own programming language. Ruby was originally designed for me myself so I'm split selfish. But for those years so many people use Ruby, love Ruby, the right software in Ruby so that Ruby became your language. That means we need more input from the community and from you to reduce my mistakes. So, by the way, this is the end of my talk. In addition, we are going to... I'm going to introduce the new Ruby 2.5 so that Ruby 2.5 has... Ruby 2.5 relatively minor release so that we had added some kind of top-level console lookup. Like in the past, string, column, column, strings no meaningless difference works as a top-level string but we have been removed. Then the backtrace, if you make errors so that you see the backtrace in the software so that the backtrace order is reversed. You can put the rescue else inside the do block and we added the ill self method. Some desperately need that. We supported the Unicode 10. We have improved the performance, the music has been written, and the faster block passing and the tracing instruction is reflected from scratch. One more thing, we are going to celebrate Ruby 2.5's 20th anniversary on February 24th, 2018 so that we are going to have some kind of the celebrated party in Tokyo on that day but not many of you can attend that party in Tokyo and the attendees is one of the people maximum so that it's too small. So we are going to have some kind of the virtual event so that you tweet your memory, your inspiration or whatever about Ruby to celebrate the 20th anniversary of Ruby and tweet with this hashtag 365. I think after the birthday, we can gather these tweets and put it into one site to celebrate the Ruby 2.5's birthday and record what you feel for that day, for that year, for that week, I can know how Ruby changed her mind. So that's all folks, thank you.