The Changelog: Software Development, Open Source - 23 years of Ruby (Interview)

Episode Date: May 7, 2016

Big show! Matz, creator of the Ruby programming language, joined the show to discuss where he began as a programmer, the origins of Ruby, its history and future, Ruby 3.0, concurrency and parallelism, Streem, Erlang, Elixir, and more.

I'm Yukihiro Matsumoto, and you're listening to The Change Log. Welcome back, everyone. This is The Change Log, and I'm your host, Adams Dekovic. This is episode 202. It's a big show. Yes, years in the making. Jared and I spoke with Matt, the creator of Ruby. We talked all about Ruby. We corrected the title. We were going to call this 20 Years of Ruby, and we had it wrong. It's actually 23 Years of Ruby. We talked to Matt about its origins,

where he came from, naming Ruby, where it's going, where it's been. Everything you think you want to know from Matt about Ruby is in this show. We've got three awesome sponsors, TopTal, FullStackFest, and our friends at Rollbar. Our first sponsor of the show is our friends at TopTal, an exclusive network of top freelance software developers and designers all across

the world. Top companies rely upon top, top freelancers every single day for their most mission critical projects. And if you're listening to this show and you're a Ruby on Rails developer looking for greater flexibility in the projects you're working on, or you're looking for a community to belong to, or you'd just like some help thinking through a problem as you work, I highly encourage you to check out TopTow. You'll have a constant stream of top Ruby on Rails jobs to choose from. You'll have the flexibility to choose the projects you work on, and you'll have a constant stream of top Ruby on Rails jobs to choose from. You'll have the flexibility to choose the project you work on, and you'll have the freedom to set your

own schedule. You'll get featured on the TopTal engineering blog, which we often link to in ChangeLaw Weekly. You'll get support for speaking at conferences and attending events. Head to toptal.com slash RailsJobs. That's T-O-P-T-A-L.com slash RailsJobs, all one word. But if you'd like a more personal introduction, email me, adam at changelog.com. I'd love to help you take your first step with TopTile. And now, on to the show. All right, we're joined today by Yukihiro Matsumoto, also known as Mats. Now, if you don't know Mats, you must be under a rock.

But let me tell you, Mats is a Japanese programmer, best known for his work as the chief designer of the Ruby programming language. And he's also known for its reference implementation, Mats Ruby Interpre interpreter, MRI. And Jared, this show for us is literally years in the making, quite literally 20 years. Our roots are in Ruby. Our audience knows our roots are in Ruby. But to have Matt finally on this show,

what do you think about that, bro? Well, I'm pretty excited. Matt, before the show, said he was nervous. And I think we're the ones that should be nervous. Yeah. Quite an honor to be joined by you, Matt. And thank you so much for the Ruby programming language, which is something I use daily and a language design that I compare other languages to to see if they measure up. So thank you for joining us and thank you for Ruby.

Yeah. Well, without further ado, Mats, welcome to the show. Yeah, thank you for having me. So Mats, I guess the best place that would make sense to start for you

and something that, you know, Jared, again, I got my mind blown before the show and I got to let the listeners know because Mats is a listener of the changelog. I couldn't believe it. Yeah.

Isn't that awesome? So cool. Now, Matt's as a listener of the show, you must know that we love to dig into the history, the past of someone. So someone like you who comes on the show, we have to know where you come, where you came from. So take us back into your story where did things begin for you to become a software developer become a programmer where did things begin for you uh that's a very old story so when i was in high school, maybe in junior high school. My father bought me, actually bought himself a pocket computer,

like the desktop calculator with a keyboard. That was basic. So I was 15, and then I took his computer and started programming. I was pretty interested in programming. That is my beginning of programming career. So that was about 1980 for you. Is that right? Yes.

Give or take. So what was it about this device, this opportunity that made you think, I could do this. I could make something on this. I could make my living doing this. This excites me. No, I didn't think anything about the job or working at that time, the programming interested me very much just because I can order computer or I can train computer do things I want to do. If I was interested in programming, I can program or train them to work for me. Right. Yeah.

You were in control. You could make it do what you wanted to do. Yeah, I can control computers. You know, it's make me feel like I train computers like a dog. Like, you know? Yeah. You heard it here first, everybody. Matt trains computers like he can train a dog.

That's awesome. I've tried training a dog and failed miserably. So I think computers might even be easier than dogs. Yes. My dog does not listen. I tell him to be quiet and he just keeps asking for the door and wants a bone. He's relentless. Computers, they don't talk back and get angry.

I guess they kind of do whenever there's an interpretation or know interpreter or something like that yeah computers are much easier mind dogs are bad too so what was your first steps then was was uh was your first steps tinkering was your first steps picking up a book you know what was your entrance into feeling like you can actually do it not so much getting excited about it but but learning yourself to teach. And as you said, control a computer. Yeah. The pocket computer was awful just because,

you know, it was only 400 steps of the capacity so that we can only type in the maximum 400 lines of code, basic code in that computer. Besides that, they have a variable, no local variables, just global variables, and the length of the variable name is only one, so we could have only 26 variables. Then I type in some sample programs out of the reference to the

computer and I modified it like a small game of the, you know, the hit and blow or some kind of the number calculation something. The environment was very, very, very limited. So I started to feel some kind of frustration soon after I programmed in that particular computer. So it was really the frustration, the lack of usability that got you excited. Because like anybody, you want things to be easy to use. You want them to be enjoyable. And computers for you was lacking that. And you felt like you can fill that void. Yeah.

But at that time, I didn't know about anything about the other computers. So I just kind of felt frustrated, but I didn't know what is the source of my frustration. So then I came across the book named Introduction to Pascal Language. So I bought that book and then I studied about the Pascal programming language.

It was some kind of enlightenment for me just because, you know, this language, Pascal, kind of freed my mind. You know, my recognition, my cognition of the programming is very limited to the basic before that. But I thought Pascal had everything, like local variables, recursive calls, and the user-defined data structures, and, you know, yeah, everything. So that was the first time I started having interest in programming language in general.

