 So I'm awfully sorry about that. So after waiting for you, so Ruby typing. So this year, I'm going to talk about types. And then various type are related to the Ruby. So warning. So this talk is highly technical. So you are not supposed to understand part of them. But a very important part is non-technical. So I will emphasize the important non-technical part. So you don't have to worry about that. So let me talk about types, blood types. So the mankind has some kind of several types of the blood types. The most famous one is ABO systems. ABO system is our blood type according to have the factor A and factor B. So we have four types of the blood types in ABO systems. So the blood type A, the people of the blood type A has the factor A. And people with the blood type B is factor B. And the blood type AB has both factor A and factor B. And the blood type O does not have either the factor A and factor B. So we are all humankind are classified into this four category, four blood types. Do you know your own blood types? No, no. So very funnily, so all Japanese, almost all Japanese know their blood types according to some superstition. We Japanese, most of us believe our blood types influence our personality. So our personality can be classified according to our own blood types. For example, the blood type A is a kind of organized personality. He or she loves to make everything organized. And then blood type B tends to be optimist. Then, so he or she has very bright viewpoint toward the future. A blood type AB, since they have the both factor A and factor B, they have some kind of a dual personality. So that he or that people with blood type AB has sometimes organized, very organized and sometimes very optimistic. And then blood type O, people with blood type O don't care about small things. I happen to be blood type O. It's kind of like a fortune telling. And then we have those psychological effects named the Burnham effect, which is the people tend to believe vague and general descriptions of their personality. So if you are a blood type A and you are told, okay, you are a blood type A, you are a very organized person. Yeah, you should have the very organized personality. So you are very easy to believe that kind of your personality description. So do you believe it? Maybe not. No, that's okay. The important point is I'm blood type O and I don't care about the small things. And I don't want to care about small things. Things should just work. And then personality influence design. Since I design Ruby, things should just work. And I want to get a job done and let things get better. And I very, very believe in succinctness, it's power. As Paul Graham once told about his idea of programming language. So the design of Ruby is highly influenced by my personality. The dynamic types is one of them. Dynamic type means the values have types, but expression or variable does not have types. So that is dynamic types. So in description of a type system, we have the two dimensional aspects, like the static versus dynamic. There are static type of programming languages and dynamic type of programming language. The example of static type language is Java, Scholar, or Haskell, or Camel. They are static type of language. And Ruby, Smalltalk, Python, Lisp, or other programming language are dynamic type. And the other aspect is the strong versus weak. Some programming languages are strong. That means the types cannot be changed or converted automatically, or weak, that you can break the time system in some way. So the example, so the Ruby is a strong dynamic type programming language. And the power or orc is a weak dynamic type programming language. The Haskell and other static type programming language are strong static type programming language. And the programming language like C, which can cast pointers to other type of pointers. So you can easily break memory access. So these are weak static programming languages. So the dynamic typing leads to design policy, which is the doc typing. So remember this picture last year? Doc typing. This is very important factor in programming language like Ruby. So doc typing means not this one, typing doc. That means if it works like a doc, works like a doc, and a clock's like a doc, it is a doc. This is a very important principle in Ruby. So if, so if, let me see. It's a doc because it works like a doc. It's a doc just because it's working like a doc, right? This is doc typing. So we don't care the internal detail of the data. We just care about how it behaves. So in doc typing, we do not classify like animal, mammal, human type things. Do not check types. We just ask object to behave. So we don't care about inheritance. We don't care about the structure. We just care about how it behaves. So we can ignore inside detail. So we ask computer to dispatch. So pick the proper method or the process that they want for that particular object. So we don't want to care about small things. So things should just work. So for example, so doc typing like this. So suppose we have the function named log, which has the two arguments. The first one is the destination to output the log. The second one is the message to print in the log. So if we have the static type of programming language, it should be goes like this. Log, DST, destination, which is IO, and the message, which is string, right? But what if we want to redirect your log message into a string? So in Ruby, we have something named string IO. So you create the string IO object, then call log standard IO as a destination. Then the string IO.string retrieves the input strings. So this is quite easy. The important point is string IO is not a subclass of IO, nor they have common interface or engine like that. They have no relations. But in Ruby, it works like magic. Just because string IO, even though string IO does not have any direct relation with inheritance or interface, but it has same method set to IO, so it's just behave like IO, an IO. So string IO works like a doc, works like IO, the quarks like IO, so it is IO. It is doc typing, right? But the static type version, which is this one. So this one says IO here, here. So if it's string IO is passed, since string IO is not a subclass of IO, it refuse to compile. It refuse to compile. So this way, this kind of program is prohibited. In static type programming language. So static type version doesn't work as we expected because string IO doesn't have common superclass or no interface to IO. So string type check fails at compile time, I mean. And then compared to that, doc typing or dynamic typing allows you to ignore internals. Just behave, you can focus on behavior of the object. So you don't have to care about the internal or inheritance tree or anything. So you just care about how it behave. So it has lower mental cost in development. So doc typing is open for the future. So you don't know when you define the log function, when you define the log function. So you don't have to decide about the future. So you just care about how it behave. So in the future, you might want to redirect your log message into the standard IO or any other IO-like object. But so it is open for the future. So that means that doc typing enhance the flexibility. But dynamic typing has some drawbacks. So dynamic typing does not check type in in compile time. So that errors, especially type errors, only fault in runtime. And often you get very bad error message like undefined method for in your class or something like that. So it is quite difficult to understand in especially in runtime. And then you have coverage problem. So unless you have the 100% coverage test so you may miss some kind of the type error in your development. On the contrary, the static type programming language, so type check has done in compile time, 100% coverage, so you at least your compile success, you can be sure your program doesn't have any type mismatch errors. And the most, the last but not least is the less documentation. The type system, type description itself can be worked as a documentation. So in Ruby or any other program, dynamic type of programming language, we often write like this. So we call the Calculated Factor number, it takes integer and then returns integer. So it's a type. So it brings me some kind of the contradiction. So I don't want to specify types just because the programs without any type notation just works. So in that viewpoint, the type notation, type description is redundant. So I don't want to care about small things. So for me, type notation is small things. I don't want to write that. But I don't want to specify types because by specifying types, we restrict, we refuse future flexibility. We are close to future enhancement. But at the same time, when we provide a code to others, we need documentation for users. So if we put type information in documents, it's kind of like a static typing with the enforcement. So you write type notation to type description anyway, like a previous example like this, you write type anyway. And then, but this is a mere comment. So this is no enforcement. This is no type check. This is not a compile time check. So that's worst of both worlds. So no compile time check. So here's a room for improvement for future Ruby. So we don't want to write types, but we want to have some kind of type information from code. But we are engineers fundamentally. So we tried to solve problem with technologies. So let me think about the solution. Okay, the one candidate is static typing with type inference. Type inference is nice. So by inference from code, you can have the type information, but you don't have to write it. But still, static typing lacks flexibility, as I explained before. You know, there are some programming language that introduce the gradual typing or optional typing, which is say, for example, the Ruby has optional static typing or TypeScript has the similar things, optional typing system or gradual type system. So these are, so you add several, you add type description in some part of the program, but it's not the mandatory. So you can drop if you don't want to, or you can put any other type description. But they are fundamental static. Partly static, the rest is dynamic. So since it is optional, you won't have the 100% coverage. And since it's static, so you lack of flexibility, as I explained before. So it's also the worst of both worlds. So I don't want like, so the optional static typing shares same drawbacks of the static typing system. So what we want is something similar to static typing, but that allows dark typing. So dark typing is very important policy and it's very important in Ruby. So we want to keep that. At least I want to keep that. And then, but static typing is good, especially compile time check is pretty nice. So what shall we do? So the thing about that static typing with dark typing. So I look for many programming language. I'm a programming language geek, so I studied about a lot of programming languages. So there is a language with static typing, with dark typing, which is Go. Go programming is kind of like this. So the focus on the log function division. So dst take two arguments, then write to the dst, and then this is type. Then this is type definition. The log dst is the anything which has the right object, a right method can be considered as a log dst. You don't have to be subclass of anything, or you don't have to share common interface. So just you have the right method, this is only requirement. So any type, even IO or string IO or anything, which has the right method can be applied to the log function. This is dark typing, and this is with static typing. This is quite nice. They call this structure of subtyping. So, but you can add inference to Go. So in the ideal Go, you can drop off the type notation. So function dst and message, the dst should have the right method, and you can call that method with message. So you can generate the dst, you can read dst type of dst should have a right method. So write takes one argument with message. So with this information, you can generate interface from code. So from this code, this is the ideal, my own version of Go, and then you can generate this version of the current Go. So if Go, something like this could be possible in Go, language like Go, so the language like Ruby can similar things. I call it soft typing. So soft typing is a type system defined by behavior. So type is defined by a set of methods and it's the other argument types. And thus, so inferred types don't have names. So many people, including static type camp, so tends to define class with a name. But you don't have to worry about type names. So I want to express that this type of this argument or type of that argument or something like that, you don't have to name it. So you can generate the anonymous interface. So you don't have to worry about names just because the make up, the proper name is a pretty heavy task in programming, right? So if you can avoid naming them, so it's much easier for a brain and you can stay the vague ideas in your brain remain vague. So the type system, the soft type systems like should be kind of database. So you can retrieve type of an expression. So here's a variable A that what you can ask type of that expression, that variable. Then you can retrieve type as an object. So you can check compatibility between types. Okay, this type of the argument under this type of expression. So are they compatible? So you can check the compatibility. So if they are compatible, you will not see any type error. But if they are incompatible, they're not compatible. So you will see the compile time type error. So you can check if a type has a specific method like does this type has a method named foo or something? So the important point is the soft typing do not challenge 100% coverage. So the current Ruby without any static type system just works, right? So if the type can be inferred from your code, so that's okay, you can check in static type, static type system, but if you don't, that's okay, just foo box the dynamic typing. So the 80% compile time check is far better than the 0% right now. So it is easily foo box the dynamic typing. So we are not trying to 100% compatible. In addition, this is still the concept, but we can use the runtime type information. So for example, you write tests, right? You write tests. Your test system should not have any type error, right? So you can execute your test with the type error correction mode. So you can correct the type of information running when you, during the execution test, executing test, then you can build type database from your source code. And then in the future, you can ship your type database with the gem so that your users of your gem can use that kind of type information generated from the test execution. So by using this database, you can have the more accurate compile time type check. So it'll be awesome. And then, but unfortunately, this is mere concept, but you can use it now, but it's still mere concept. But it's a part of the Ruby 3 project. We have a lot of things to down to Ruby 3, but this kind of soft typing. So the soft typing, which is static typing, kind of soft typing, that you can check the new type error in compile time without any execution. But you will have that kind of soft typing in Ruby 3. That is my hope and dream. The important message is we care about you. We care about you. So the Ruby is pretty nice. Most of us love Ruby, right? I force you to say that. So most of us love Ruby just because Ruby care about you. Ruby cares about you. So Ruby try to reduce your burden in your development, the mental burden, or Ruby restore joy in your programming. So when you were a child, then started programming, everything was fine, even the basic, or assembler. But as you grow, you pick the programming as a job or responsibility, so you have to care about many things. So you make money out of programming. So the joy is getting less enjoyable. The programming is less enjoyable. The joy is decreased day by day. But Ruby tries to restore that kind of joy. Just because Ruby tries to reduce your burden, it tries to joy in your programming. Just because Ruby cares about you. Just because we, the designer or developer of Ruby, the language, care about you. So we care about how you feel during the programming, we are willing to improve the development experience. That sometimes it really sucks, just because it fails to find your type error in compile time, or it's their document is less descriptive compared to the other programming language. But we are, despite the current states so we are willing to improve the development experience. So we are trying. So we are sick of claims like Ruby is dead, Rails dead, Ruby is old, and I don't care. As long as we are improving, actually I care. I try not to care. They hurt. But actually I try not to care. As long as we are moving forward. As long as we are moving forward. We, the Ruby is moving forward. Ruby is moving forward. Every Ruby version, every year we release a new Ruby. Last year, Christmas, we released 2.3, which has the improvement, keeping compatibility. And then we are going to release 2.4 this year and it will improve your experience, your programming experience. And that kind of improvements keep goes on, then gradually into Ruby 3. So you may ask, where will Ruby 3 come? Actually, I don't know, I'm sorry. So my hope is we will see Ruby 3 in this decade. Yeah, before the Olympics in Tokyo. But it's only my hope. So we will try making Ruby 3. We will add Ruby 3, the soft typing, and Ruby 3 will be three times faster compared to Ruby 2.0. And then we will add some kind of real concurrency in the language. But we have a lot of things to do and we have a lot of things to be done and we need more resources, we need more power, so you have to wait for years. I'm sorry. But we wish your input and contribution to keep moving forward. We have to keep moving forward to survive, to make you happy. And then we will improve the situation by working together as a community. So Rails will be improved, Rails 5 will come. So they will add many new things to improve the development experience. And as a platform, the Ruby language will be improved and then we will add many things to improve your development experience. By the way, Ruby 2.0. So this year we were going to be able to release Ruby 2.4, hopefully as a Christmas present this year, as usual. Last week we released Ruby 2.4 Preview 1. In the Ruby 2.4 Preview, it's not as big as 2.3, but we added very important changes to the language. So one of them is a fixed num and big num unification. So we will no longer have the fixed num and the big num in the language, just integers. So when I first designed and implemented Ruby, so I stole many things from other language. For example, from Smalltalk. And Smalltalk has the two types of integers, like small integers and big integers. And then the list has similar to types of integers, which is fixed num and big num, which are where I stole the ideas from it. So I stole those classification without thinking deeply. But I don't want to care about small things. So the distinguish, distinction from small integer, which is in line in a big integer, which is big and lives in the heap is small things. You don't have to split them in the program side. So as after the years of consideration, finally we decided to unify those two classes. So we don't want to care about small things, so the fixed num and integers are unified. The basic ideas from the flow num, the idea we introduced in 119, so in 64-bit platforms, the float has two representation, implementation representation. So the small float numbers are in line in the variable. So they are immediate values. And then other float numbers, allocated in the heaps, but they're still same float class. So despite the implementation representation difference, so they can be a same class. So that idea lead us to unifying fixed num and big num into one integer class. So that introduced the small incompatibility. So if you use fixed num class in your program, so fixed num class is became alias to the integer class. So most of the case it just work, it just work. But if your program is very, depends on the size of the fixed num or something like that, so it may have some kind of compatibility problem. So you have to be really, really care about if your program care about the size of the fixed num. So the integer, integer implication. So the second one is a smarter case conversion. So we have the up case, down case, or several other case conversion method in string class. So it worked only for ASCII characters. Just because it is quite difficult to define what the case is out of the ASCII characters. Your English speakers doesn't care about the weird down ASCII case characters. But in the Unicode, from the Unicode construction, you can obtain the huge table of case conversion. So now it works for other characters. Let me explain about the background. So when I first designed the Ruby, so Unicode were there, but it can be very ignoble. So Japan has several character set to Japanese characters and Chinese has their own encodings and Russian has their own encoding, Indians, every country has their encoding other than ASCII. So we cannot define any way to case conversion out of ASCII. So at that time, we were able to handle ASCII only. But as time goes by, the number of people using Unicode is getting bigger and bigger. Now almost everyone using Unicode, especially in the web-related field. So now we can rely on some kind of the Unicode case conversion database. So the Ruby 2.3 and prior, so hello up case is hello, but if you use E with what does, or something is on top, so it's not converted at all. So hello, but after Ruby 2.4, you will have flow for case conversion here, here. But if you want the old behavior, you can put ASCII as an argument. So you can get old behavior. So we don't want to care about small things. So having the accent or something like that is trivial for us in our daily use. So I want you to, I want you don't have to care about or worry about small things. Actually implementers made big effort to make this possible. For example, takishai. Do, does anyone have any knowledge about takishai? Or you do. So in Turkish, the capital I converted to I without dot. In the ASCII capital I, it should be converted into the I without dot. And then you have the other I, which can correspond to the I with dot in the ASCII I. So when you're using a Turkish, so you're not rely on the ASCII I to I conversion. So in that case, you have to specify dot current Turkish instead of ASCII where it is, here it is. You have to specify the Turkish instead of ASCII. So you can get the Turkish conversion table. That made us very troubled. Anyway, in any way, I promise, we promise, we co-committers promise, we will do everything to keep moving forward just because only paranoia survives. Yeah, we are paranoid to survive. We have to be paranoid to survive. We have to keep moving forward to survive. You know, there are tons of other programming languages. Something is new. So maybe you are interested in the other programming languages like Elixir or Clojure or Scala or JavaScript or TypeScript or many other languages, many other rivals. So, you know, you are okay to move on to other programming languages. But for me, with a Ruby, I'm nothing. So I have to survive. But the primary motivation to keep moving forward is to let us care less about small things. So to make you happy, to let you enjoy your programming again and ever. Happy hacking. Thank you. Thank you, Matt, for your entertaining presentation. So, just curious, how many of you guys out here are of blood type B? Type B. Okay, you're my type. Optimist. Yeah, so I would like to open some, Matt, for some questions. If anybody has any questions regarding type B. Yep, sure, please. Okay, hi, Matt. So with soft typing, how would it help us if we, does it mean that I don't have to write types, write tests anymore? For example, like test, I expect an object to be of the person class. Does it mean that I don't have to write tests like this anymore with soft typing? You still need to write test. Just because most of the tests were logics, but not types. But you can reduce some types, some tests, just test about the types. But you still have to write tests. Write tests. One last question. Were the types actually help the compiler to generate optimized native code? Generate? Optimized native code. Currently I have no plan to make, I use it as optimization information, but maybe in the future. Hi, any more questions? Please don't be embarrassed or afraid to come up. So with more encoding support in 2.4, does it mean that now there are a lot of mappings in the Ruby repository with all those encodings? Yes, Ruby repository became bigger. How bigger? Like 10% or? I don't know, I didn't count, but much bigger. Thanks. I think it's fantastic that you have the case conversion in other languages now. That's wonderful, thank you. But in Java there are locales which can govern things like, we were talking about the very interesting case of the reverse Turkish high situation. In Java you can have the locales, the current locale, you can overwrite the current locale for an operation, and it also provides currency formatting, gate formatting, decimal formatting based on the locale. Any possibility of you ever see that in Ruby? Not in the core classes. Maybe we, locale has some, of course locale has some benefits, but as the old C++ programmer, so locale gave me burden or pain rather than a benefit. So personally I don't like locale, so I don't do that by myself. But I'm not object, I'm not against about adding locale to some kind of the gen or the additional library. So with the integer unification break any existing code that uses C extensions? Includes C extension, the very few examples of the breakage. And only one example report from the outside is the message pack, which requires the size of the fix num by using the is a method. But this is very exceptional, I think. No, but say for example you're using the fix to int macro for converting fix nums to integers. Yeah, we provide macros to distinguish. So will that macros still be there or will it be removed? The current macro does work, and then we provide new macro to distinguish the unified version and the ununified version. Any more questions from the audience? Okay, I personally have a question from us. So Ruby is generally a very polite language, and I'm wondering if you had to do anything to enforce this politeness for your contributors and both developers like? Yeah, I don't know. I'm not sure about the definition of polite here. But you know, the weak committers are very straightforward each other, so they, actually they hit each other. So if one of our committers make that cold, so they're blamed so heavily. So it's not that different, it's not polite in that sense. So let's all, one more question, please. Ah, sure. Hi, Matt. Ruby is awesome and we all love it really here, but you said let's move forward a couple of times during the talk, and like moving forward for most of the people here is kind of hard for Ruby. Because I'm sure like, can people in here raise your hand if you ever contributed anything in Ruby control? Like I mean gems in Ruby, not seco. Okay, now who can write C good enough to actually contribute to Ruby itself? I would say this is a big problem. Can you tell us how can we as Ruby community help with the Ruby itself, because most of us unfortunately don't have enough experience with C especially to write in the code base as complicated as in the write. Yeah, the information and use case is very, we need very much, the information very much. So the, if you feel something, if you feel somewhere to improve, so let's tell us through Twitter, through blog or issue tracker or anything. So you can tell, okay, there is a room to improvement in Ruby language. So you don't have to have a knowledge of C code. So just you think you need to improve here or there in the language. Or maybe you can benchmark your application. So this part of Ruby is very slow. You have the core team have to improve here or something like that. That kind of the concrete information is very crucial for us to improve, to work on. So of course, if you can write C code, so you can send us a pull request or a patch or anything like that, this is more than welcome. But if you're not, that's okay. Just kind of tell us your use case, your benchmark, your ideas or maybe your improvement for our documentation or anything like that. Any contribution is welcome. And many of those doesn't require seeing knowledge. Okay, so I just want to ask one question where when did you get that lonely operator T-shirt because I really, I think I really wanted to know. Yeah, after I made a lonely operator. So a friend of mine is working as a T-shirt company. And their website is running in Ruby. So he made this T-shirt for me and gave this for me. So I don't think you can buy it. So if that's called for questions. All right, no movement. Okay, so let us once again give a round of applause to Max. Thank you.