Good morning, everyone. Thank you. I always
feel nervous before you. Every year. This is RubyConf, the canonical Ruby conference. This
is the 19th conference? Yeah. Thank you for coming.
And I am very glad to have so many first‑timers. We welcome you. So, I'm talking about Ruby,
because this is a Ruby conference. Ruby is pretty popular programming language. You
know that. And it is 11th in the TIOBE index out of 150
programming languages. And ranked eighth in the Redmonk index. So, it's quite popular...
still. But nothing lasts long. And then the pride
goes before a fall. [ Laughter ]
So we have to be anxious about extinction. So, what makes Ruby great? I think the best one
is the programming joy. Back in the '90s, so there are people, especially programming
language designers tend to focus on the efficiency. So, the computers were so slow back in the '80s
and '90s so that we had to focus on the performance of the language. Compiling program language
and static type framing languages were popular like C, C++. JavaScript was not there. And
then ‑‑ but as a programmer, I started creating Ruby in 1993. So, back then, very
few programming languages focused on humans. They tried to focus on machines, because they need
more performance. But I'm ‑‑ I was a hobby programmer. The programming languages
itself were my hobby. So, I created Ruby just for fun. It was my hobby. I didn't
expect this big audience. [ Laughter ]
But... because Ruby was originally my hobby, so I was no order or requirement from the
customers. I didn't have any specific reason to create something. I just created Ruby
for myself. I enjoyed creating Ruby. I enjoyed implementing Ruby, and I enjoyed designing
the language. For that reason, I focused on myself, because I'm so selfish. A selfish
person. But accidentally, many of you felt similar, and I happened to make it a free
software. So, people are free to use that, without any money. So, people started using
it in scripting, gaming, building some desktop application or something. And the web came
in. And then the people started using ‑‑ creating web applications using Ruby.
Programming was pretty popular back then, but Ruby is better in many ways. Ruby is
the pure object‑oriented framing language. It is modular. It is powerful. And it is a
little bit readable. Not like pearl, in many cases.
And then mostly because of the joy of the programming, the Ruby programming tends to
be productive. Because most of the time when you are using Ruby, you are highly motivated. You
are productive when you're motivated. And you are motivated when you feel joy. Right? So
that's one of the reasons Ruby is highly productive. Of course we have many convenient and strong
features for productivity. But the best key of Ruby productivity is the motivation and
joy. Of course it is very good language design. Of
course I designed it. [ Laughter ]
But most importantly, we have resources, because so many people created libraries and frameworks
and Gems. So, those resources help you become even more productive. Those
resources does not come out of nowhere. It's from the community. So, I think the community
is the key of Ruby's success and popularity and productivity ‑‑ everything. Ruby
is the community. Okay. Ruby is a language software. And it's good, you know? It's
good language. It's well‑designed. But the community is more important.
If I didn't put it on the internet, if I didn't make it open‑source, Ruby might be nothing
without community. It should have been nothing. So, that you are the Ruby.
In that sense, we have to attract people, because the community without newcomers will
be, you know, dimmed. Go away. So, we have to attract people. Those newcomers ‑‑
welcome! Those newcomers are a very good sign of Ruby's success.
We have to provide technology to attract people, good community to attract people, and we need
more jobs to attract people. And yeah. Broader audience to attract people.
Open source community cannot stop. We are like kind of a shark. We have to keep swimming. Because
we cannot expect high loyalty for free. Because you are not forced to use Ruby ‑‑ okay,
most of you. [ Laughter ]
You came to the community. You came to the conference because you felt Ruby is good,
and that you wanted to learn more about Ruby, right? So this is attractiveness. But because
you're not forced, you can go to Python, PHP, JavaScript, or whatever. You can freely go
away from the community. So, we have to attract people. We attract people by good technology,
good community, and the participation is the key.
We call it open. We are open community. So, Ruby is often called open‑source software. I'm
in the free software camp, but I like the term "open," because open means welcome. Welcoming
you. So, I like the term open. And being open as a community, we build the future of
Ruby. Not me only, but with you. The roadmap. I rarely talk about the roadmap,
but this time is an exception. There year, December ‑‑ next month ‑‑ we are
going to release Ruby 2.7. [ Applause ]
As a Christmas gift. [ Laughter ]
As usual. And next year, we are going to release Ruby 3.0.
[ Applause ] Very importantly, this is fixed. No matter
what happens, we are going to have the Ruby 3.0 next year. Actually, some members of
the core members, including me are a bit worried that we cannot keep the deadline of Ruby 3.0. But
unless extremely bad things happen... [ Laughter ]
We may drop some announced features in Ruby3, but we will release Ruby3 next year.
They will come later if we drop. We will try our best.
[ Laughter ] So okay. Let me tell you about Ruby 2.7 coming
pretty soon. We are going to have the very nifty feature in Ruby 2.7, because Ruby 3.0
will not be the big jump. It's just a next release. We have the big jump in the version
number, but not big jump in the language. So, there are some new features prepared for the
Ruby 3.0 is released with Ruby 2.7. The first one is the pattern matching. We
are going to have it. Not the regular expression pattern matching. But the pattern matching
from many functional programming languages. With using the pattern matching, you can,
like this. Took the JSON data and pattern match to the recall named Alice and her child,
Bob, and retrieved the age of her son. Or no Alice. Well, if you write down the existing
Ruby, you have to write it like this. Okay? The person's name is Alice. Then children is
Alice's children. And Alice has one child whose name is Bob. And retrieve the age of
his son or something like that. This is quite straightforward, isn't it? Yeah. Okay. Pattern
matching can make Ruby more concise. So, we are going to have the pattern matching. Okay. I
admit it. The pattern match something slow right now.
[ Laughter ] If you use a pattern matching Ruby 2.7, you
will be warned. [ Laughter ]
This is experimental feature, but you can use it anyway. And I bet you will use it. And
you will love it. Okay. Keyword arguments. I admit that I
regret some part of keyword arguments, because of some of the history issue. But back in
Ruby 1.9, I allowed to put the hash argument at the bottom of the keyword. So, that people
can use the hash as a keyword argument, emulating keyword arguments. Then Ruby 2.0 introduced
some part of the keyword argument, but we have to support the pre‑existing emulation. So,
combining that, we have some weird corner cases. So, it's kind of confusing. For example,
what should happen? We have the method named m, and it has two arguments. One is traditional. The
other is keywords. Then call method m with a keyword argument. What should happen? Error? Yeah. It
should be error, I think. But it works like this.
Whoa. Okay. Next question. What should happen one is optional argument, the other
is keyword argument. And I call it with one keyword argument. What should happen? Reality
is this... Kind of confusing. Okay. Keyword arguments
pitfalls. The wrong number of arguments cause very nasty confusion. And in combination
with optional or rest arguments can be confusing. And combination with hash arguments is confusing. So,
we should fix to avoid future tragedy. I know it's backward incompatible, but it's
a pain we must suffer. So, we will do it in gradual steps. Step one, Ruby 2.7. Step
two is Ruby 3.0 or later... Ruby 2.7, the behavior is basically compatible
with Ruby 2.6 or before. But you will get warnings. And Ruby 2.7 introduced very ugly
Ruby2 keywords method. In 3.0, we will introduce real keyword arguments. So, that means you
can write the program that runs on both Ruby 2.6 and 2.7. You can write the Ruby program
that runs on both Ruby 2.7 and Ruby 3.0. But not for Ruby 2.6 and Ruby 3.0, because of
this incompatibility. So, you have to migrate. But, after this pain, unfortunately, this
unfortunate pain, keyword arguments will be simpler, easier, and safer. I will tell you,
this is the biggest incompatibility in Ruby 3.
I'm sorry. But you have to suffer. We will provide a migration path so that we try to
least your pain. Okay. Numbered parameters. We introduced
numbered parameters. Okay. _1 is the default parameter, first default parameters. Okay? So
you can take these elements and double them. It's quite easy. And you can use it,_1,_2, local
variables and the methods. But be warned. Stop using it for your new programs. Okay?
Next one is argument forwarding. You can write it like this. Three dots. Receiving
any arguments in three dots, and they are passing any arguments in three dots. You
need to wrap them in parens always. You can drop the parentheses around the arguments
for most cases in Ruby. But this is one of the exceptions. You have to wrap the argument
forwarding in parentheses. Begin/end ranges. This is kind of trivial. But
one, dot dot means the endless range. So, it means the one and forever. And then ..10
is negative infinity to one. I'm sorry. So GC compaction. We will introduce memory
compaction. We have less memory consumption, but it should be manual compaction. So, memory
compaction is still slow, so you have to tell the garbage collector to compact when you
are idle. So Unicode 12.1 and more emojis. More emojis.
[ Laughter ] [ Applause ]
Some will appreciate it, but as an implementer of the text processing, I say nah.
[ Laughter ] Better IRB. IRB, we introduced the multi‑line
edit for IRB. If you hit the top key twice, you will see the, you know, the inline references. You
don't have to switch the window or terminate the IRB to look up the reference.
We will have faster fiber. Samuel Williams improved it a lot. Great.
And we will have the faster JIT compiler, great.
And Ruby JIT will be very close to 3x3 in some benchmarks.
[ Applause ] Thank you. And we added many convenient methods
like enumerable tally due to elements of the enumerable. The filter_map, and the unbound
method to bind_call and others. So what's not new in Ruby 2.7? Pipeline operator. From
F #and elixir. They have this instead of this. But, it's canceled.
[ Laughter ] Okay. Natural pipeline operator behavior
in Ruby is very dependent on the definition of natural.
[ Laughter ] Let me explain a little bit more about that. I
was very frustrated about that. Pipeline operator in F # defines it like this. And
this operator on the left‑hand side argument at the bottom of the argument list. In Elixir,
it's defined in macro, and it's the left‑hand operand as the first argument as the function
calls. That means the behavior of the pipeline operator differs in F # and elixir according
to the culture and library design of the language. The concept of the pipeline operator, the common
behavior of the pipeline operator is to add primary argument to the call. So, I defined
natural behavior of pipeline operator for Ruby, and it should add primary argument to
the call. Think about the map method in Ruby, the primary operator, the most important argument,
which is the enumerable, is the receiver. So, add primary argument to the call means to
add primary argument as the receiver... It is the method call. But many people expect
Elixir's pipeline behavior, because they know Elixir's. So, there are far more than I thought. The
common sense is defined by the community. So, if I strongly insist the proposed behavior,
I would have tried to persuade the community. And it would take years. But even though I was
the original proposer of the idea... yeah. It's okay to drop for me. Unfortunately, not that
much. So, I canceled. The second one is a method reference operator. In
Python and some other languages, the obj.foo returns the foo method from Ruby at obj. But
in Ruby, obj.foo calls method, even with a parentheses. So, the parentheses is not significant
in Ruby language. It's very useful. Obj.foo can be attribute retrieving defined by method. So,
you can easily define the accessor. So, it's quite suitable for object‑oriented programming
language. But it's relatively harder to get a method object. You have to do like this. Obj.method,
and the symbol. So, instead of the existing way to retrieve
the method object, we proposed obj.:foo to retrieve the method object. Yeah... but it's
useful in some cases, and it's short and it is powerful, but ugly. Yeah. It kind of
looks like braille. Yep. And in recent years, we have added some features as part of functional
programming languages, but we didn't have the grand design of functional programming
in Ruby. So, we will take time to think about functional programming in Ruby. So, it's
canceled for Ruby 2.7 to rethink. But maybe we will provide method reference operator
in Ruby 3 or farther in the future. But we have to make some grand design of the functional
programming in Ruby. So, what's next? You will have the Ruby 3.0,
and the current plan ‑‑ I talked with many people to design the future of Ruby. Last
few years, we are working on improving the performance. And we have to be a multi‑core
ware. And we can address the bigger team and bigger projects.
So the Ruby3 should have the VM performance and con currency and static analysis. So,
the VM performance. We already ‑‑ Ruby 2.6, last year, we shipped with the JIT compiler,
experimental JIT compiler. It ran Ruby applications faster, two times faster for some cases, very
CPU‑intensive tasks. But whereas the application runs slower, unfortunately. But we are working
on it for last year. And we are working on it for Ruby 3. And right now the JIT compiler
for applications runs as fast as without JIT. Not faster yet. But we are trying.
And in some benchmarks like very CPU‑intensive benchmarks, it comes 2.8 times faster compared
to Ruby 2.0. So, we are very close to Ruby 3x3. So, yeah. We merged. Okay.
Next we have improved garbage collectors. We must ‑‑ the heap in 2.6 and compaction
in 2.7. We keep improving performance. Concurrency. Concurrency is hard. I regret
adding threads. [ Laughter ]
I added threads to Ruby way before 1.8. So, they are way older. So, back then, every ‑‑
most of the computers only have one CPU. So, we didn't have to care about multi‑core. So,
the grand design of the Ruby threads is stick to the single core. But, you know, these
days we have many cores on laptops, smart phones, even on the Raspberry Pi. We have
to care about multi‑core. So, in the multi‑core age, there are threads and the Ruby concurrency
is hard to use correctly, hard to use it efficiently, and it's very hard to debug. We need a better
concurrency abstraction. So, we talked a lot about the future of concurrency in Ruby,
and we concluded we are going to provide a new concurrency model, one for CPU bottlenecks
and the other for the IO bottlenecks. We will provide
fibers for I/O bottlenecks. They should be easy to use, easy to debug, and they are easy
to perform. You might say that the go or elixir use single
routine. The processes for go and elixir. But we need two. Because these languages are
designed with the concurrency model from its day one. But these concurrency models add
on, so that for the sake of the compatibility and the portability, so that we need two entities
instead of one. The one is guilds or maybe we call isolates. We have to discuss it a
little bit more. It's kind of like WebWorkers or Isolate in JavaScript. It helps the multi‑cores
by offloading the CPU‑heavy tasks. The fibers were a small enhancement. It uses
the I/0 multitasking and built‑in async so that we are not going to have the async
or await ‑‑ the reserved like in JavaScript or Python or whatever, but we just use fibers. You
can't write down the normal subsequential program with the normal plexing.
And now, static analysis. We can call it static typing. As the project grows, the
test becomes a burden. You know that. Testing increases in size and more time. And tests
are not DRY. Don't Repeat Yourself principle. You know? We do write tests anyway, but we want
to be more productive by reducing tests. The other languages tried to reduce the tests
by providing type hinting or type annotations. Or even the different dialect of the language
from Microsoft. So what should we do? Add type annotations? Or
the creating the alternative dialect like a TypeRuby? No.
[ Laughter ] I hate type annotations.
[ Applause ] Because it's not DRY. You know? You program,
your current Ruby programs run without any type annotation, right? Because Ruby does
not provide type annotations. Because I'm stubborn.
[ Laughter ] But if it works, so adding type annotation
is kind of redundant. So, it's not DRY. So, that we won't add type hinting to the language,
because it's not needed for my picture. The plan for Ruby static typing, we will provide
static type information for standard libraries. In format named "Ruby Signatures." The future
Gems can provide type information as well, so you can have the type information in different
files from your programs. You may wonder that having different file ‑‑ so you
have to make it in two files instead of one. But it has a reason. Because, you know, in the
far distant future, maybe five years later or ten years later, we will have the very
smart compiler with AI. So, that you can guess the type information without any type
signature. So, that at that time, you don't have any type signature, Ruby signature, type
annotation, no anything. You just learn by the compiler. Your program is wrong or something
like that. You made mistake in this line of code. Compilers can tell you or teach
you how to program Ruby. And we will provide a tool named the Type Profiler that uses AI
for type checking. This AI stands for the abstract interpretation.
[ Laughter ] [ Applause ]
So that traces call paths of your applications. And collecting type information of your application. And
along with the checking type contradiction to the type information from the type signatures. Then
generates signatures for your applications. And that means you will have the type information
of your application without writing any type annotations. And then you can have the third
party type checkers. So, that uses type information from signatures.
Currently we have some ‑‑ the Ruby static type checkers including RDL and Sorbet and
Steep. Sorbet and Steep have their own sessions in this conference. If you have interest
in it, go ahead and attend these sessions. And then, yeah. They don't use the Ruby signatures
yet. The projects are started before the Ruby signatures. But all of us agree to adopt
the Ruby signature gradually in the future. What will happen with this type checking?
You ordinary Ruby programs will be statically type checked. Errors in compile time without
any type annotations in your Ruby programs. If you refine type definition files in the signatures,
you will have better checking. So, type profiler cannot generate types or make a distinct ‑‑
distinguish between the tuple type and the uniform. So, you can write down the Ruby
signature by hand to tell a compiler that kind of information. But Ruby static type
checking without any type annotation. Wouldn't that be cool?
[ Applause ] Yeah. We are working on it. And the result
is promising. At least from my point of view. We cannot stop progressing. We cannot stop progressing
as a community, otherwise we will die. Eventually. So, we need to survive. We have to keep moving
forward. It is our destiny. Not only us, but you, too. Participation is the key. Ruby
can be better. Ruby can be great. Ruby can make your life happy with your participation.
More than 20 years ago, I created the term, "Rubyist," and the definition of Rubyist is
a person who is more than a mere user. So, you are Rubyists, because you attended the
conference. And you are part of the community. You are Rubyists. I wish you all keep being Rubyists. Don't
go away. [ Laughter ]
And happily ever after. Thank you. [ Applause ]