What came after Pascal? So I started to read books and magazines about programming and the programming language. So then I came across Lisp, Smalltalk, and some other programming languages like Logo. So then these programming languages are pretty amazing for me. But back then, I didn't have the computer

that runs that kind of the great programming languages. So I just read the book and studied about them. But I really wanted to programming in it it in them but uh i couldn't that is kind of a frustration so you're just you're just reading books about lisp books about small talk but you don't even get to try to use these languages no the computers are very expensive back then i always find it interesting jared whenever we have someone on the show that that has such a history with i i guess going through the hard days is all i can think of to describe it because it's the days whenever uh who was our most recent guest he made

the keyboard because that's what he had to do to get to the next step. Yeah, Richard Hipp from Sequel Light. Yeah, which is a show that isn't quite out yet. But if you're listening to this, then it's out. So go listen to it. Episode 201. But this is a case, too, where Matz is loving and desiring to program but can't. Because access isn't quite there. And so I guess, Mat guess mats what did you do to

to get access what's the next step for you there uh through reading the books about the computer programming languages so the i found out that every programming language was designed by a human being you know that right that Right. That means, you know, we don't know who designed English nor Japanese. But we have, for example, John McCursey for Lisp or, you know, Alan Kay for Smalltalk.

So the programming language was designed by a specific person or group of people. And they had intention or ideas for their programming languages. So when I was in high school I was pretty much interested in programming language and even though I didn't have any chance to programming in those programming languages in reality. But I'm really, really interested in programming language, the concept of the programming language.

So I just wanted to create my own programming language when I was 17. It's pretty profound that you have that perspective because I didn't think, well, I don't know who, and Wikipedia won't tell me me who invented the English language. So I never really got curious to the point where I'm like, well, if someone designed it, then I could do it. So I never, I don't, I don't know if I've had that perspective that you, that you have. It's interesting that you come to that conclusion on your own. Yeah. So you're 17 years old. It's about 1982

if my math is correct. Yeah, around that time. At this point, you've used BASIC and you've used Pascal. I didn't use Pascal. But I knew Pascal. Oh, okay. So you didn't even

use Pascal. You just learned it. So only basic so far. Only basic. Only basic back then. And you have this kind of a wanderlust or a desire to not just try these languages, but to learn about them, even though you can't use them.

And you want to write your own language at age 17. Yeah. Did you attempt a language at that time? You know, it's prior to the internet age. So I didn't know anything. So I didn't have any experience on programming. I didn't have any knowledge for the, you know, compiler writing or anything.

So I took my notebook and write down programming in my own programming language. Awesome. On papers. Do you still have that notebook? That was my question. I was like, do you still have that? Unfortunately, I lost that notebook.

Oh, man. You could compare it to Ruby and see how closely you ended up creating. Yeah. Something like that 17-year-old wanted. I vaguely remember that was kind of like a Pascal. But I saw some kind of the influence from Lisp. I think it was kind of the combination of the Pascal and Lisp. So we're not quite to designing Ruby yet. And obviously

this show is about painting the history of this 20 year rich history of the Ruby programming language. So of Basic, of Lisp, of Pascal, what was it about those languages that got you excited? Like what specific

features, what specific things even if you couldn't write them you can read them and think about them in your mind so the from pascal i learned a lot from the the language programming language features can help programmers like a you know the old basic i used was a very limited it didn't try to help programmers. Like the limitation in the number of the lines of code, limitation of the number of variables. They couldn't have any user-defined function.

They didn't have anything but a few lines of BASIC code. So compared to that the Pascal language tried to help programmers to be effective. So that kind of attitude influenced me a lot. So the programming language should help programmers. Then Lisp. So when I read about Lisp, I was very surprised by the consistency of the language. So the Lisp language was made up of the very few concepts, like a list and some atoms. Then everything was combined out of those small number of concepts. So that kind of the consistency or extendability surprised me a lot.

And obviously Smalltalk had a huge influence on Ruby. Yeah, but back then, it was early 80s, so the material about, information about the small talk language was very limited back then. So I studied about small talk mostly in my university ages. Is that when you gained access to actually start using some of these languages at university? Yes. So did you study computer science, or what did you go to school for specifically? So in 1984, I went to the university called Tsukuba University in Japan. So I majored in computer science. So finally I got access to the real computers and I started programming and also the university has a huge library so that they can access to the books and the materials and the papers about the computer science.

So you know finally I got access to the information of computer science. That must have been like heaven for you. Yeah. It's in your, in your, really, it was a heaven. What I find interesting is that,

uh, there's roughly, uh, based on some notes, Jared pace it to me is roughly 13 years difference between the day or roughly the year from what wikipedia tells us is in the mid 90s so assuming 1995 1996 uh ruby being created so there's roughly um you know 13 years between your original age or roughly 15 to 17 when you know when you're kind of painting this picture that you just share with us so there's 13 years between that time.

You went to school and you learned a bunch of interesting things and all of that stuff. And so we're obviously here to talk deeply about this history of Ruby. So I want to tee that up real quick before we take our first break because when we come back, we're going to dive into some more details around those 13 years and then specifically get into the origination, the date, the timeframe of Ruby and what the original problem was and those types of things. So we'll take our first break and we'll be right back. Rollbar puts errors in their place, full stack error tracking for all applications in any language.

And I talked to Brian Rude, the CEO and co-founder of Rollbar, deeply about what Rollbar is, what problem it solves, and why you should use it. Take a listen. How do you build software faster? Like, how do you build better software faster? And there are tons and tons of aspects to that. And Ruby is like, you have a better language, you can have better frameworks that help you be more expressive and more productive. So the flip side of that is like,

after you've built something that works, or at least mostly works, how do you go about getting it from working to in production and actually working? How do you cover the edge cases? How do you find things you missed? How do you iterate on it quickly? And that's kind of where what we're trying to do comes in.

