 This is the keynote, the first keynote from myself. Every year I feel weird. I am a programmer, not a presenter, but the last 20 years, the things has been changed a lot. So this year I'm talking about the feeding sharks or crush on pipes. Oasis community is kind of like a shark. Yeah, in Jaws. Just because Oasis community, especially a developer's community, we have to move forward or die. Just because if you lose interest, we will go away to somewhere else, more interesting. Yet, the Ruby was pretty interesting back then, but it's quite boring. So let's move on to another programming language, framework, technology, say, whatever, no JS, JavaScript, but we have to feed the community. So we have to attract the community somehow by showing how to earn money, rails, or by enlightening people by philosophy behind the language design or maybe framework design or something like that, or by showing the future, the possible future on the technology. So I give many presentation in past RubyConf. I give presentation about the future, basically. So in the RubyConf 2001, that held in Tampa, Florida, it was the first RubyConf ever, and it was, I don't know, 30-something people were there? Do you remember? 30, 35? 35, 35 people attended the first RubyConf. Yeah, some of them are still attending this conference. So I gave a presentation about the future of Ruby. There was a virtual machine. So back in 2001, the Ruby interpreter is pretty naive interpreter of the abstract syntax tree. And introducing the virtual machine to the language will boost the performance of the language. So I give a future vision of the introducing virtual machine to the language. Then it became true in 2007 by the Ruby 1.9 due to the work of Koichi Sasada. And then in the next year, RubyConf 2002 in Seattle. So I give us some vision of the future, the M17N and the native thread and the generation garbage collector. So M17N stands for multi-lingualization. Did I pronounce correctly? Multi-lingualization. So the ability to handle the many encodings from the language everywhere. So back then, Unicode was not that popular. So we have a lot of encodings nationwide. So the people in the United States has ASCII. That's okay. English is so lucky language. And the European people has Latin one. And the people in Asian country has kind of like a nightmare. We have so many characters. So back in Japan, we have to define 6,000 characters, including the Chinese characters and the Japanese characters. So the 8-bit is too small. So back in Japan, we had at least three, or maybe four character encoding to represent the Japanese characters. And the Chinese has several ones, that Taiwanese has the others. And there are so many character encodings back. And still, they are. So the many programming languages like Java took Unicode to represent every characters. But the very early version of Unicode only has 16 bits. So that means that 60,000 characters. But the world is wide. So everyone wants to add their own characters into Unicode. So they overflowed. Now we have, I don't know, 100,000 characters or maybe more characters in Unicode right now. So the 16 bit was too small. And so we like to support many encoding natively without any conversion to and from Unicode. And then I would like to address the native threads and the generational garbage collector. That these technology became true in these ages. Multilingualization in 2007, a native thread in 2007, and the generational garbage collector in last year. The next year, Ruby code 2003 held in Austin, Texas. So this year, I gave a lot of wild and crazy ideas. And then local variable scopes and the multiple assignments if I meant keyword arguments, method combinations, selector namespace and optional static types. And then some of them became true. And the local variable scope ideas and the optional static types abandoned, gave up. I gave up. But the other ideas, multiple assignments, refinement in one line, keyword arguments in two or method combination, which is done by a module prepend is became true in 2007. And then selector namespace, which now we call refinement, is in the language in 2013. And the next year in Washington, the RubyConf 2004 held in Washington, DC. And then I missed that one. The only RubyConf I missed, regretfully. But my youngest daughter was born that that year. I couldn't make it. Instead, Brad Cox, the designer of the object C, gave a keynote at the Ruby conference. And then Koichi gave his first talk on the earth. Next year, we come to 2005, in San Diego, I present the Stubby Lambda and real multi-value and the traits. And I remember almost all members, all attendees, act against Stubby Lambda. It was too ugly or something like that. But 10 years later, so many people use Stubby Lambda instead of the L, A, M, B, D, A. So, yeah, I was right. I was right in Blanket's design. So Stubby Lambda became true in 19, 2007. And then the other two ideas just gave up, given up. RubyConf 2006 in Denver. In this year, I gave a presentation about the bike shed argument encouraged. But we discussed to nourish new ideas about the language design and new frameworks and then. So in most of the cases, the bike shed ideas are considered bad. But in some cases, like a bike shed argument, ideas are encouraged, like kind of like a brainstorming. So I didn't present any new ideas that year. And RubyConf 2007 in Charlotte at North Carolina. So in this year, the Ruby19 was introduced. But that was a huge jump from 18. So I gave an introduction about the language difference and improvement and the performance gain or something like that. So I didn't give a presentation about any new ideas. So RubyConf 2008 in Poland in Oregon, right? The philosophy is explained. The philosophy behind Ruby language design was explained. So I didn't give you no idea idea. RubyConf 2009 in San Francisco, the Power of DSL explained. So no new idea was given. At the same time, RubyKaigi 2009 in Tokyo, I gave a whole lot of new ideas, like a complex literals, the rational literals, true division and bitmap marking and symbols you see. And most of them, except true division, was introduced to the language later. RubyConf 2010 in New Orleans. So I gave up new ideas like a trace and a module prepend and refinements and the right version machine, which is later became MRB. So these ideas except mix, which is kind of like a trait, was introduced to the language. Then RubyConf 2001 to 2013 last year, held in New Orleans, Denver and Miami and boy, Miami was good. So there's new ideas. After all, some may become true, some may not. The false rate was a 32%. So I classified conferences like this. So since the first one to 2005 in San Diego, I give a presentation about exciting but uncertain new ideas. Then year 2006 to 2008, nothing new but philosophy. And the year 2009 to 2013 was improving implementation. So there are new ideas, but they're so near-sighted so improving the current implementation of the language. So there's no big deal. So we need to feel well to move on. So it's about time to start talking about Ruby 3.0. By the way, we are going to release Ruby 2.2 in coming Christmas. So we will add some new improvement to the language, still keeping the compatibility. So Ruby 2.2 will be a drop-in replacement to Ruby 2.1 for most of the cases. And then the session, Koichi Sasada will give them, talk about the garbage collectors, but he will cover some aspect of the new things in Ruby 2.2. So if you have interested in the new things in Ruby 2.2, go to his session. So I'm going to introduce the things in Ruby 2.2. Ruby 3.0 to come, that may happen in the next 10 years. So maybe we will see Ruby 3.0 in 10 years later, or maybe next year, I don't know. I have no idea. So the huge topic of the Ruby 3.0 will be the concurrency and jit and static typing. But I'm not going to talk about concurrency just because I have no specific idea about having concurrency, but I know that everyone complains about the giant global interpreter lock. So we, Koichi, is talking about, discuss about the concurrency, introducing the true concurrency, I mean the true parallelism in Ruby, in the CRuby, so I will try to make something neat in the near future. But I have no concrete idea yet. So jit, we might use LLVM, or we might use some other technologies, but the jit will boost the performance of the Ruby by the factor of 2.2.4. So not that great, but Ruby twice faster, Ruby twice faster is good for you. And static typing. Static typing? But all new kids in the street, Scala, TypeScript, Dirt, Goal, the new coming language in the 21st century, the old new language has the static typing. So the people come to see me to talk about the typing, especially optional static typing. So JavaScript can have the type with the form of the TypeScript, or maybe the ECMAScript 6. So why not Ruby? Some people might say the Goal has some kind of the static typing with the form of the dark typing. So why not Ruby? Or something like that. So it's kind of like a crash type. So we had some kind of the proposal and the bug list, a feature list number 9999 by David D'Agostino. I'm sorry. It's a proposal about the typing annotations. Like this. So connect has a stream and a client. Then it retweets the fiber or something like that. And Python, yeah, our rival. The Python enhancement proposal 30,107, which is a functional annotations like this. So it's kind of similar. And interestingly, Python does not check types, even with the type annotations. It's kind of like a documentation. Quite interesting ideas. And that from Google, it works like that. So they can declare types, but it doesn't complain about the wrong type. What is static typing? And then the Python people are also working on something named MyPy, which is the optional static type checker. So the benefit, what is the benefit of static typing? So I classified in three-fold. The performance and the compile temp check and documentation. Performance. But no one complains for faster Ruby. So by adding some kind of the optional static typing, if the Ruby runs faster, so very few people will complain. But do we really need static typing for speed? So JavaScript V8 is quite fast and LuaJet is extremely fast. And both languages, JavaScript and Lua, are dynamic type, no static typing. So if they are so fast by the technology like a Jet or a specialization or some other technologies, so why do we need static typing? So we can compress performance with dynamic type language. So we don't need static type for speed. So, but the compile temp check is very important just because, so how many times you find some silly bugs of the type error with type errors so when you forget tests? But static knowledge is pretty good. So the compile time checks can find many errors without the program execution. So it's quite nice to refactoring so you can be sure so you can be safely or refactor things. So when you change the name of the method, you have to change every occurrence of the method calls, but you might forget some of them. So it increases the test coverage. But the static typing is less flexible. It's against dark typing. So the dark typing is a very crucial, very important in the Ruby language. So it's quite sad to losing them. So about documentation, there are much better than comments. So we often use comments to the value or type that method requires. But we sometimes forget to update the comment when we add arguments or when we change the type of the argument. So for consistency sake, so the static typing is much better than comments. So no contradiction, no investigation into data. You don't have to read through the method to find out the type or requirement for the argument. So that is the PEP 3107's indentation. So Python people use types as documentation. But there's a bad side of the static typing. As I said, dark typing being optional and dry. So dark typing. The static typing is against dark typing. So you declare that you really need strings here so you can only call that method with an argument string. But if you want to call it with a string IOL or maybe the other some compatible types which behaves like strings, but which is not really a string. So that is dark typing. But if you declare the argument as a string, so the something which is not string cannot be called. And then we had a guy named Guy Rikou who created some kind of optional static typing back in 2001, which is way old. And he didn't disclose his implementation, but he told us from his experience so optional static typing. He created that to overload the methods. But he told us that is not a good idea. He didn't speak much in English. He mostly spoke in Ruby. But I really respect his ideas, his opinion, I mean. Option, being optional. So optional typing is only used for this 99 coverage, I believe. That is like TypeScript. It has the type name, the dynamic, which can hold any type of object. But the most of the cases, the types are defined for methods, libraries, something. Only a fraction of the program can be dynamically typed. In that cases, so we can utilize the static typing. But Ruby with 99% option typing is, I don't think it's no longer Ruby. So it's quite difficult to make Ruby 99% optional typing. So Ruby with a duck typing. We are with Ruby? So I don't think so. Ruby should keep being Ruby forever. So the JavaScript and TypeScript are very similar, close programming languages, but they are still different. So Ruby, there might be a room for the Ruby with some kind of static typing addition. But I don't think it will be Ruby as a language. And then Drive. Drive stands for don't repeat yourself. So Drive Principle is kind of like avoiding the duplications. So static typing, as I believe, is against Drive Principles. Just because we write code and we write correlation. So for me, writing code, vaguely accept this operation or something like that. So I have the vague idea of types in my mind. So I write down the code to represent that. So the code represents the behavior and the code represents the vague requirement to the object. So then I have to extract the operations. Then I form that type if I have to declare. So when we already described type requirements in the code, so why should I write down? So the fundamental idea of Ruby is do the computer the things they can do. So I made some ideas named the soft typing. The soft typing is the idea was described in the paper like this or that. So which is kind of getting some benefit of static typing without adding any declaration in the program. So no declaration needed. So it's kind of the best effort type checker. So looking through the program, so extract the vague idea I have in mind and write down in the code. So then they guess part of the type inferences which is the soft typing. So for example, so we have assignment A equal 1 which assigns the integer value 1 to the variable A. So the type of A is integer. So it's quite easy and done by the most type inferences of programming languages. But this is a little bit more complex. So the defined method foo that takes argument X, then the print X and then call to int. That means the argument of the foo method requires to int method inside. So with that knowledge, so calling foo with 1 is okay just because 1 has the to int method. But calling foo with strings is not good just because the string does not have to int method. So this kind of inference, having this kind of inference globally can check types of most of the Ruby program without adding any type declaration, without hindering duck typing. So in soft typing, type is represented by the set of methods which is the name of the method and the types of the arguments. And then some types can be represented by class or module but it means a set of methods. So if a variable is typed as a class, say integer, but any object with the signature of integer can be assigned to that variable. So it enables the static check of types and detect more errors. And it will be some kind of the best effort type checker. And then the target will be the subset of the Ruby programming language or restricting some kind of the dynamic nature of the language. For example, the require with variables or expression will be restricted just because, you know, by adding arbitrary require runtime that would hinder that kind of the global type check or define method with variables will be restricted, or method missing. So with this kind of the soft typing, this, say, meta-programming will be narrowed. And for documentation with soft typing, so unlike other programming languages, so you don't tell compiler types. The compiler will guess your intention and report back to you. So you write down the program, then you run the program through the compiler. So compiler will tell you, okay, this variable, I guessed your intention to this variable is this and this. So it is right or wrong or something? Or maybe you generate the information for the documentation or IDE. So without writing any documentation, you can understand what is expected as a type. So the future compiler will tell you what is your intention. So your future compiler somehow breathes through your mind to tell you what your intention. So it's kind of like a two-way communication between the compiler and you. So right now, you write the program and the compiler will tell you some kind of syntax error, then the execution system will raise you some kind of exception about the dynamic nature. So in the future, you can communicate with the compiler about your intention. So I think your intention contradicts somehow, so you have to fix this or fix that. Or maybe the IDE will tell you, you can call this method and this method, this method for this variable. So without any information, type information, type the correlation from you, so the compiler will much smarter in the future. So the soft typing means that two languages in one. So statically, soft type language and then dynamically type language, as current Ruby is. So when soft typing is not applicable, your program is so dynamic, so you cannot apply soft typing. So the soft typing will not find any bugs, but it means just four bugs to the dynamic typing, current Ruby. So you will not have the benefit of soft typing, but you still have the benefit of Ruby itself. But if you write down in the soft type style of the soft type applicable, so you can get the benefit of the static type checks. So it will be strongly encouraged in the former. So this kind of the soft typing will come first in the form of the static analyzer, but I think we need some help from the community just because I just met through the paper, the soft typing paper, and it is quite different. The paper was written on the language like a scheme, like the procedural, somewhat functional programming language, but the soft typing on top of the object-oriented programming language is so different. So we have to discuss and consider new ideas and implement them in the future. So we have to work on. That would take years, but I believe it will benefit the language and it will benefit the community as well. So it's for quicker error detection or for better ID integration. So this is just an idea. So just like the prior keynote, this idea might be given up, but this is the food for thought. We consider this as a food for thought. So we open up the gate to discussion for Ruby 2.0. These ideas may or may not happen in the future, but that's okay. The importance is think seriously about the future. Think seriously, how can we help ourselves to be better programmer, more efficient, or more, say, money-making? But there should be rooms to improve the language. There should be room to improve ourselves as a better programmer, efficient programmer. So let's discuss about the future. It's about the time to start new things that reached us to Ruby 3.0. So I believe the future is bright. So we will promise we will feed you the interesting things, like crazy ideas like soft typing or concurrency or making Ruby faster or anything like that. So let's enjoy programming. So Ruby makes us happier, being happier. So the key Ruby works for us to make us happier. So prepare for the future. Happy hacking. Thank you.