>> EVAN: My chair is missing a foot, and I
don't want you to see me looking nervous,
so we will eliminate this right now. And
please give Barrett a hand. He didn't thank
himself. 
[ Applause ]
All right. Where were we? 
>> MATZ: Nashville? 
>> EVAN: Oh thank you. Yes. Been a long
couple days. Whoo! No. So, thanks for coming
to the traditional Q&A. The way that we'll
do this is we solicited some questions online,
and then I also have some questions that I
will just sprinkle in, and then we also have
mics up here for you all to ask questions. So,
if you have a question, you don't have to
wait for me to finish. You can go ahead and
line up. I will call on you and sprinkle
them in. And yeah, just have a conversation
and see where it takes us. 
How was the conference? 
>> MATZ: It was a great conference. Thank
you. And I was a bit tired this year, so
I missed many of the sessions. But I am looking
forward to see the videos. 
>> EVAN: Good. Ice‑breaker question. That
went well. Maybe not. Maybe it didn't go
well. All right. The questions online are
really good. I think we will probably do
that more in the future as well. It allowed
people to expand on their question in written
form. The first one we had is looking back
at Ruby's history ‑‑ some of these will
sound familiar. But I think people like asking
you the same question year‑over‑year and
see if they get a different answer. That's
a fun game. Looking back at Ruby's history
is there a language feature that you or the
core team is especially proud of? Something
that really stood the test of time? Or conversely,
has there been anything in the Ruby community
that has impressed you like a library or product
or something like that? 
>> MATZ: As a language, the invention of the
block is remarkable for me. It is very small
change, but it is readable and writable and
pretty expressive. 
For the libraries, the invention of Rubygem
is very impressive. Actually, the very first
version of Rubygem is written in the very
first version of this conference. 
>> EVAN: By David and Chad and Rich. I can't
remember who exactly was in that room at the
time. My follow‑up is we have two syntaxes
for the block. Which one came first? Did
the do end or the curly braces? 
>> The brace comes first. 
>> EVAN: And you were like oh, I need another
way of doing this. 
>> MATZ: Actually, before the first release
of version 0.95, I released to my close friends
that Ruby's Godfather told me that it was
confusing. So, I enhanced the syntax. 
>> EVAN: That's interesting. It was like
oh, it would be nice to match them up, too. That's
cool. 
As we're looking at Ruby 3.0 and thinking
about Ruby 3.0, are there ‑‑ there's
a couple of questions about sort of like things
that we might remove and part of the other
sort of half of that question is do you ‑‑
like I know that you have talked about sort
of the way that major version upgrades have
gone in other languages. So, are you thinking
of the two to three transition as it being
a big transition for people? Like taking
away a lot of things that they have to figure
out how to replace? Or maybe talk a little
bit about that? 
>> MATZ: Yeah. Between Ruby version 1.8 and
1.9, we had a huge jam for compatibility. And
I think it was necessary, but it requires
the community to migrate to the new version
1.9 for five or seven years. 
>> EVAN: It was a while. 
>> MATZ: It was a long time. Half of the
community stays in the 1.8 for a long, long
time. And you know, we at the core team,
we made a lot of effort to improve the 1.9
so half of the Ruby community was left behind. So,
I don't like that kind of tragedy. And as
we see the similar tragedy in the Python community,
so I feel even more stronger. 
>> EVAN: So is there anything that ‑‑
but it is on the flip side, it is opportunity
to take things away. So, are there things
you're thinking that you want to take away
in Ruby 3? 
>> MATZ: We are going to remove several features,
several very trivial features, like the save
variable for maybe the dialogue setting...
some variable. But, they are very trivial. So,
we took several years to remove them. Once
you be warned to use that feature, then you
got error for using that feature. Then we
totally remove the feature in the future or
something like that. 
>> EVAN: I don't recall if you talked about
this on day one. It's been a couple of days
now. So, we're looking at Ruby 2.7 for this
coming up this year. And how many are we
gonna have Ruby 2.8 or 2.9? Do you have thoughts?
Do we get Ruby 2.10? 
>> MATZ: No. 
>> EVAN: So three minor versions left? 
>> MATZ: Actually, as I mentioned in the keynote,
so there's No. 2.8 or 2.9. We are going to
plan to release 3.0 next year. 
>> EVAN: Okay. 
>> MATZ: Whatever happens...
[ Laughter ]
Unless extremely bad things happen. 
>> EVAN: All right. Good. Let's see. So,
let's see here. What else? I don't know
who this might have been, because they didn't
attach names on purpose. But someone wanted
to know if you have changed your mind about
macros in Ruby 3.0. I don't know who might
have asked that. 
>> MATZ: No! That is a long question, but
basically no. In 2.6, we exposed ast so we
can build from the Ruby program. Then you
can tweak the ast and you can generate the
bytecode from that so you can create that
intermediate processing of the program. That
means that you can implement some kind of
macro using that kind of tool. 
>> EVAN: So you're saying there's a chance? 
>> MATZ: Yeah, there's a chance, but not actually
in the language. 
>> EVAN: Maybe pre‑processing hooks before
you parse and then...
>> MATZ: Yeah, those kind of things. And also
some pop mentioned about the transpiler, the
compiler, they are tweaking the transpiler
so you can have another chance to have something
similar to macro. Maybe you can extract a
new language features using that kind of a
transpiler. 
>> EVAN: Um, yeah. Let's see. Don't forget,
if you have questions, please, the mic is
right here. It's not just my time. It's
your time. If you have questions, please
come up to the mics, and I will call on you. Let's
see if anyone's at the mics. Oh! I've already
covered macros. 
>> I'm not going to ask about macros. Is
the pipeline operator gonna come back? 
>> MATZ: I would say there's a chance. 
>> EVAN: The pipeline operator, if we could
talk about it for a second, it might be an
interesting view into how Ruby core decides
on what experiments to take and how you evaluate
the experiment and whether or not to go forward
with it. So, could you maybe talk about,
like, who presented it, how you did the evaluation
and came up with the decision to pull it out? 
>> MATZ: Okay. I was the one who introduced
the idea of the pipeline operator into Ruby
at Ruby Kaigi this year. And then we discussed
a little bit and we experimented a bit. And
we had several controversy. And then we found
out that people expect pipeline operator to
behave like Elixir pipeline operator. It
was surprising for me. So, you know, after
considering a little bit, a little while. Then
it's not worth frustrating the whole community. And
I just, you know, retract the idea. 
Maybe after the idea, we come up with a consensus
of the behavior of pipeline operator, really
consider it. 
>> EVAN: Okay. That's a good question that
someone had submitted, which is sort of around
functional programming. Obviously the pipeline
operator is sort of a form of that. You know,
are there any other things, like you ‑‑
like maybe talk about what was the thing that
drove you to say oh, maybe we should have
a pipeline operator? Was it looking at Elixir
and other functional languages? Are there
things out there that makes you think maybe
we can have something that does like this
or other features that you have considered? 
>> MATZ: We considered pattern matching from
the functional programming language, and then
we merged ‑‑ we take it. And what else? What
else? 
We have very teeny idea like an immutable
struct or something like that. But it's not
a big deal, so maybe we add them in the next
release or something. But not for Ruby 2.7. 
>> EVAN: Okay. Okay. So, maybe expanding
frozen? 
>> MATZ: Yeah, maybe we have syntax to create
a JSON‑linked tree using the immutable hash
or something. We are not having any good
idea with expression to create that kind of
tree. 
>> EVAN: Okay. Whoever submitted this question...
>> MATZ: We are welcome to proposals.
>> EVAN: Is there a good way if someone has
a proposal that they want to submit to Ruby
Core, is the best way to write it up? Or
is it to submit a patch first? What do you
think the best way to submit a proposal like
this? 
>> MATZ: Submit to the issue tracker with
the bugs to rubylang.org. So, having a pull
request is good things, because we can ‑‑
we can't tell the exact behavior, the original
proposal intended. But we might not take
the exact pull request. If you can describe
the basic ideas, feel free to submit in English...
or Japanese.
>> EVAN: Or Japanese. Okay. This gentleman...
>> MATZ: Actually, English is preferable because
of the very fraction of the community can
understand Japanese. 
>> EVAN: Okay. 
>> Hello Matz. First, thank you for bringing
pattern matching into Ruby. That's really
exciting. And I'm wondering if there might
be plans for the future to add pattern matching
like Elixir at the function level. Right
now you can do case_in. And in Elixir, you
can define multiple versions of a function
with different parameters or conditionals. Right
now if you define a method in Ruby, again,
it overwrites the first one, so there would
need to be some changes. Is that something
that you see valuable or possible in the future? 
>> MATZ: Yeah, in Elixir, we have the multiple
version of the function and you can dispatch
it according to the patterns. We already have
had optional argument or something like that,
so it is quite difficult to have the overwriting,
overloading methods in Ruby. So, I don't
think it's impossible, but it's quite difficult
to add the overloading method in Ruby so it
might take time even if it's possible. 
>> Thank you. 
>> EVAN: Aaron. 
>> MATZ: Oh, you. 
>> So I noticed in Perl 6 now, they use emojis
for some operators like atomic...
[ Laughter ]
Would you consider adding emoji operators
in Ruby? 
>> EVAN: Can I expand it to just be Unicode
operators? 
>> Yeah, yes! Yes! You can! Ha ha! 
>> MATZ: Actually, we Japanese long for so
many characters. And why you guys want to
be suffered. 
[ Laughter ]
>> Because they look cool. 
[ Laughter ].
>> MATZ: You have to pay the price. I know
that. Yeah. Not soon. 
>> Okay. 
>> EVAN: Maybe ask another interesting question
which is not necessarily all the way to Unicode
operators, but one thing that's interesting
about Ruby is that the set of operators is
fixed. Whereas you have a lot of languages
where you can sort of have this arbitrary
operator out there. Would you ever consider
having arbitrary operators rather than just
the fixed set that we have of, you know, greater
than and less than, spaceship and that stuff? 
>> MATZ: Yeah. In some languages you can
add arbitrary combination of characters as
the operators. Like Haskell and Scala. In
some languages, the new operator needs to
fall into some particular format like sometimes
the operators have to be surrounded by the
percent or something like that. 
And the ‑‑ I think the formal makes your
program cryptic. It's like a macro, and for
the same reason, I don't want to add that
kind of things into the language. The latter
ones, adding new arbitrary operator within
a certain format, it's possible, but we are
lacking characters. I don't know how we describe
the new operator. But I think the latter
has slightly more chance. 
>> EVAN: Trying to figure out how do you express
precedence rules is also hard. 
>> MATZ: Yeah, in some other languages has
the same precedence for that newly added operators. 
>> EVAN: That makes sense. Yeah? 
>> So, especially because so many people here
are new to programming or relatively new to
programming, what advice would you give to
people who are interested in making their
own programming language? Or, you know, would
you encourage others with making their own
programming languages like you did with Ruby? 
>> MATZ: Uh... so there are several books
on creating programming languages. And some
of them are very good book. But unfortunately,
those book focus on implementation of the
language. So, there are very few books ‑‑
probably no books for focusing on the design
of the programming language. 
Actually, a few years ago, I wrote a book
about designing programming language, but
it's in Japanese and translated into Korean
and Chinese. So, if you do speak those languages,
that's okay, buy my book. 
>> EVAN: Maybe we should get it translated
into English, then. 
>> MATZ: Yeah, probably. 
[ Laughter ].
>> EVAN: Makes note...
>> Thank you. 
>> Sorry. I'm live tweeting random things. So,
the dot colon operator. I dearly miss it
and I would like it back. It was shorthand. So,
a lot of us who tend to have more of a functional
bent, we were fond of that operator and sad
to see it go. Though with as many admittedly
evil things that we did to the operator, we
kind of understand why. 
>> EVAN: Maybe explain what it did. 
>> MATZ: The dot colon operator ‑‑ to
retrieve the method object from the object. So,
that object.call on foo takes the foo method
object from the object. We have to do that
object.method with the symbol foo or something
like that. It's kind of indirect. By using
dot colon operator, you have to retrieve the
method object directly from the object. 
There are terms named list 1 and list 2. List
1 is a list language like Ski and Scala and
Python. And .object or .name notation retrieves
the corresponding function or method object. And
then the other language, like object.foo calls
the method foo, like Ruby or some other many
programming language is call LISP2. And Ruby
is the LISP2 camp. So, because by using that
kind of notation, so we don't have to add
parentheses every time. So, you can emulate
the attribute access through the method. 
It's better for the object‑oriented programming. But
for functional programming, it is sometimes
better to retrieve the function object or
a method object. Then to emulate the functional
programming in Ruby, it is much easier to
retrieve the method object without those kind
of method direction. 
So that's the reason we want to introduce
the dot colon operator. But we retract the
idea for two reasons. The first one is the ‑‑
three reasons, actually. The one reason is
there's ‑‑ okay. Dot colon operator
retrieve a method object from the object. But
we ‑‑ to retrieve the method object from
the classes, modules, we still have to call
the instance method. Instance method method. Yeah. So,
it's not kind of in consistency and perfection. This
is one reason. 
The second reason is we added some, you know,
features as part of the functional programming,
but these addition is kind of ad hoc. So,
that we believe that it's ‑‑ we have
to take time to design ‑‑ interest the
ground design of the functional programming
in Ruby. So, that's the second and the biggest
reason to retract that dot colon operator. 
The third reason is the dot colon does not
really look like the method retrieval, but
like braille. I don't like that operator's
appearance. So, for those reasons, we retracted
the dot colon operator. So, that means we
reject the idea of the method retrieving method
reference all together, so maybe we will have
time to consider about functional programming
in Ruby. So, as a result, we might re‑introduce
a new operator. And that might happen to
be dot colon. But after the discussion we
are going to have. 
Of course we invite you to join the discussion. 
>> EVAN: Did we get to your question? 
>> Yeah, I would say that's perfectly fair. Yes,
we did very bad things with it and you want
to be careful introducing those things because
we horribly abuse them and write blog posts
and probably give conference talks about them. So,
I apologize. So, I appreciate that you are
considering this because once they are in
there, they're very hard to not have in there. I'll
very much be contributing to this discussion,
and anyone else who is interested in this,
I know others were, I would like to have them
participate in some of these discussions as
well. And I believe they will. Thank you
for taking the time and being considerate
about those. 
>> MATZ: Thank you. 
>> Dear Matz. Over here on your right. This
other mic, Matz. So, in some far‑off, distant,
but inevitable future where you're no longer
able or no longer interested in being the
sort of driving designer of Ruby, have you
thought about what ‑‑ how the language
design will move forward after you? In this
future, there's still lots of people using
Ruby, of course. 
>> MATZ: Yeah...
>> EVAN: Less morbid. Have you thought about
retirement? 
>> MATZ: Actually, the Python creator retired. That
made me thought about my retirement plan in
the future. But he is nine years older than
me. So, we can stand for next nine years
or something. 
The Python community formed the board of design
or something with the five members or something. By
voting. Yeah. But I'm not a true believer
of the democracy in software. 
[ Laughter ].
>> EVAN: You don't necessarily want four people
painting a picture. Sometimes you want one
person. But I think, like, have you thought
about what it would look like? I know you
have a lot of people who already do lots of
things. 
>> MATZ: Yeah. Okay. 
>> EVAN: We're not trying to put you on the
spot, either. So...
>> MATZ: Okay. Year 2025, six years from
now, I will turn 60. Probably I am having
a year off. So, that community can stay,
so probably I will name some kind of successor
or replacer at least for a year. And then
after Ruby 3, we have some kind of designing
practice things for my successor candidate. And
after that, I might name one of them to be
my successor. 
>> EVAN: Okay. Yeah. That's good. 
>> MATZ: It's a big plan. We have years ahead. 
>> So the future is still there's a single
author of the language? A single designer? 
>> EVAN: You still want to have one person? 
>> MATZ: Yeah, because sometimes the committee
thinks or the, you know, the community ‑‑
the design decision could be irresponsible. Okay. I
don't care about this feature, so, okay. Either
follow the other ones or something like that. So,
that makes language less consistent or something
like that. So, I still believe the language
should be designed by the very one particular
person to make decision and take responsibility. 
>> EVAN: Yep. Over here. 
>> Yeah. So, about eight years ago, you filed
an issue on the Ruby tracker about autoload
and possibly wanting to remove it. It got
closed earlier this year. I was wondering
what went through your mind over the past
so many eight years behind your opinion of
autoloading and its use and should we use
it as much as we do? And generally your opinion
of it? 
>> MATZ: I still don't like the autoload. And
I want to remove that from the language if
possible. But the impact of the removing
was far bigger than I expected. So, you know,
I don't want to punish the community because
of my preference. That's the biggest reason
I changed my mind. 
>> How do you see the relationship between
the automated tests and the typing in programming
languages? Do you think having one reduces
the need for the other? Or do you think they
can work together? 
>> MATZ: No. By using static typings, we
find more errors at the compile time so that
we don't have to code very silly type tests
like, you know, assert type things in a test
so that we can reduce the assertion from the
tests. But the ratio of these kind of type
assertion silly tests, they are relatively
smaller in the test so that we might ‑‑
we have to pay more attention to the logic
in the tests. But you know, these silly things
can be omitted in the reference state. So,
having static testing, static type checking
increase the quality of the software, I believe. 
>> Thank you. 
>> EVAN: Yeah. 
>> So during the keynote, you mentioned how
I/O concurrency how you regret adding threads,
and you were interested in using fibers as
a solution. And you mentioned the async gem
as well. And I was wondering if you could
elaborate a little bit on what you think the
future of concurrency in Ruby is. 
>> MATZ: This is difficult because of the
states. We have nothing to guide the concurrency
structure or architecture. But by using the
guilds or the fibers, we can reduce the burden
of the concurrency for one thing. 
As I explained in the keynote, the isolates
can be considered as the web workers in JavaScript. So,
again, you can offload that long‑running
task into ‑‑ separate the native threads. And
it is independent name space so that you don't
have to worry about the shared state or something
like that. You can communicate via channels. And
then for I/O multiplexity, this is very much
important. For example, with node.js is single
threaded, but it's still fast because these
kind of quick I/O multiplexing. And we want
to provide that kind of feature. 
We reduce the cost of the context switching
of the fibers using sometimes assembler or
something like. The context switch something
reduced dramatically into six to seven? Yeah. Then
we are going to introduce the core of the
async gem into the very core. Actually, a
core part of the async gem into the Ruby core. It's
kind of confusing. 
And then the other part is still defined in
the async gem. So, that we can use the, you
know, I/O multiplexity without marking. 
>> So would that mean like there would be
async versions of the HTTP? The existing
core library? 
>> MATZ: Yeah. We are going to have the async
version of the database access and the socket
access and the file access or something like
that. 
>> Cool. Thank you. 
>> EVAN: My follow‑up question there is,
having a lot of async stuff makes it harder
for people who write C extensions, because
you have a C extension that is kind of expected
to live and do its thing. I don't recall. Can
you save a fiber through a C extension frame
right now? 
>> MATZ: Yes... on some major platforms, we
use the stack switching so that you can keep
the C extension stack frame, even though we
can't. 
>> EVAN: Okay.
Yeah. 
>> What is an upcoming change or addition
to Ruby that you are personally most excited
about? 
>> MATZ: The most excited one is the pattern
matching. So, it will open up a whole new
world in Ruby programming. It's still experimental,
and it's still slow, but its expressiveness
is very dramatic. 
>> Yeah. You talked a lot about things that
are coming in Ruby 2.7 and Ruby 3. Have you
thought about any features or modules that
you could remove in Ruby 3 or Ruby 4 without
having a lot of issues with backwards compatibility? 
>> MATZ: Well, so we still have the very old
modules like, you know, the Singleton module
or ‑‑
>> EVAN: Grieve.
>> MATZ: English. Those kinds of things can
be removed in the future. And actually, we
made them in a bundle gem so we can remove
them gradually. 
>> EVAN: All right. I think I'll ask you
a couple of quick questions here at the end,
non‑programming ones. One person said you
work on this every day? Do you get tired
of it? Do you feel like you get burned out? Do
you do anything? How do you cope with that? Do
you just take time away from it? Do you have
something that you do? 
>> MATZ: Actually, I have no obligation. I
am hired by Heroku. And thanks to Heroku. I
have no assigned job. So, I can do whatever
I want in Ruby. And I spent some of my time
as a language designer, so make decision of
the language change, language future. The
other part is as a programmer, so I implement
mRuby. So, yeah, when I get tired of the
designing language, I go to as a programmer. And
then I implement some new features of mRuby. Then
I get tired of the C programming, so I go
back to the designing the language. And if
I tired of both of them, so I go out. Yeah. Read
a book. 
>> EVAN: So you switch back and forth to keep
yourself fresh. I will ask one bonus question. We're
just at time, because I had forgotten to get
to this. Someone asked if there's a future
where MRI and mRuby kind of merge together
or are they always going to be separate? 
>> MATZ: I think they will always be separated,
because that first priority is a little bit
different. CRUBY, the priority of CRuby is
being the canonical implementation. So, every
new feature is implemented in CRuby first. And
then the other implementation like JRuby,
etc. So, in addition, CRuby focusing on the
performance of the server side, especially. And
then you also work usable as a scripting language. But
JRuby is focus on the big server process. And
for that case, JRuby is unbeatable. And mRuby
is focused on the smaller devices and reducing
the memory consumptions and something like
that for that purpose mRuby is the winner. For
that reason, so every different implementation
has every different domain to live. So, we
are not going to merge them into one. 
>> EVAN: One last bonus question. Someone
wanted to know how your dog is doing. 
>> MATZ: Yeah. Thank you. Two months ago,
my dog lost. It's gone. And yeah, but don't
worry. 48 hours later, we found him! Yeah. Actually,
he just disappeared from my backyard. No
one ‑‑ my ‑‑ the fence was shut. So,
I don't know. There's no reason to escape. But
he disappeared. But two days later, the police
called me and my neighbor, 200 yards away,
who found the dog and called the police. Yeah. We
found him. 
>> EVAN: Well, great. Thank you, everybody. Thank
you, Matz for your time. 
>> MATZ: Thank you. 
[ Applause ]