So we're trying to say, after you've shipped your software, you're software you're not done you know you saw there's still work to do and we want to help make that process of maintaining and polishing and keeping things running smoothly be really really really easy so developers spend roughly half their time debugging right so anything we can do to make that process better is going to have a huge impact all right that was brian ruse ceo and co-founder of rollbar, sharing with you exactly why it fits, why it works for you. Head to rollbar.com slash changelog. You get the bootstrap plan for free for 90 days. That's basically 300,000 errors tracked totally for free.

Give Rollbar a try today. Again, head over to rollbar.com slash changelog. All right, we're back from the break. And obviously, if you're listening to this show, 20 years of Ruby with Matt is like link bait, right? You're going to listen to that show. Even if you've never programmed Ruby before, you want to listen to the show

because Matt is such an influential person in software development. Already, Jared and I have been enjoying Matt's story, how he got into programming and his journey through BASIC, Pascal, and Lisp. But ultimately, he got to a point where he was just maybe frustrated even further with usability and decided he can create his own language because you can do that. And so, Matt, Jared and I have been trying to dig

and figure out when Ruby was created. And Wikipedia says mid-90s. Can you help us with a citation? Like, when was Ruby in your eyes? When was Ruby officially born? So what can we call Ruby's birthday? The birthday of the software is not well-defined, just because

unlike human beings, the software is not very form. But software, including programming languages, do not have any physical entities.

So the logic or concept are very crucial for the existence of software so in that sense the name is pretty important for software right so the yeah in programming so if you name some concept in a very good name or right name, your design is guaranteed to succeed. So I value names date I name Ruby, Ruby. Okay. As a birthday of the Ruby programming language, which is February 24th, 1993. So we're actually 23 years. 23 years of Ruby.

Yeah. So we got our title wrong. You know, hearing that, thank you for sharing the official date with us. So February, was it 23rd or 24th? 24th. 24th. February 24th, 1993. You named it Ruby. Has anybody ever asked you what the significance of the name Ruby?

Like, where did Ruby come from, the name Ruby? Why is that? Since names are so significant to you, why that name? Oh, it's kind of like a coincidence. Like when I decided to create my own programming language, that I will tell that story later probably. Yes. But when I decided to name my programming language,

I wanted to name it after the name of the jewel, just because we had pearl. Back then, I talked with my friend about the concept and the plan. So, several names come up with the name of the programming language, my programming

language. These were like diamonds and spires. But those names are so long and quite difficult to type. So after examining a few programming, a few journal names, we picked two candidates. The first one is Ruby. The second one is Cora. But I talked with my friend and the Ruby is shorter and the Ruby

Jewel is more beautiful. So I picked the name Ruby. So it's based on beauty. And it's based on in theory, easiness because it's shorter. Not so much its length, but it's easy. It's much its length, but it's easy.

It's easy. And after that, we found out the Pro is a birthstone of June, and the Ruby is a birthstone of July. So it is a good name for the programming language, which succeeded, which came after. But it was just coincidence. Just coincidence. So your next language will be the birthstone of August.

Aquamarine? Now I'm googling for birthstone of August. Para... Ooh, not easy. Parado. Paradot. Not as good as Ruby. No.

So you had a name. It was 1993. You had some influences, including Lisp. Smalltalk. Lisp. Smalltalk. Perl, of course. You talk a lot about how every programming language is created by a person.

And you also talk about how when you design a language, you design for specific things. And the big idea around Ruby, and correct me if I'm wrong, but it's this idea of designing for the programmer or programmer happiness around this idea of joy. Where and which was avant garde for sure at the time was quite almost revolutionary, you might say, with how popular Ruby eventually became. So where did that notion come from? Where did that influence where you said, let's optimize for programmer happiness? How'd you think about, how'd you think of that? Actually, I confess that I didn't think that at the beginning.

Oh, okay. So some programming languages are designed with specific purpose, like a basic and a Pascal as a programming education or C for system programming, like writing Unix operating system. Or a small talk, like it was a prototype of the future programming environment or something like that. But unlike other programming language, I didn't have anything specific in my mind. You know, I told you that I just wanted to create my own programming language. Right. But as a programmer, I wanted to use my programming language.

So as a programmer, my daily job is writing some kind of C language for main project, and then like some pro script or shell script as a side task. So writing some kind of scripting language could help me use my programming language for my tasks, like a kind of dogfooding. So I picked scripting language for that purpose. I didn't think of solving my specific problem or anything like that. I just wanted to create my own programming language.

I love that. Like it was a very pure desire. It's like, I just want to create a language. Yeah. At the same time, I wanted to have fun with designing and implementing or using my programming language. So at that time, I didn't focus on the effectiveness or productivity of programmers in general. I focused mainly on my joy in programming and designing of my own programming language. So that gradually leads into the programming joy of the programmer in general

all over the world. I was just going to say that it makes a lot of sense that you ended up creating a language around enjoyment and joy and programmer happiness because you weren't designing for specific use cases like you mentioned with C or another language or Perl with like Perl's whole purpose was text extraction and reporting. Right. And so it had that very practical goal. But your goal was to just enjoy making a language that you would love. And so what fell out of that was a language that is enjoyable to use. Just makes sense. See, I would say the opposite. I would say that that's like a kind of a happy accident. Yes. You know, because he said he was he wanted to dog

food it but it wasn't uh you know top of mind and in the fact that like this is the main thing you want to do but he wanted to be happy creating it and so just yeah it seems like it's a happy accident to to get there although it does make complete sense that's what should come out of it right so you mentioned lisp and how you liked how small lisp was and its concepts and how consistent it was um you mentioned small talk and pearl and when you were originally designing ruby were you actively thinking about your use of these other languages or the things that you like and just you know, quote unquote stealing those into Ruby?

Was it how do I say it? Were you actively taking features from Perl that you like and saying I want those in Ruby or was it more of an indirect influence on the language? So when I decided to create my own programming language,

