 Last week I had a heavy low egg, so I'm recovering now. This is Matt, thank you for having me. This is a nice visit to Singapore. Even I had only a little bit more than 24 hours to stay. I'm going to talk about Ruby after 25 years. This is the stripped-down version of the keynote speak in Ruby Alexa Conf in Taiwan this March. Some of them might hear the talk in the conference or maybe from YouTube, but you have to stand and prepare the question for the next Q&A session. Okay, I have to put this small dongle to the laptop. This year we celebrated the 25th anniversary of Ruby. Ruby was born in February 24, 1993. This is the day I picked the name Ruby. It's not the date I released it or no, it's not the day I started coding it. I just named it Ruby on that day. So in Wikipedia, for the programming languages, it recalls the release date of the language, which is... it doesn't work. It is December 21, 1995. The Ruby project was started in 1993 and then released in 1995. It is actually as old as Java. The Java project was the original name is Oak. The project was started in 1993 and the first white paper of the Java programming language was released in 1995. So the Ruby is actually as old as Java. It's the same age. So what's wrong with it? So it just turned 25. So 25 years ago, we wanted to name it after Java just because we had the programming language named Pearl. I used a little bit of Pearl and mostly shell scripts. So I wanted to create my own programming language. The language compares to the native code is quite difficult. You have the knowledge of the platform as long as the knowledge of the native code which differs from CPU to CPU. Having overcome that obstacle, competing to the C compiler is quite difficult. So I just gave up that path. So I just created some kind of interpreted programming language so that I created scripting language because shell and Pearl scripting languages are the second most used programming language that I used in 25 years ago. And the Pearl was pretty famous for scripting language. Remember that year 2003, we didn't have the Pearl 5. So it doesn't have any object-oriented programming language feature. So I wanted the better programming language than Pearl. We have the rumor about the Pearl 5 which should have the object-oriented feature. But the object-oriented feature of the Pearl programming language is a little bit awkward, as I say. So I created the object-oriented scripting language. So we wanted to name it after Java. And we had two candidates, Ruby or Coral. But Coral was longer in one character. It should be the name of the program so that you have to type every time. But the only one character difference makes tons of types of the type in combined. So Ruby is shorter and more beautiful. So we picked Ruby. Ruby is shorter and more beautiful. And Ruby was more precious. Afterwards, we found out very interesting coincidences. The Pearl is the birthstone of June and Ruby is the birthstone of July. And you might know the font names. The real font, physical font, has the name according to their size. So the 5.5 has the name Pearl. And the 5.5 point, the next bigger font, has the name Ruby. So it is quite sufficient name for the next Pearl. The next Pearl was our primary goal at the very early stage of Ruby. I tried to make Ruby the language as useful as Pearl. And as strong as Pearl, and to be honest, we went too far. Present day, we are not the next Pearl. The next Pearl is Pearl 6. In fact, it's next to Python. Or it's following Python, maybe, in some aspect. And it is quite difficult to imagine the future. 25 years ago, it is pretty difficult to imagine the present day. Ruby is used worldwide. No way. So the prediction future is always hard. So did I foresee the current popularity? Definitely no. There is tons of programming language out there on the internet. So we have tens of thousands of programming languages out there. Most of them are very unpopular. Very few people know about the language. And they gradually disappear in the history of the internet. But in some coincidences, or maybe some accidents made Ruby very popular, the predicting the future is always hard, difficult for anybody. So it's okay to be irresponsible about talking about the future. So it's okay. I'm going to talk about Ruby after 25 years about the future. So the trend now is the scale relative. 25 years ago, the computer was pretty weak. I used the Unix workstation, which is very, very expensive. But still, the power of the computer is pretty much weak. Maybe 100 times weaker than my laptop. It's quite... The first Unix workstation I worked with, I developed Ruby 25 years ago. The CPU was the Motorola 680K, 68K. And the memory was, I don't remember, a few megs of memory. And the hard drive was 180 megabytes of the hard drive. It is nothing compared to the present days. Well, everything is getting bigger. So we have the telebites of the storage in my laptop. And in the server, we have, I don't know, the petabytes of the storage collectively in the data center. And the memory was the one... Maybe one cost has 64 gigs of memory. It's far bigger than my hard drive back then. So everything is getting bigger. The data size is bigger, traffic size is bigger, program size is bigger, and the team size gets bigger. So we have to fight with these sizes. So this is how we work on Ruby 3, the next major release. It's kind of our fight against the future. We have three major goals. The performance, concurrency, and the static analysis. The performance. Performance is pretty much important for the language. Of course, Ruby is slow compared to, say, C++ or Java, because it's interpreted. It's run on top of the virtual machine. But no one complains about the faster Ruby. So we enjoy the productivity of Ruby and the succinctness of the programs. But still, if Ruby runs as fast as C++, that's okay. So if Ruby runs faster, we process more data, or we process more traffic so that we can fight with these sizes. And then these days, the performance of the single core would not be improved because of the limitation of the mobile as well. Because the circuit in our CPU is so teeny so that if the Intel company designs wrongly, the chip will be burned. Too many heat there. So they have to put many cores in the chip. So that means we don't have the faster core. Instead, we have many cores in the chip. So that we have to utilize the concurrency to accomplish the performance. So utilizing these many cores, we can handle more traffic. And then by providing the way to strut static analysis of the program so that we can fight against the size of the program, the size of the team and the size of the software is getting bigger and bigger so that to fight against these sizes, we have to provide better way to find bugs and the tests. So the performance and concurrency in the static analysis is the three major key to the Ruby 3. So by performance, we have the project named the Ruby 3x3. So that means the Ruby 3.0 will be three times faster than Ruby 2.0. Let me explain a little bit about that. So that we are not going to have the big jump toward the Ruby 2x and Ruby 3.0. So that we are adding new features to Ruby 2x. Like we have added new garbage collector to Ruby 2.2 or maybe we added some kind of incremental garbage collector in Ruby 2.4 or we had added some kind of the JIT compiler to Ruby 2.6 in the current version so that we are going to release this Ruby 2.6 in this December, coming December. So that means that you will enjoy the JIT compiler next year, and it is. Or you can try it right now by downloading the trunk, the very bleeding edge version. So the performance will be improved every year. So that compared to Ruby 2.0, Ruby 3.5, the current version, the recent version runs, I don't know, 20, 30% faster and then consumes, I don't know, many times fewer memory, less memory. So that we have improved that much. So that we want to measure this kind of improvement into this kind of 3x3. So it's not easy, but we need the difficult goal. Like, you know, the President Kennedy in 1963 so that he made some kind of announcement to bring human beings to the moon and then at that time of the year 63, it is nearly impossible. But he declared, we go to the moon, we go to the moon. Because it's not easy, it's easy, but it's difficult. And it's a huge technical challenge. But by having that kind of goal, in July 1996, the three people went to the moon and they're standing, walking on the moon. I didn't realize I said 69. 96? I'm sorry, 69. July 69. Oh, yeah. I remember I watched that on my TV and most of you haven't been born. Anyway, this kind of goal is Ruby 3x3. And by having goal, miracle happens. And then last year, a guy named Vladimir Makalov, who is from Canada, who was born in Russia, he is employee of the Red Hat, and he's in charge of the development of the GCC for the last 20 years. And he's the very expert, nearly genius, of the compilers. And in Rubik's Eye 2017 last year, and he presented about the MJIT, which comes with the RTL, which stands for the registered transfer language, which is the technology behind the part of the GCC, and MJIT, which stands for the method jet. So it is kind of silly, though. It is a jet compiler. That means that MJIT generates the C code into the file corresponding to the Ruby programs, Ruby methods. Then it kicks GCC or Cclan to compile these generated C files, then rolls those five compiled functions by the DL open dynamic loading, then run it as a native code. It's kind of a silly idea. And he implemented that. And it did run fast. So then he implemented the just-in-time compiler using GCC in the realistic way. It was, yeah. Actually, I was joking. We discussed about this kind of approach. We just gave up. It's kind of silly, but he was serious, and he implemented that. I was so impressed. It's compiled by GCC. But one drawback is he implemented a new virtual machine, a whole new virtual machine. RTL itself is a sign of the registered-based bytecode, so that he implemented the virtual machine and its compiler. And the big problem is the big jump. So replacing the virtual machine and the compiler at the same time is too huge so that it is quite difficult to debug the things, so that it is, you know, the... HisMJet runs some small Ruby's programs very quickly, pretty fast. But it doesn't... It couldn't compile, say, Rails programs. Rails application is huge as a whole, so that it's too big, so that it was hard to be stable, and it was hard to keep compatibility. So the other guy, Takashi Kokubun, implemented the MJet, which is replacing RTL by the current virtual machine bytecode. So that it's not fast, it's workable. So that the current tree, he is working on improving that, and we have tons of rooms to improve the performance. So that next Christmas, you are going to have the Ruby 2.6, which comes with the JIT compiler. You don't expect the performance yet, but then we have tons of rooms to improve it, so that in the future, we have a lot of chance to improve the performance. Then, so that, you know, Brad, who originally developed MJet, so that he, you know, the part of his work, MJet part, the compiler framework, the JIT compiler framework was taken, but we have to give up his very important RTL part. So he tried again in this Ruby conference this year. He came back and he, which one? Okay, I made a mistake in the slide. Okay, let me see. We will see the JIT in Ruby 2.6 next Christmas, and then you can try it with the dash-dash-jit option, so that you download the trunk version, so you put the dash-dash-jit, so that the JIT compiler will work. And a very simple software, like the native naive loops runs pretty fast, but in a complex program like Rails application, well, okay, it already runs somehow. And yeah, and Brad came again, I'll try it again in RubyKai 2018, comes with the new technology like the Mio, which stands for peace in Russian. And then that means lightweight JIT. So in the very complicated language implementation, like the VA or maybe the Firefox JavaScript implementation, it has the many layer of JIT, so that he has the lightweight JIT. And then, yeah, the problem with the MJIT is that it is very heavy to compile everything by invoking C compiler, so that we try to reduce the burden, but it's still heavy compared to the built-in JIT compiler. But the Mio is very lightweight JIT compiler, and then it only supports the X86 and ARM, but it is quite lightweight so that you can build M. And then it is not fully optimized, but it runs anyway, so that compile time is 10 times faster than MJIT. So that maybe we can have Mio in the future version of Ruby to implement the more lightweight, more faster Ruby. So JIT is not panacea. It improves the CPU intensive task, but if the bottleneck is not CPU, it doesn't help it. The performance at all. So that don't expect too much. So I don't say that every Ruby program will run very fast using JIT, but the CPU intensive task like LOOTS or maybe some of the text processing things will be very fast. Well, maybe if the bottleneck is the database connection or maybe network, it won't help. Okay, concurrency. As I said, concurrency will fight against the traffic size and we have the multi-core and many-core these days and the multi-taskings. The multi-taskings is over-evaluated. For example, the Node.js claim to be very fast, but it's single-threaded. So we might not need the real multi-threading in many cases, but at least we have some kind of the CTU intensive multi-tasking. So in that way, the real multi-tasking will help. So we have a language named Alex, which has the very concurrent virtual machine or maybe we can have the multi-process up to put up everything, every multi-tasking into the operating system like the Linux or maybe the Windows or something. So these kernels can easily handle the multi-processing. So the bottleneck of Ruby programming language is JL, which stands for the giant interpreter block. Which is the Ruby basically runs one thread at a time because of the safety-ness. What? Because of the safety-ness. You know, the thread shares memory, the thread shares object and the status so that with multi-threads accessing the same object at the same time, it's quite difficult to keep the consistency so that to keep the safety so that we need to have the giant interpreter lock so that it is quite easy to remove the giant interpreter lock by modifying the few lines of code of Ruby virtual machine but your software will probably crash. The zero is for your safety. It's safer, but it's slower. So we have two ideas. One is the autofiber. As NoJS did, that's so that we have for IO intensive works that we have the very quick context switching is required. So the fiber is much lighter than threads and it's much easier to understand. So autofiber is the IO context switching by IO and it's still the fiber. So that its overhead is much, much lighter. For the CPU intensive task, we are going to implement the guild. The guild is the little bit different abstract of concurrency. I'm not going to tell you about the detail but Koichi Sasada, who is the VM guy is in charge of it and he's the diligently working on it. So we can probably by using this kind of high-level abstraction we can go even further, say cloud-based FAS, which stands for the function-as-a-service things. So by using this kind of the guild stuff you can build up the very efficient Ruby function-as-a-service or maybe highly distributed tasks. Static analysis. Oh, it's almost all the time. The Ruby is optimized as the small teams. Consize abstract of flexible. But after Ruby on Rails, the software is getting bigger and bigger. The Ruby on Rails itself is dramatically the development by providing web abstraction but abstracts view of web development. But abstraction is the key. But as a team gets bigger, a code gets bigger. It will be harder to maintain. Then the people require static typing like two JavaScript people approach the coming rays of TypeScript or something like that. But I don't like that. Because the static typing is not dry. So that if a programmer works with the types, so that we should not be able to omit, we should be able to omit them. I don't know this and things, but I'll forget about that. So that the types is the key, but I don't want to write something and type the question of things. It's redundant. So the guy named Sotaro Matsumoto he challenged static type inference in Ruby in his PhD paper, but he proved it's nearly impossible. After his graduation, he tried twice and failed. So the type inference, the traditional type inference does not work for Ruby. So his new challenge is named STEEP, which does not infer types most of the cases, but STEEP requires type description files like a TypeScript does. So imagine .d.ts file, then STEEP 6 type integrative. There are two ways to provide type description. Type description file and the comments. I'm not fully satisfied with it. It's still redundant. But the future is also... But providing this type description file, I think we can extract this type description from YAR documentation or maybe type inferences or the runtime type aggregation or the abstraction interpretation, which we call it AI. Ruby generate the type information from AI. Yeah, sounds nice. Runtime type aggregation means that you write tests, right? Yeah, and then you run tests, right? So by running tests, you have the type information of the method of the class and then once we run the test correctly, after gathering this type information, you can generate this type information to the type description files, so runtime type aggregation. Or maybe if you have some free running software by virtually tracing the runtime call path, so that you can gather the type information, basically, which we call the abstract interpretation. So by evaluating these abstract interpretation, you can gather this type information. From that type information, you can generate the type description. Once you have type description files for every method, every class, so that you can have the static type check using the technology like Steep. So that that means without writing any type annotation to your code, so you can statically check the type of your software. That would be nice. So at the beginning of the Ruby 3 project, this is kind of like the dream, kind of impossible dream, but having research, having experiments, so now we have these great things, including JIT compiler, including the higher concurrency abstraction, and these type referencing things, we call it type guessing, because by using the term type inferences, the type theory people will be getting at, so that we call it type guessing. Anyway, this kind of static analysis is nearly possible in the future, maybe the year or two. That would be wonderful. So we will have the Ruby 3, the performance will be improved by using MJIT and other technologies, and concurrency in the Guild and the Art Fiber, and the static type analysis using STEEP and other software analysis things. So that would be great. So we will have Ruby 3, it will be the continuous evolution we will have, so that remember, so we will continue the incremental development, so that we are adding features by year by year, Ruby 2.5, 2.6, 2.7, so that we are not going to have some kind of big gap between the Ruby 2 and Ruby 3, so we are not going to have that kind of gap between Ruby 1.8 and 1.9 or Python 2 or Python 3, we are not going to have that kind of big gap. So just we keep improving the language, the value, the keeping the compatibility, so that we are not going to have that kind of compatibility hell again. So it's kind of the division of the community, so that some people keep using the old version, some people keep using the new version, so that the half of the community stays old version, giving up the new technology, new performance improvement, and new functionality or anything. So that kind of things, we are not going to see that kind of situation never again, so that it's out of time to say. So our goal is help us accomplish great things with simple Ruby code, and simpler, safer, and more enjoyable. So 10 to 70 years ago, Ruby was hot. Everyone was excited about the new technology named Ruby. Actually, it was not really new though. But anyway, 10 to 70 years ago, everyone was excited about new technologies. But these days, no one is excited about hearing about Ruby. Okay, Ruby, I know Ruby. But the Swift is new. Or Rust is great. Yeah, that's true. But still, we are keeping improving the language. We are trying to keep Ruby great. So Ruby is great, I believe. Yeah, you agree? Yeah, I'm forcing you. Ruby is great, in a way. It's not hot, but it's great. And we try to keep Ruby great. And then improve it. So it's applicable to not only web, or maybe to the DevOps things, or maybe to the embedded field, or maybe in some kind of general programming language, or even to the research computing, or the data science things. I know there are more popular languages in those fields. But by keeping compatibility, by keeping moving forward, Ruby can be applied everywhere. Unless other factor happens, I want Ruby to be your first option of the technology. I spent too much time, I guess. In Intel, the profile says, only parallel survives. There will be a parallel to survive. So the language comes in the goal. We had Fortland, we had Kabul. These languages still survive. But no new programmer enjoys learning these languages because they're abandoned ancient programming languages. I don't want Ruby to become like that. We will do everything to survive, to keep providing values. To make programming fun again. Thank you. We will open the floor for questions. If anybody has any questions. Hi. So these issues, these tasks to improve performance, improve concurrency, these also happen for other languages. Do you keep in contact with other programming language creators like Widow, Faro, Zoom, or any other? No, recently. I have met Guido, Lolliwoll, or maybe to the last month. But it was more than 10 years ago so I haven't talked with them recently. Okay, thank you. Actually, it's a fun story. In the Office of Convention held in Portland more than 10 years ago, we had the language designers' lunch. Or Lolliwoll organized the language designers' lunch. The Lolliwoll there, Guido was there, and I was there. We talked about community management or maybe Unicode. Unicode was a very hot topic back then. And then one of them jokingly, if someone said put the bomb in this restaurant, the whole office of community would be suffered tragedy or something. Yeah, that's so funny. Any more questions? I think people are shy. So on a related note, how do you make Ruby continue to be relevant? Because there are different languages, new languages coming up. Do you look at the language constructs from other languages? Or how do you keep it fresh? And do you see them as competitors? Yeah. Before being the language designer of Ruby, I consider myself as a language geek. I'm really interested in programming languages in general. I like to research about the programming languages. When I saw the new programming languages, I tried to read about the materials and the reference, and I tried to write some very teeny sample code in those languages. And then I look for the source of inspiration so that there might be a chance to steal the ideas from those languages. And the language designer, I told about the language designer's lunch, so the language designer, the creators, the relationship between the creators of the languages are very good, and they exchanged the ideas. So I took some ideas from Poro and Python, and then I think Ruby has some kind of influence to that newer language, like Alexa and Groovy, or maybe some part of the influence to the language like Swift. And then we pretty much value those kind of exchange of ideas to make better programming languages. Alright, one more question. Hi, so from Ruby 2-3, you mentioned that one of the biggest improvements is going to be performance, and you mentioned that you would be hoping that it can be applied to Java, but even Java itself has been criticized as a bit slow nowadays because it's still running on the JVM, and then you have new languages like Go, which is trying to go on par with C in terms of speed. So what's your take on this? You know, the fully compiled programming languages like Go is not our real competitors. Like, you know, the Java, as having the virtual machine and JIT compiler, the Java is kind of the competitor. But you know that behind Java, we have tons of researchers with the PhD in IBM and Oracle, so it's quite difficult to compete, but we are chasing it so that we try to make Ruby fast anyway. So for the people who are very eager to seek the performance, there are technologies in the ground, which is the new implementation of the virtual machine technology, and then the Truffle Ruby is the Ruby implementation on top of the ground virtual machine, and it runs pretty fast. Actually, the Truffle Ruby runs, say, 8 to 20 percent, 20 times faster, not 8 to 20 percent, I mean, 8 to 20 times faster than the C Ruby, which is quite fast. And you know, some J Ruby people jokingly claims that, okay, Ruby on top of the Java technology runs, we already surpassed the Ruby 3 by 3. Anyway, yeah. And yeah, that irritates me a little bit, though. Anyway, using those kind of technologies Ruby runs fast, but the point is the keeping compatibility. Truffle still cannot run Rails for application, so they are improving. One of the things that I hear you saying in your last couple of answers is like comparing against Truffle Ruby and Growl or comparing against Java on top of the JVM. The virtual machine in both those cases is fairly mature and very highly performant. They're both particularly Growl designed with performance as a primary goal. Do you see the idea, in the slides, you sort of danced around the idea of, well, replacing the JVM YARV and the JIT compiler all at once is too big a jump. But how likely do you think that is that Ruby over time will continue to depend on current YARV as opposed to one of the other backends? It is not mandatory to use the YARV forever. When the first MJIT came in, we tried to replace the virtual machine with the IoT LVM, but the keeping compatibility for the language like Ruby is pretty much difficult. Remember the 20... I don't remember. Some years ago, when we replaced my interpreter by the YARV, at that time, we had tons of Ruby virtual machine implementations. We had five, six of them tried. Everyone but one YARV was failed. The YARV stands for yet another Ruby virtual machine so that we have the handful of other Ruby virtual machine implementations at least attempt. But the implementing the compatible virtual machine is quite difficult. Only one person succeeded so that I try to replace it. So that if there is a chance to have the RTL to become the matured compatible virtual machines, we'd glad to be replaced them so that we have no fixed role. But probably we will stick to it mostly because we don't like Java. We don't want to maintain Java's programs. Okay. We have one question at the back so I'll take some time to get to you. My question for you as a language designer more like what kind of languages do you prefer? Those kind of languages who try to tell developers you only can do this with one way and we say this is the proper way to do this because we saw a lot of other developers who fail in another way to do that. For example, like the Golan does it or you prefer more like the Java way when we are trying to give you tools as much as possible we can give you because we trust you are probably a good developer. Other languages. It's quite difficult to name one language so maybe I have to name every language out there and the language I value most, I study most is Python mostly because our domain is so overlapped so that we face similar issues and similar problems so that we have made different decisions and we are making a similar decision or making different decisions in similar problems so that I studied many of the PEPs Python enhancement proposals or something and these kinds of things are very worthy for me as a language designer and then the other source of inspiration is say I prefer Go I'm a C programmer so I consider Go as a better C programming language or maybe the better system programming languages in that sense I prefer Go to Rust and Rust has a different approach to the system programming and I very respect their decisions but actually I myself don't want to write the big application in Rust because the type bookkeeping is a little bit tedious for me but I respect the approaches What else? I study Elixir programming language and I have communication between the creator of the Elixir programming language Joseph Alain who also is the Rust committer and actually I discussed with the design of the Elixir programming language in very early stage so that the sound part of the Elixir it reflects my opinion and then I have a lot of other programming language out there actually I like most of the programming language out there including very old ones like APL Thank you We have time for one last question Hi You mentioned earlier that you thought that Ruby might not be that hot anymore so I'm just curious what language do you think is hot right now? Aside from Ruby of course Yeah, hot programming language Okay, probably a probably a Swift is the hot programming language and it's not the language itself but the JavaScript domain is hot I guess it keeps being hot because of the generation change of the frameworks I visit JavaScript time to time and every time I study JavaScript the mainstream framework is different Yeah, so I have to relearn everything again and again Yeah I'm sorry for the JavaScript developers Okay, thank you so much for coming up We have a small token to present to you Thank you so much for coming up all the way and speaking to us Thank you Thank you Yeah, the photo sessions