so I had been a big fan of object-oriented programming for years back then. So I wanted to apply the concept of object-oriented programming to my programming language. So, and back then I was a C programmer, so I wanted to feel comfortable as a C programmer when I using my own programming language. And I wrote many shell scripts and some Perl scripts.

So I want my programming language to replace those languages, like Shell and Perl. So in combination with these, the idea of the object-oriented scripting language was gradually formed. So I took some kind of the Lisp interpreter and then put some class libraries out of Smalltalk and then picked the features out of Perl and chopped into the methods and then reorganized into the class libraries.

In that way, I gradually designed my programming language named Ruby. So you named it in 93. By 1995, you had a public release. Yes. I'm trying to figure out here if this was your 1.0. Yes, it was. Ruby 1.0.

Oh, I'm sorry. Ruby 1.0 was 1996, it was. Ruby 1.0. Oh, I'm sorry. Ruby 1.0 was 1996, if Wikipedia is correct. 96, yes. So let's talk about that. You've fully formed this idea, right? You've given birth, so to speak,

of a concept and working code for a 1.0 release. What happened next? Were people using it? Did you announce it somewhere? Did you keep it for yourself or did you put it out into the world?

And what did people think? Yeah, soon after I started project in 93, virtually no one knows Ruby, just because it was my personal project. And only my few, a few close friends knew about the language and they helped me to try my baby programming language. But the implementing a programming language kind of took time. It took six months

to do simple Hello World for me. I started in February. The simple Hello World worked on August. Writing Hello World program in Ruby is, you know, kind of one line of code and then it took us maybe 10 seconds or something but implementing language to do hello world is kind of huge task i needed to implement string object so i need a string class and to implement string class we need the object class to inherit and the whole object system and the whole messaging system. And then to call print, we need the access to the standard IO.

And then we need to object, we need to, I needed the object by the standard IO or something like that. But that took me six months to do simple Hello World. Reminds me of that Carl Sagan quote about making an apple pie from scratch. You must first, what is it, create the universe? Yes.

Sounds like you had to create the Ruby universe in order to have a Hello World from scratch. Indeed. So how long before other people started to use it? Until December 94, virtually no one used Ruby, but two other friends. But in 94, I passed some small message to the Usenet, which NetNews, which we had to communicate to others

on the internet back then. I don't know. I don't remember the exact number, but 10, 20 people were interested and formed a mailing list. And they advised me in the very early stage of Ruby to these kind of the communication and discussion. So Ruby design of Ruby,

design and implementation of Ruby got better. Then I passed the whole Ruby source code into the internet, December 21st, 1995. So I guess once we're getting to more and more users, what do you feel like is roughly the time you feel like Ruby was really adopted by the programming world? When was it that, and what was it like at the time for people to really start using it? Not just, and I don't mean it in a negative way,

20 or 30 people, but a lot of people. What was, when did that begin? Yeah. Soon after I passed it at the South Coast of the Ruby, so I formed the mailing list. Right. And then two weeks later, we had 200 members of the mailing list. Right. And then two weeks later, we had 200 members of the mailing list.

So that is kind of number. Yeah. So I was surprised. So, you know, after seeing, you know, unknown programming language from nobody, so nobody knows me back then. So, but I'm interested and joined the mailing list in two weeks.

That is kind of, you know, surprising for me. What do you think was it that, what was the secret recipe? What do you think was happening the right way to attract people? What was the, what was it about Ruby

that was really getting them? And what languages were they coming from to try people? What was it about Ruby that was really getting them and what languages were they coming from to try Ruby? I'm sorry, but I don't know about secret recipe. But I was so surprised. Only one thing I can think of is the, you know, the Ruby is designed after my preference or taste. Surprisingly, so many other people felt similar way toward the programming and the programming languages.

So that kind of preference invited them to involve in the Ruby community. So in the beginning, Ruby was designed for me, myself, only one person. Right. But surprisingly, so many people, not only in Japan, but all over the world felt similar way and they're interested in Ruby

and they felt joy in programming Ruby. It is so out of my expectation, so far beyond my expectation. It might be a good place to talk about the cultural divide. We have a note here, mainly just around how, obviously, Ruby was written by someone who's Japanese, speaks Japanese as their primary language.

That's you, obviously. But Ruby has played this part in bringing people together from all over the world, you know, the United States, Japan and all over. And you've also got people who speak english primarily learning japanese to break down the cultural divides and be able to speak uh you know your native language and and whatnot can you speak to you know what it's like to have such a an influence i guess on those people like how ruby has bridged that gap between you know, cultural divide, language barriers, things like that. Hmm. Language barrier. Yeah, at least if I were born in

English-speaking country, so my life would be much easier. But at least, so we programmers kind of have similar souls inside of us. Despite the difference of the primary language we speak or the culture we brought up, most of us feel similar way. So we are primarily programmers. So even though I was born in Japan, so you were born in the States or maybe others from other countries, from other cultures, somehow we feel similar way. So Ruby language stimulate common soul of programmers. Right, the common desire for usability,

simplicity, joy, happiness. Yeah, that kind of things. Those are language universal. There's no language. It's to see me have joy is to see me smile, and to see you have joy is the same. You would be smiling. There would be some sort of appearance on you that is language agnostic.

That makes sense. Well, what about things that you like a lot about Ruby? What are your favorite parts of Ruby? You've written so much over these years. What is it about Ruby that really, I guess the easiest way to ask is just, What are your favorite parts of Ruby? You've written so much over these years. What is it about Ruby that really, I guess the easiest way to ask it is just, what's your favorite part about Ruby?

What is it that attracts people to Ruby? As a language, so I like Ruby's extensibility. We have Ruby language, but we can add many things, like class libraries and gems, so to extend the power of the language. So the Ruby language allows us to make Ruby even stronger by adding the classes, like adding objects. So that kind of extensibility I like the most.

The second thing is a part of that, is the block. The block is a, you know, the block is a somehow form of the higher order function, but Ruby provides that things in very nifty way. So that forms that you can extend the method with adding blocks. So I like that kind of things in Ruby. But in fact, the most important things in Ruby language is the community. Since we emphasize the happiness of programmers,

so we cannot live without the programmers. We are not just a language. We are not just a technology. We, the community, is most important for the language. Well said, and I agree with you on the extendability to this day. And I know active support in Rails catches a lot of flack. But the fact that Ruby allows you to write out when you're thinking about a time and you think, well, it was three days ago and you can type in your code three dot days dot ago. Yeah. That's, that's a joy for me.

It's so expresses exactly what I'm thinking and I don't have to conform my sentence into a structure that the language requires of me. I can express it the way that it makes sense. And obviously active support is adding that to number three in that case is absolutely a joy when it comes time to use it. So thank you for that. You know, all these decisions, they have big consequences and sometimes they make all of us smile. Sometimes it makes some of us smile and others of us frown. But they're all trade-offs and no doubt, Matt, you've had some decisions in the language design and maybe even in the implementation that you look back and think,

if I could take that back, I would. So we're not going to ask you now. We're going to ask you on the other side of the break. You've talked about your favorite parts of Ruby, which is extendability, as well as the community, which is so important. But we're going to ask you about any design decisions that, you know, if you had a second chance,

if you're designing that new language next year, you wouldn't put it in. So stay tuned, and we'll talk about that on the other side of the break. Full Stack Fest is sponsoring this show. It's a week-long full-stack development conference, September 5th through 9th in Barcelona. If you haven't seen this conference, check it out. You're going to love it. FullStackFest.com. They have a total of 16 speaker slots open and yes, call for papers are open right

now. They're open until May 14th. So don't wait. Talks are 40 minutes long each, including Q&A, DevOps, infrastructure, UX, browser technology, mobile, backend, distributed systems, machine learning, AI, IoT, wearable technology, robotics, you name it, you can talk about it at Fullstackfest. It's a Fullstack conference, end-to-end, September 5th through 9th, 2016 in Barcelona. Head to Fullstackfest.com. Once again, September 5th through 9th, 2016 in Barcelona, Fullstackfest.com. Until then, Adam from the Changelog sent you. Alright, we're back with Matt. And Matt, we could probably camp out

all day on design decisions. Yes. We don't have all day. We have 20 years to cover, so we'll be moving along, but you mentioned some of your favorite things about Ruby. Extendability, the community. The block.

Is there anything that you regret in terms, yeah, the block, absolutely. In terms of design decisions, whether they were initial or even over the years, that you say, eh, probably not my finest moment. Can you share that with us? The biggest regret was I took too many from Perl. Oh, like some of the global variables,

like the dollar sign, colon, stuff like that. Yeah, magic variable things or something like that. So at the very early stage of designing Ruby, I wanted to create a scripting language that could replace Perl. So I took many things from Perl.

So my primary goal was that everything Perl can do, Perl could do, should be done by Ruby as well. So I took many things out of Perl, but I should have thought that Matt,

thought more about the features I took, just because at that time, my scope is too narrow down to scripting language. Ruby itself is not really a script language anymore. So it's a general purpose programming language, right? Now, so in that way, the features, some features are too specific to scripting. Like, you know, those

special global variable is very handy for the small programs like, you know, the 10 lines of code or something like that. But, you know, once you write bigger code, that kind of magic features

makes implementation more complex or behavior more complex to understand. So I regret the many of them. So those features are gradually becoming obsolete

these days. No one uses the magic variable any longer, but we implemented implementators still support those things. That makes our implementation even more complex

or error-prone. So I regret those kind of features. They're good for golfing, but not much else. Golfing and scripting. Golfing. Indeed.

So you mentioned that Ruby started off as a scripting language in your mind and as it became generally used and generally useful, it's now a general purpose programming language. One thing that also happened in the early 2000s was the advent of Rails, which exploded in popularity, as you well know, and alongside it, Ruby exploded in popularity, moving beyond the bounds of the community that you had built over maybe the first nine or 10 years of Ruby's existence now to a much larger community. So much so that many people look at Ruby as a web programming language and not a general purpose programming language and not a general purpose programming language.

Your thoughts on that perception of Ruby being web-focused as a language? I have kind of mixed feelings. I'm happy with the title of the web programming language. Ruby is very good at web programming thanks to Rails. And then, you know, writing web application using Rails means

the programmers have to write their programs in Ruby. So that's okay for me. In contrast, some programmers hesitate to think about the use Ruby out of web. Like Ruby can write anything. Like, you know, the infrastructure managing like a chef or puppet or maybe some other features.

Like writing desktop application. You can write desktop application in Ruby. You can write script application in Ruby. You can write scripting in Ruby. You can write the infrastructure managing in Ruby. Or you can write even the mobile app or even you can program embedding system in Ruby. So even though I'm happy with the title of web programming language,

but I also wanted to know them, the Ruby can be usable beyond web. Yeah, I think that's fair. And I think many people who learned Ruby because of Rails or came to Ruby because of Rails, any of those came for Rails but stuck around for Ruby. And it won them over even more so than the web framework and they then take it into all the different areas of their programming

needs and like you said, you find it in many places, not just the web. A good example of that though, Jared, is your own personal take on it. Before the show started, I'm not sure if it made it into the audio for the listeners or not, but you had said that Ruby to you is the thing by which you judge all languages. So I'm not sure how Matt feels about that. We'll ask him, of course, but just that Ruby, I'm not sure how you got to Ruby, but maybe that's an interesting story as a side note. But I can imagine it's probably similar.

You came for the Rails, but you got to Ruby and you loved it. And then now it's your barometer. It's the thing you judge all things on to see if it's the language that fits for you. Yeah. Yeah, so I mean, absolutely it is. And as I look around the field and all these interesting new languages are popping up. Matt's as a language person, I'm sure you're keen on many of these. And so I look at each one and I say, hmm, can I write three dot days dot ago in this?

And I use that as a test or can I extend it to even get that kind of a feature? Right. Or that kind of a statement. But, Mats, how does it feel? Because you were influenced by so many different languages. We mentioned a handful of them. Perl, Python, Smalltalk, Lisp. Yeah.

Now you're being an influence. Your language that you designed has influenced Clojure. It's influenced crystal very very much uh elixir groovy um rust swift what does that feel like to have you know created this language that you pulled in ideas from all these other places and now your language is being used as a barometer for quality or as an influence for new languages to be created Yeah, so I have considered myself as a some kind of language Geek or like a wannabe in a programming language, you know as time goes by

surprisingly my masterpiece Ruby becomes so popular mostly thanks to Rails and it started influence other programming language or other programming language designers so that is so honor for me you know I feel like I

now become a member of the broader community of language designer. You're now elite. Yeah. Part of the elite. Yeah, not really elite, but, you know, me a member of the programming language designer community.

So I'm pretty happy about that. Maybe there's an extension to that. So not so much just your happiness with your influence, but while we're here on this topic, maybe a bit of advice. Let's say there's a language designer or a budding language designer or a future language designer listening to the show right now or years from now, and they've got you, someone who's been down a long road 23 years with ruby so far uh studied many languages now part of the elite club what advice would you give back

and could you give back to influence future language designers in a positive way what what advice you may have said some of the things so far, like positivity, happiness, and things like that, but what's one core thing you think you could share with a language designer out there? Few years ago, the Dave Thomas, our Dave Thomas, we have a lot of Dave Thomas's out there. So our Dave Thomas, one of the programmers, told in the conference keynote that the programming is a process of designing a domain-specific language for the application.

So in that sense, every programming is a design of the DSL or API for that particular application. So every programmer is or should be language designers. So take my advice as an old language designer. Mind design and mind psychology. We programmers often focus on technologies. We are human. We are people. So we have minds and feelings. Those feelings influence our productivity or effectiveness.

So when you design anything like an API or language or anything, think about how you or how users feel about those designs. That kind of thing is the key of good design of API and language and the programming in general. So that is the reason I said mind design and mind psychology. I was going to say, we're kind of curious, maybe your thoughts on a few particular languages. You mentioned, I think it was before we started the show, that you had listened to our show on Elixir. And you also mentioned that you're interested in listening to our show on Haskell. Some of our listeners are interested in your thoughts on Elixir as a language and on Go

as a language and any other languages that you find interesting that are up and coming. Could you share your thoughts on those with us? So when I designed Ruby in the early 90s, the computers had only one CPU. So we didn't have to care about the parallelism. We did have concurrency, but we didn't care about the parallelism. So we didn't have multi-call. But these days, everything is multi-call, everything is parallel. So we have tons of computers in cloud. So we have many calls in a laptop.

So now we have to care about the concurrency and parallelism. If I knew about this future, I care more about the concurrency in the design of my language. So in that sense, I'm very interested in the design of Elixir. Elixir is based on Erlang, which is the very concurrent programming language. The key of the multi-core and the better concurrent model. So we are trying to address that kind of concurrency in Ruby 3, but Arlon has long history of concurrency, and they have done very good things in providing parallel programming.

We look up that kind of history and we have to learn a lot from design of Erlang and design of Elixir. For the future of Ruby, I guess, when you know, what you like about Elixir, what you like about Erlang and what you like about Go and their focus now that there is a future, obviously, and there is this now an awareness of, you know, 128 cores and concurrency and things like that, you know, back in nineties when you were designing Ruby, you didn't have that concern. And now there is. What can you say about the path to give Ruby concurrency? What can you say about the future that Ruby has when it comes to concurrency? Mm-hmm. So we have several ideas for future Ruby concurrency. So the first one is some kind of the streaming process, like adding some kind of the pipelines to the language.

And then those pipelines process that data, probably. Those pipelines process data in parallel. And then the other idea is providing some kind of the, you know, the more isolated things than threads. The most bad things about threads is the data

sharing. So the thread can look into the other thread access. Those kinds of shared states is the source of all review. So we could provide some kind of isolated capsule

of the parallel execution. So those capsules can be communicated via like some kind of a channel like the routine has. In that way, so we can avoid data sharing. So we can provide the share nothing model

like a language like Elixir provides. We are experimenting on those ideas right now. So maybe a year or two, so we will decide which idea to pick, and that will, the idea will gradually come into the Ruby 3. So Ruby 3, what's,

I guess anybody listening to that's got to be excited who is a huge fan of Ruby, you know, having a path of concurrency and having in quotes what we've had talked about on the show before that you mentioned Joseph Lim, uh,

having proper support for concurrency was something he had actually had said about his departure from Ruby and his, uh, his desire to create Elixir. Um, there is a path, uh, how,

how far out? I know that it's difficult to project things like that, but is this a year or two? Is it half a year? What's roughly the timeframe people can get excited about for the future movie? So we are open source, so we don't provide any specific roadmap,

but in my mind, I hope it will be released before 2020. Okay. Well, let's... We're getting near the end. We've got roughly 15 minutes left in our scheduled show timing, so let's

go ahead and take a break. When we come back, we have a Slack room for those who support the show, uh, change law members or change logger, as we call them. Uh,

if you're a fan of the show and you want to support us as well, you can go to change law.com slash membership to learn more about that. But you get access to this private Slack channel. And in there, we dropped the message that, Hey, we're having mats on the show today. This is really awesome.

Anybody have any questions and a lot of questions came up around am ruby so we'll go into this break when we come back we'll talk a bit about am ruby and what we can expect from it and kind of some things you can see for the for the future of it and maybe even how you get the the government of japan to sponsor it so that's kind of interesting so we'll take this break we'll talk about that on the other side and also of course We'll be right back. There's no algorithms involved. It's me, it's Jared, and the rest of the ChangeLog team hand-curating this email, keeping up to date with the latest headlines, links, videos, projects, and repos.

And to get this awesome email in your inbox every single week, head to changelog.com slash weekly and subscribe. All right, we're back from our break with Matt's. This is the tail end of the show, Matt, but we've got so much more to cover, so much rich history of this awesome language called Ruby that you created 23 years ago. And, you know, Jared and I, we've been, you know, hosting this show, The Change Log, for a while, and we've had the likes of Go on here.

We've had the likes of Jose Valim come on here and talk about Elixir and air but now will be on air is is maybe any envy that he might have or those who are involved in you know steering Ruby in the right way any envy they might have around concurrency and dealing with you know you know just compatibility and things like that and so Matt, Mats, take it away. I mean, that was a good answer you said in the off air, but say as much as you like here on air about that. You know, I am pretty happy about working with Ruby. You know, it is good language.

Sure, I say that. You know, it's quite challenging. You know, we have to solve many technical challenges and that is quite amusing for us as programmers. So we are pretty happy about working with Ruby, but sometimes we feel frustrated to keep compatibility. So we have millions of Ruby programs out there. So if we make any incompatible change, so that would break so many Ruby programs.

So due to, I don't like that word though, so social responsibility. So we are very conservative to make incompatible change. For recent years, the keeping compatibility is our primary goal of the design and enhancement

of the Ruby programs. So that compatibility things sometimes hinder us to make progress. So in that way, I sometimes envy the other programming language, namely minor programming language, so that they can make big change very easier.

You have a lot of, as you said, millions of Ruby applications out there. And as you said, you have the social responsibility. And so that's holding you back from progress. Sometimes, yes. Which is expected, right? I mean, it's a known fact, right? Once you have baggage, so to speak, and not in's known fact right once you have baggage so to speak and not

in a negative way once you have baggage you must carry that baggage yeah and uh that can sometimes stop you from chasing those new shiny objects but you'd mentioned also that that m ruby is one way you get to to sort of tease that uh that part of you that gets to chase the shiny objects, gets to do something interesting. So I'd mentioned that we have a Slack room with members in it that chime in when we ask them to about, you know, we have a guest coming on and they had some questions around the future of mRuby and things like that. What's interesting, and I guess with mRuby, as it relates back to this tickling of the Envy thing

for you with other languages? So yeah, working on the other things than Ruby, like mRuby is a subset of the Ruby language that targeted to some kind of embedding system, like embedding in applications or embedding in systems and devices. Like, working on that kind of things is quite refreshing. In addition, I have been working on the other toy programming

language named Stream, which is, you know, the Stream language is very early stage, so no one uses it. So it's quite easy to the drastic change. So these kinds of experiences are very refreshing for me. Let's focus on MRuby first. And we do want to have a few questions on stream. But on MRuby specifically, it looks like you started it in 2012. As you said, it's for for embedding whether inside other programs or

on devices what's the status of it is it is it production ready are people putting it on devices and then like does it have a future roadmap or does it just kind of follow Ruby's advancements and keep parity

the status of MRuby is quite close to production-ready. So some companies already use MRuby in their products. For example, a company in Brazil created some kind of payment devices embedded in MRuby. So if that device understands the credit card, debit card, and Bitcoin, then those kind of the systems can be configured using Ruby, so with embedded MRuby.

The other companies in Japan, SIPs, Internet Router, embedded to MRuby, They use MRuby to provide the routing configuration in Ruby or maybe the character user interface using MRuby. Some other companies are experimenting with MRuby to be embedded in DR systems. The examples are, for example, the microsatellites, like satellites with five inches squared, piggyback with the rockets, then go around over the Earth for a year or two. Then those systems is configured by MRB. So when you say rocket, you mean like a rocket ship? Yeah, rocket. Nice.

Okay. I have Adam's attention. Yeah. You say rocket ship, my ears go up. One thing about this in your readme for MRuby, it says this is sponsored by the Regional Innovation Creation R&D Programs of the Ministry of Economy, Trade, and Industry of Japan. Anything to share with us on that, how that got set up, and I don't know, the details of that relationship and why they're supporting it so much? Yeah, I have been working on the local government of the prefectures in Japan.

So Fukuoka Prefecture is one of them. So during the work with the Fukuoka government, they applied the government funded project. So they got granted. The grant was originally designed for some kind of the hardware stuff. So it was quite difficult to explain to them. So they asked us, where did you install those facilities or something like that? Yeah, it is software.

No, no facility. It's not a real thing here, okay. No physical things. Or that kind of things. But somehow we got granted. So with that granted, we organized some kind of things. But somehow we got grounded. So with that grounded, we organized some kind of joint venture. So in those processes,

so we implemented MRV. You know, the most important thing is a deadline. You know, we open source, we usually have no deadline. We do when we do. We do when we can or something like that. So it might take years to implement. So I had the vague idea of implementing

the smaller implementation of Ruby language. But implementing a language processor from scratch is kind of a huge task. So it is quite difficult to start. You know, the

first step is the most biggest step. So that grant forced me to make a big first step. They helped us to make, made me, they forced us and helped us to make a first step. Then after two years in 2012, so we finally made it open source.

So I guess going back to maybe something Jared asked, I'm not sure if we got full clarity, at least it's a little unclear to me, but his question was around the advancement of mRuby and if it's closely tied to, because it's Ruby 1.9 compatible. Is mRuby your outlet for progress as we talked about when it came to the envy,

or is it something different? Is it, is it tied to Ruby's Ruby's progress? Yeah. Yeah. And held back by maybe even it doesn't have that same, that same handicap. So M Ruby itself is the base, you know,

the ISO Ruby standard, so that we cannot make, you know, arbitrary change to the language. In that sense, I sometimes feel similar frustration. But, you know, MRV implementation is subset, so we can drop mobs. So it is held back now, but if you wanted to, you could break away. Is that what you're saying?

Okay. The implementation is a subset of Ruby, so you can avoid a lot of the traps or the things that you don't necessarily think are required to support. Right. But in terms of the language semantics, it conforms to the ISO standard. And so in that way, it is tied to the language.

Correct. Which makes sense because it is Ruby for embedded. So you want it to be the same languages as much as possible. We're running out of time. Let's talk about Stream a little bit. You mentioned influences from Ruby, which makes sense. Erlang, other functional programming languages. It looks like very much the Unix philosophy. Can you tell us, you gave us a brief overview, but give us a little bit more. When you started it, you say it's still just a toy or something

that you're playing with. Do you see this becoming your next big thing, or is it just that outlet to play around? Yeah, just the outlet to play around. So, as a side job, I write articles for the Japanese programming magazines, mag magazine, so about the programming and the programming language. So as a, as an example of that article, so I designed the small toy programming languages based on the idea of the streaming programming. So I named it Stream, double E, S-T-R-E-E-M. So then I put it as a backup.

I put my repository into GitHub. So last year, no, the end of that, December 2014, so almost a year ago. So then someone found my anniversary. Back then, yeah, yeah. Someone put that things into the, you know, the hacker news and it was buzzed so much. You know, it was amazing.

Back then, I had only 200 lines of, you know, the syntax description. So virtually nothing. But it was buzzed. We had a lot of the issues in GitHub. It was not supposed to be open, supposed to be public. But it was just a backup. But then someone found my repository.

You're a victim of your own success in that way. Yeah. And finally, so I got the pull request from the other programmer. So, okay, you describe your language in the article. So I implemented your language. Wow. I only described my language in the article. And I only put the 200 lines of the syntax description,

and the other one implemented my programming language. Yeah. Since then, I modified a lot, but it is still based on the interpreter, the AST interpreter, which is written by the other one the other guy right i guess as jared had said we are kind of run out of time as much as we would love to keep you here matt and keep talking to you about this rich history because it's fun for us hopefully it's

fun for you as well to yeah it was fun you know take the time to to go back and think about man where did i where did this come from? How did I get here? Why am I here? And it's interesting to take that same thing and share that with the listening audience. And as a listener of the show, Matt, which I'm still blown away by, Jared, I can't believe that Matt listens to the show, which is cool. I love that. But Matt, we often ask those who come on the show who their heroes are. And there's, you know, several, several times that, uh,

that you're somebody else's hero. And so generally the question is who's your programming hero, but in this case, who's somebody who's influenced you to be the match you are today to be the you know the the mats that uh that has led mini swana through the ruby and has this you know has this match is nice and so we are nice kind of community that's come and followed him who has influenced you who's your hero that made you made you who you are today? My primary framing hero is Larry Wall, who is a design pro. Not really as a language designer, but as a leader of the community. So he has a sense of humor in his keynotes and he has sense of his sense in the design of program software his works like a patch our end and then Paul all of them are

very helpful to programmers so that kind of attitudes and that kind of sense of humor is my role model. So my primary programming hero is Larry Wall, definitely. You have any secondaries? Alan Kay, who designed the future of programming by providing the object-oriented programming. And then John McCarthy, who provides the idea of Lisp and the idea of the very nifty programming language. Very good heroes there.

Well, Matt, this is a chance for you to share whatever you think you might want to share. Is there anything else that Jared and I may have left out? Any important detail in this 23-year history of Ruby that we might have missed? Anything you want to share that you've got on your mind at all before we close out? Yeah, we are still working on Ruby 3.

We have tons of ideas, but we are still open to new ideas. Like, you know, we worked on Ruby for last 23 years. So we sometimes become narrow-minded. So we need fresh ideas out of the community. So submit any ideas to our issue tracker, bugs.rubylang.org. We may not be able to accept all of them,

but at least the reading new ideas are very refreshing for us. We'll link your Ruby issue tracking system up in our show notes. And that's an interesting thing you said there too, because one other question we tend to end with, which I'll just ask because why not? It's something you kind of teed up in a way,

but feel free to extend it if you like. We ask, how can the community support you, support Ruby? So I guess one way to share ideas through your bug tracker, what other ways, what other things out there are in Ruby that you can point people to? How can people step in and help Ruby see progress? So people

consider Ruby as my programming language. So it's designed by me. So it's designed by a person. But in reality, Ruby has long been a language designed by the community. Of course, I lead them and I make final decisions. But still, so many ideas and so many implementations are from community.

So the Ruby is our programming language. The idea and the use case and the pro request from the community to form the language. So if I haven't had a community, I couldn't make up Ruby. So Ruby wouldn't be Ruby without community. Well, there you hear it. So if you're out there and you're writing Ruby code

and you have some influence or you would like to share some influence back to Ruby, there's Matt's invitation to say that Ruby wouldn't be Ruby without you. So if you're listening to this and you're excited about these 23 years of history of this language and the future of this language, then you can be a future Matt. Either step in and help M.Ruby,

step in and help Ruby, or however, step in and share what you have back to Ruby and back to the community. Matt, I want to thank you so much for, you know, I know English isn't your first language, and I know that it's tiring to speak English as not your primary language, but I really appreciate you stepping out like this and sharing your story in your non-Native language

because there's so many people out there who really care about you and care about your language and care about the future of programming and really appreciate the influence you've had on it. And so to come on this show today and sit here with Jared and I and share what you have, it's just an honor to talk to you like this and to get a chance to help you share this beautiful story of Ruby and this awesome history you have yourself. With that, we're going to close out the show.

So listeners, thank you so much for listening to the show. If this is your first time listening to the show, sad face, go to changelog.com slash podcast and subscribe in iTunes or your podcast app. We also have two emails we ship out. One's called changelogweekly, so go to changelog.com slash weekly. The other one is called changelognightly, and obviously that one's nightly, so go to changelog.com slash nightly. Those are two awesome emails we ship out

that keep everyone up to date on what's fresh, new, and open source. One's editorialized, one is nightly, and sort of the catch-all of everything that's interesting that's happening on github so if you want to catch up and stay up then then uh go ahead subscribe to those but that is it for this show today so fellas let's uh say goodbye goodbye thanks matt bye bye thank you thank you for having me. you