 lucky today because we have not one but we have four Ruby core committers here today and you're going to hear from many of them individually over the next couple of days but we wanted to take this opportunity to bring them all together up on this stage and get a sense of where Ruby is moving as a whole. So it's my very very big pleasure to invite them up onto the stage. Can I please invite the one and only Matz? Let's give him a huge round of course Hiroshi Shibata. We'll be speaking to you tomorrow and the one and only Aaron Patterson with his selfie stick, Aman Gupta who's very graciously joined us today as well. Please have a seat gentlemen and joining me for this panel is Winston the man who brought you this conference. So Matz of course needs no introduction. I'm sure you guys all know who he is. He's the reason we're here today. Shibata-san next to him is a C Ruby committer and he's going to be speaking to us about M Ruby tomorrow. Aaron is a core contributor to both Ruby and Rails. He's a 2010 Ruby hero and he's giving a closing keynote tomorrow and Aman next to me is a 2009 Ruby hero and he's been working on making Ruby leaner, meaner and faster for you. So how this is going to work is we're going to start with a couple of questions for our team panelists and then we will give it over to you guys if you have any questions for them. Okay so maybe what we can do is while we start with the first few questions if you have a question for our panel if you can line up behind the microphones then we'll know to give you your turn at the end of the question. Okay so thank you everyone shall we begin? Sure so to give a little bit of background of why we are doing this panel this year I was sort of inspired when I went over to Ruby Kaigi last year and I saw this Ruby committer on stage and it was overwhelming because on stage they had like I don't know 50 people maybe. Around that I don't know it was like the stage was full of Ruby commuters so I'm like oh can we do something like this in Singapore but it's difficult to you know to get 50 Ruby commuters in Singapore honestly so you know I'm really honored that we have them here today and that's why I thought we shouldn't miss this opportunity especially to interview them about the future of Ruby and what they think about Ruby etc and I hope that you all will find this chance really awesome as well because there's a chance for you to voice out any opinions feedback that you have about Ruby as well to our panelists. Great so maybe we can begin with something a little more simple and this is a question for all of you what are you working on right now what was the last thing you worked on before you came here? Mimi? Let's start with you Matt. Okay I spent my time designing Ruby to make a decision about the language future like accepting proposals rejecting proposals and write a future world map and then at the same time I'm working on as a programmer on M-Ruby and the stream languages. It's already on. Okay so I maintain a lot of websites or like Ruby Rangorg and Ruby CI com and Bronx Ruby Rangorg as an issue trucker so I operate I'm an infrastructure engineer of Ruby Rang and I'm met over C Ruby and R-Doc and Rake and Ruby James and Ruby Beaded so I support to build the issue and synchronizing called Upstream and Ruby trunk. Maybe you can use one of the other mics. Hello. Hi I work on a few of the I maintain a couple of the libraries in the standard library like Fiddle and Psych and recently I've been working on I mean mainly I look at how Ruby works from a Rails perspective so I'm on both the Rails and the Ruby core team so basically I look at how our application runs performs or our Rails application runs and performs and then I think about improvements that we could do to Ruby to deal with that and recently I've been looking at code loading which I'm going to talk a lot about during my talk so I don't want to say too much more. I work mostly on performance so whenever there's we run I work at GitHub so we have a pretty large Rails application and we have a lot of extraneous Ruby code as well so we try to optimize as much as possible on the Rails side but there's times that we need to jump down to Ruby and make improvements there. I am most interested in boot time sort of similar to the work that Erin's been doing but I'm working on a couple patches that are still very experimental but trying to get boot time as fast as possible for our app. That's great thank you so much. So just now in the earlier keynote we have already heard about MADS talking about you know there are other languages out there right now like Go, Elixir, RAS etc that probably you know has some good features that we should adopt for probably Ruby 3.0 but Ruby 3.0 is probably going to be a little bit away from now. More of looking at the whole community in general are you worried that people are moving away from Ruby to to go into other languages? And this is a question for all of you as well so feel free to jump in. Actually it's up to each individual's decision so we cannot say anything but so at least you know we often say the open source community is kind of like a shark so if we stop swimming we will die so we have to indicate to the community or to the world we are alive we are improving we are moving forward so that's the things I am thinking of always. It's in my opinion it's hard not to get worried about stuff like that I think maybe because I spend way too much time reading hacker news. Seriously though because you read it and they're like oh it's one day it's JavaScript the next day it's Rust the next day it's you know whatever so you always think about that but then I remember like well I'm actually building real applications not you know some blog so it's it's difficult to say it's difficult to say for sure I think probably sorry Matt I think probably Ruby's not cool anymore I mean I love I love it I love programming in Ruby it's just I'm maybe I'm not very cool I don't know. Do you guys think Ruby is cool? A little more enthusiasm please come on. It's not it's not cool for hacker news. I agree you know maybe ten years ago when Rails came into the world so though everyone is new to Ruby basically and it it appeared very cool new new things but you know these days you know we have Ruby for a long time so Ruby hasn't changed drastically for a long time so you know but it's how we earn money. I would say that competition is definitely a good thing you know like I'm not worried because it's cool to see all these new ways of approaching programming and we can learn a lot from them and at the end of the day you know like when you're trying to get something done there's advantages to using one thing over another so for instance I maintain the event machine gem and for a long time like Ruby developers that tried to do event programming in event machine had a really hard time because it was a very different way of thinking about stuff and it was very easy for those developers to use a blocking library or use a gem off the shelf and then try to fit that into that machine and those two paradigms didn't work as well and so for me it was actually nice to see people start to use Go or Node.js or other technologies for those applications because they were better suited towards getting those types of things done and that doesn't mean that Ruby is not as good or or any less because you know like for me I write a lot of C I do a little bit of Go but at the end of the day I still think in Ruby and there's certain class of applications where Ruby's might go to whereas there's other sorts of applications where if I am very performance sensitive or I am thinking about getting something done in two megs of RAM then maybe Ruby's not the right solution there and I can experiment with these other things learn concepts there and then bring those back to Ruby to improve Ruby in the long term. That's great. This is a question for Matt's since we're gonna do one for each of you and then we're gonna jump back to the audience and see what you guys have for us. Have you ever thought about creating another new language from scratch so you talked a little bit about that this morning? Yeah, I just created the stream program language last December. It was just experimenting. I had no intention to make it public but as a workplace I put my soul into the GitHub so someone found the repository and then he passed it to the hackaniers. It became cool again. At that time it was the 200 lines of code. It was just a toy. The huge threads in the hackaniers or the reddit and everyone gave a star in the toy program. I had a 3,000 star on GitHub stars and 200 lines of code. That was funny. I thought of the source was the community around some kind of the workable working code. The stream proved it was wrong. It was just quite easy to be popular if the hackaniers found it. To follow up, would you have done anything differently looking back now that you know everything that you know about how Ruby has progressed and now starting this new thing from scratch? As I mentioned in Keynote, 1993 was a totally different situation. We had single core machine and we had very simple programs. If I saw the 2015 back then, I would do differently for concurrency and I would do differently. I would have less inherited from pro as a scripting features. The importance of the scripting features is getting less and less important. Do you think that M-Ruby is sort of something that would solve some of the problems? Some of them, yes. M-Ruby is confirming to the ISO standard we defined in 2012 and it lacks the definition of some kind of the dollar special variables or something like that. Even regular expression is optional. In that sense, M-Ruby is much simpler and smaller. This is a question for Shibata-san. You're using Ruby from a very practical angle. What do you think is the most important benefit that Ruby gives you? Sorry. So maybe the question would be why are you still using Ruby? Yeah, I will be an interpreter. I think Ruby language, so I feel I write Ruby code, so I feel a pun. I think it's the most important thing for Ruby. So he feels his coding when he code in Ruby. So that means if you're working in other languages, you're probably working rather than coding. You know, sometimes we feel we are doing some kind of bookkeeping. Okay. So I feel I wrote some languages, so I feel I'm working. That I write Ruby, so I'm programming. So I feel... So I guess a lot of us probably share the same sentiments exactly, which is why we are all still here. Some from even the first ever read.ruby.com because we all felt that using Ruby is really productive, really fun, which is why we continue to do it even though there might be other languages out there as well. This question is for Erin. A lot of people depend on the improvements that you make to the code and the work that you do every day. And people closely follow what you're doing and what all of you are doing to a certain extent. How do you decide what you're working on next? Oh, dear. Questions. Well, so usually, I mean, basically the way that it works is I take the specific features that I want to do, and then I have a system of levers and coins that I flip. And... No, no. Basically, the stuff that I choose to work on is driven by... Well, it'll either be... There's a few different things that drive me. First off, it'll be things that we need for our application. So that's one of the things that it'll work on. Other times, it'll just be like somebody files a bug and it's like, oh, this is a pretty bad bug. We should probably fix that. So that'll be something that I work on. And then probably the third category is where I just get... I get distracted and I'm like, oh, this is such an interesting problem and I just dive in and spend probably too much time on that particular thing. So it's typically one of those three things. But yeah, I think most of the time, it's driven by the applications that we use at work. So that's where I put most of the weight. So one last question for Aman. So you have done a lot of work on performance, tuning and debugging for Ruby. What has been your biggest challenge so far when you were doing this performance-related work? That's interesting. The one that comes to mind right away is not even... It's a little bit technical, but I think... So there was a point of about three to four months before the 2.1 release, where I was working very closely with Koichi-san. And it was a really good collaboration, but it was challenging in one, in terms of time zones, because I found myself basically waiting the entire day for 5 p.m. my time, because I was like, okay, Koichi-san's gonna wake up and I have 10 sessions for him. So that was interesting. And then also the language barrier was definitely a big part of it. So we collaborated on the garbage collector for a long time, and a lot of the first couple of months was really talking about variable names and doing renaming and refactorings and cleaning up the code so that it was much more easy to understand. A lot of it was like... He would ask me questions about what is the subtle difference between this word and this word in the English language and try to get the exact right naming. But it felt kind of cumbersome for a while, but I think it ended up in a really good place where a lot of the commits during that time were search and replace one word to another word. But the end result was after a few weeks of that, the code was much easier to read, much easier to understand. You could look at a function name and really get a sense of, okay, this is what it's doing. And so I think that was the most challenging in terms of even understanding a lot of the code and understanding why it was written in that way and then getting to a point where we could simplify it. I think it ended up in a spot where now it's much easier for anybody who has a basic understanding of C to be able to go in and read that code, even though it is, you know, GT.C is one of the largest, most complicated files in the VM right now. That's great. And to round off, back to Matt's for one more question for you. In a previous interview, you mentioned that for the first few years you wrote Ruby largely on your own, and then people started to join and contribute. Can you tell us a little bit more about how this first community formed? Right after the... Right after I put the Ruby on the Internet on December 1995, so I formed the mailing list, and I didn't expect many people to have interest in the new unknown programming language, but I expected more than 200 people to join the mailing list, and the first mail in the mailing list is from my friend, so the congratulations to open your software. Then the second one is, okay, I found a bug. The third one was for me, and absolutely I fixed that bug, and the fourth one, I found another bug. So I realized it's kind of difficult to implement the programming language, which is, you know, most applications has intention, so the purpose, but the programming language can't do anything. So it's quite difficult to predict the combination of the features. So the... And the bug thing, I really didn't have any test of the language. So in that sense, Ruby is kind of working, but it has a lot of bugs, so it's easier to find, easier to fix. So the people helping me to fix the bug, okay, I found the bug, and this is the patch to fix that. So in that kind of involvement, it could become a core of the core development team now. So we just, in that sense, Ruby had many smart developers involved in. So then from the... gradually from the community of the developers and users, then their popularity was formed. And Dave Thomas found Ruby, then wrote a book, and then DHH found Ruby, and Ruby on Rails framework. So the rest is the history. Awesome, and now we're here today. So it seems like if you want to form a community, you should release buggy software, which people can help fix now, I'm kidding. Actually, I got one question. Because we are all doing open source, have you ever felt discouraged when you are doing open source, or have you ever thought of, I don't want to do this anymore. People are not appreciative of me, et cetera. Have you ever felt like this, and almost wanted to give up? Well, 15 years ago, the term open source was invented in 1998, I think. And as soon as I said that, I had a lot of things, misunderstanding of the source, or free software, free, I was in free beer, or they didn't trust any open source, so that they considered open source as a toy software or something like that. It's kind of discouraging for me, but not that big to stop the project. But back then I was tired to explain about the benefit of open source and the trustworthiness of the open source software. The situation has changed a lot in the last 15 years. What about the rest? Do you have anything you'd like to add? I can give you an earful, I suppose. Ask me tomorrow night after a few years. I'll tell you, I'll really tell you. Honestly, the worst for me is like, maybe you saw Andre's talk this morning about security issues. I think that's probably the most discouraging thing, especially because, well, it's hard because somebody comes to you and says, okay, I've got a bug, and you have to keep it secret. And by the way, I'm going to tell the world about the bug on a certain date, so now you need to make sure to fix it by that date, or everybody's going to know that it's broken. And then since you have to do it in secret, or since you have to fix it in secret, it's harder to get people to review it, so it's possible that the thing that you release is actually broken, which this has absolutely happened to me. And then you also have the potential of breaking people's software with the security release, so maybe you fix the bug, you release it, and then all of a sudden you get people reporting and saying, well, you actually ruined our application. Sorry. This happened to me with a high-profile company who is sitting to my right. So, yeah, I mean, that sort of stuff is really discouraging, especially you'll get a lot of people who say, oh, how could you have written that bug? How could that bug exist? When it's just like, I don't know, I mean, it just does. But I think, so that's, in my opinion, that's very discouraging, but you just have to remember, like, well, you know, we wrote the software, it's been there for how, who knows how long, and I mean, it's not my fault that it existed, it's your fault for not noticing. I mean, that's basically just the way I have to think about it, but, yeah. I think after this question we're gonna throw things back to you guys, so if you have a question for our panelists, please head up to the mics right now so that we can go right straight to you afterwards. So, come on. This is a question for all of you as well. The Ruby community is really nice because, well, Matt's is very nice, and so we are all very nice. I don't agree. Well, if that's the case, that leads me to my question. So what are some common sources of disagreements between you guys among the contributors within the community, and how do you solve them? So I try to consider that everyone is among the same team. Like, you know, sometimes the people complain about the Ruby or the reporting bug with very angry fearing, but I consider them to be a member of a team, like the team of the broader Ruby community. So by thinking like that, I don't have to react with the aggressiveness. I don't have to reflect their feelings. So, okay, I'm sorry, but you can solve the problem, solve the issue together. So in that sense, we can at least try to be nice. Do you think they're adding emojis? Yeah, emoji is great invention. And in GitHub issues, we have a lot of sushi as a reward. So that makes me wonder, so when are we going to add macros? Great, so maybe we can go to the questions. If you could let us know who the question is addressed to and what your name is. This can be for anybody. My name is Casey. Ruby, I've found, has been a fantastic language for people that are brand new to programming because it takes away a lot of the boilerplate, a lot of the extra syntax and just lets you start thinking and typing. But part of that simplicity can make it difficult for people that are brand new to programming as well because as soon as you get past that surface layer and you actually try to be a core committer or be a committer to some gem and not just a consumer of these products, the complexity gets pretty deep pretty quick. And it's been hard for me as a mentor to get people from that first step to the second step of going back and contributing again. What advice do you have for me as the mentor and for the people that I mentor to get past that first step of now you've learned how to code but maybe Ruby is your first language and it made things easier for you. How do you get to the next part? You know, I have never been a beginner, at least in Ruby. But in programming, so we often see the very deep complexity often. But I think it reflects the fact that the world itself is complex. So the problem we are going to solve is complex. So we have to face it. But we have the power of abstraction, so most of the cases we can abstract away the complexity of the world and the issues. But when we first solve those issues, we have to struggle with that complexity. Then the only strategy we can take is divide and conquer. So divide the complexity into the small pieces and abstract away to the inside detail into the say class or library or framework. I think that is the only way so we have to step forward bit by bit. So then we have to face the complexity of the world. I'm not sure I answered the question. I'll try. The question was about getting new Ruby developers to contribute to open source stuff, essentially. So on the Rails team, we kind of have to deal with that. We get a lot of students every year. So, well, I think we have them all year, honestly. But we get a lot of students who are there. Some of them are new to programming. Many of them are not new to programming, but they're new to Ruby. And we have to get them working on Rails source code itself. One of the biggest challenges for that is you can't ask them to just go look through the bugs. That's impossible with a project like Rails, because it's so big or it's so popular that any bugs that are left over, I guarantee are hard. The reason they are still in the tracker is because they are hard. So it's difficult. You can't just point the students straight at that. So typically what we do is we come up with particular projects that we want, features we want them to add that we know that they can basically tailored for their particular skill level. So if they're super, if they're a really, really beginner, maybe we'll have them start refactoring tests or something like that. Just something that's very... It's still contributing, but not too deeply. Not deep into the APIs. And then if they're more advanced, they can put them further down. But some of the things we'll do is, since they're new projects, it'll be a little bit more... Well, I don't want to say greenfield, but less brown. And then of course we have to make sure that we don't ever put those projects in the bug tracker. But that's typically our process for onboarding new people with development on Rails. What about for GitHub? I'm sure you have a lot of new developers as well with a very old code base. Yeah, it's tricky. In terms of advice, I would say... The biggest advice I would give is don't give up. To you as a mentor and to the people that are trying to get caught up, it's not like I started programming and I was great all of a sudden. It took me a really long time to learn the basics and put all the building blocks together to a point now where I can jump into the VM and understand what's going on. It takes a lot of practice. I really like what Matt said about divide and conquer. I think that's really the only way to approach it is to find those small pieces, find those smaller projects, and start to put those building blocks together such that you can actually even approach. Because that's what it is when you're going after a large project like that. That mindset that you have to go into it with is understanding how do I break this up into maybe five tests or five different libraries or five different smaller pieces and then try to tackle them one by one. Because if you try to go at it all together and even try to fit the whole problem in your head, it's just impossible. There's too much to it to try to understand and grapple with. Thank you so much. Can we have the next question? Hi, I'm Peter. My question is for Matt. So considering all the progress that has happened on Jay Ruby and Rubinius, is there a future for MRI? And if so, what is that future? At least the MRI or CRuby will remain as the reference experimentation. And the original CRuby is optimized for the scripting. So for the memory footprint the startup time is much smaller than the same Jay Ruby. So I don't think we use the Jay Ruby for the tiny text processing but CRuby also serves that purpose. And then the new idea is come from the CRuby always just because I'm a C programmer but my core team is C programmer. So the CRuby will remain the breathing edge implementation of Ruby language. Thank you. We have a question on this side. Hi, I'm Joel. I'd like to pose this question to the entire team. So when in the design of Ruby language say someone comes up with a new language feature that would bring the language forward but at the same time could potentially break backwards compatibility what would the team tackle such a proposal? Right now we are basically rejecting any backwarding compatible changes just because we have the millions of Ruby users including us here in the auditorium and we have tens of millions of lines of Ruby code so we cannot break them. So we cannot introduce any backwarding compatible change the huge backwarding compatible change except for the big reasons. So maybe I will make some kind of decision to make a huge backwarding compatible change but in that sense we will see the situation like Python 3 and Python 2 or even Power 5 and Power 6. So that the situation I am not pleased to see so probably I am not going to make that kind of decision. Thank you very much. We have one more question here and then one on this side. This question is for the panel. With all the different versions of Ruby out there MRA, JRuby, and ARubyneas are there any plans to formalize some of the properties of the Ruby language and some kind of formal specification? Yeah. So as a standard the dual we have the ISO which is kind of subset of the Ruby language though and we are working on updating the ISO spec 3000, 301, 27 or something like that. And then that is the spec. The spec comes from ISO. It's nothing but spec. And then the standard defect we are working on the Ruby spec. So we are working on the Ruby spec. So we are working on the Ruby spec. We are working on the Ruby spec. And we are updating it as a standard the executable spec. So and we still have some problems in the corner cases in the spec but we are working on it. I hope that there is never a formalized spec because one of the things I really enjoy about Ruby programming language, the Ruby programming language is it seems or the culture is it seems like a very hacker centric culture. Like it's a programming language for hackers by hackers and I'm afraid that introducing some sort of formal like this is how you do it thing would ruin that feeling. So I agree. So the ISO only defined the core so not the corner cases. It also allows the enhancements for each implementation. Thank you. Hi, so maybe this time question for cometers except for Matt. Imagine that you live in a perfect world where you don't have to care about backwards compatibility. What Ruby features would you remove from the language? Two things I'm thinking of. The Polish variables, like a dollar or something and the second one is thread. What about the rest of you? The others? I like threads. I would add, so if there was something I could add, well I would remove the dollar variables for sure. I don't know, but what I would add is a good way to do immutable shareable data structures so that you could share among threads and not break stuff, hopefully. Yeah, I'm trying to think there's a lot of features that I don't use which maybe removing would make language simpler and the implementation simpler. There's the go-to equivalent, the catch-and-throw stuff. There's coroutines or something. There's fibers, but there's also the legacy. Call CC. Is that gone now? That's not in two. It's still live, so I would have to require the continuation. Yeah, continuation. Yeah, continuation. Yeah, I'd love to remove that. I don't know why people hate that operator so much. I like that operator. Sorry, I didn't have a mic. I was saying that I like the flip-flop operator. There's a lot of people that hate the flip-flop operator, but I like it. I don't know why people hate it so much. I don't know what it is. It's the two dots, and you have a conditional on either side of that. Maybe it's three dots, but you just do the two dots, and it flips back and forth. I like that operator a lot, and I don't know why people hate it so much. Anyway. Don't remove that. Some improvements don't have the flip-flop. For example, and when we don't have. What about you, Shibata-san? I'd like to leave this all to you. We had a lot of problems. Yeah. I hope to minimize standard rivalries and reprise operational rivalries to newer and modern rivalries. For example, for Are they it's a big incompatible changes. His trouble. So we introduce, in Ruby 2.0, we introduce a bundle of gems, so that you can download it as a standard distribution, but it's implemented by gem, so you can replace it by a gem update. So we are making some old libraries, like net.telnet.http into gem and then making it a bundle of gems. So gradually we can remove it from the standard distribution, since they are all implementation-wise and spec-wise. Do we have more questions from Flo? I love this reaction. I have a question from Matt about typing in Ruby 3.0. So you say that adding type annotations in Ruby feels redundant, because it's not required. But in Common Lisp, Common Lisp has type annotations, but they are used, as you know, in the object system, to specialize methods in generic functions. So they are there, but they are used, and then they can be used for type checking or compiler optimizations. So I was wondering if you thought about that for maybe a future version of Ruby about introducing something like that, like generic functions, instead of the small talk-like object system. The idea of the generic function is considered before, and actually, I don't know, 18 years ago, 17 years ago, the guy named Guy Deku implemented the generic function, multiple dispatch in Ruby, and it's based on the class. And he didn't disclose the implementation, he just implemented by himself, and he just reported the result, and he reported it was failure. But then I didn't understand what he said, but thinking, yeah, and then he passed away a few years ago. And I'm thinking right now, the generic function dispatch is based on the class, which is totally against the dark typing. So I think that is the reason Guy considered it was failure. Well, from a user's perspective, it's different than leaving classes, right? Yeah, in multiple dispatch, you have to specify class to dispatch, but the dispatch-based class is against the dark typing. And what about the macro system? I recommended some kind of a transpiler. Okay. Thank you. This is a question, I guess, kind of to the panel. Ruby comes with mutable strings by default, and a lot of the new languages out there are just giving up on this concept and going with non-mutable strings by default, and you have to opt in. And is this something that could be considered removed from, let's say, for Ruby 3 in favour of performance, or is this one of those cases where elegance is always going to win? The compatibility wins, unfortunately. But we have some kind of optimization, say, that the string.freeze does not invoke the method, and then freeze in compile time. We may add some kind of prefix or suffix to say, this string is frozen and immutable. And the things would come in the future. Or maybe we have some kind of magic variable so that all the literals in this file is immutable or something like that. So we are thinking about those kind of ideas. But it's always in the explicit path of the transition. Otherwise we cannot do any progress for the sake of incompatibility. Any more questions from Floor? We have time for maybe one more question. Come on, come on, come on. Don't be shy. We're all very nice. You don't see Max and Aaron and Shibara-san and Aman in town every day. Okay, if not, then I'll ask a question. Yeah, we'll ask a question. So as you can see, a lot of us over here are pretty shy. And at the same time, probably most of us are involved in building applications rather than going deep into Ruby itself. For people who really want to get into Ruby, into committing to Ruby and contributing to Ruby, what do you think is the best thing for them to do? So, you know, for the first step, so don't consider yourself, don't exclude yourself from the core community. So you are part of a team in a broader Ruby community, which is the bridge to the core community. So the problem you see is the problem for us and the problem we see is the problem for you guys. So you can do many things. So use Ruby and see the... You can think about how to improve the language or find out the complain about, okay, this is too slow or something like that. And then submit your proposal, complain to the bug truckers. Then we start discussing about the issue. So in that sense, we can move on, we can improve the language, so we can have the fresh aspect, fresh insight from the community. So that is the driving force of the core community, core developers. So consider yourself involved in the core developers. I would say if you run into things... So if you want to get involved, what you should do is, if you ever run into something, you don't understand why it's working or you just want to understand how something works, you should always be asking why it does that. So say, okay, why is this particular thing slow? Or why does it behave this way? And this probably won't sound very fun, but you should just keep researching it and don't give up until you understand exactly why it behaves that way. And once you do that, you're going to start finding yourself digging into, eventually digging deeper and deeper into the thing, trying to understand that particular thing that you're dealing with. And once you do that, maybe you'll discover why and then you'll fix it and send a patch. Or if you finally do understand why and there is a valid reason for it, you've gained some knowledge about the internals or the thing that you're trying to deal with. But the important thing is to be persistent about it, as Amon was saying earlier. Well, thank you so much. Do you have something to add? Yes. Contribution is not the only core language code. So we have our Ruby Rang website and API documentation. So you can contribute to translation to WW Ruby Rang. So, for example, for emoji guides, Junior Fatas, he leads to translate Chinese language from English on WW Ruby Rang. So I think East Asia have a lot of languages. So Thailand and Philippines and Japan, Chinese. But WW Ruby Rang main language is English. So that Roka Rang is not available on our website. So please contribute to translate your language from English. So we are welcome to contribute to our GitHub. WW Ruby Rang is available on GitHub. We accept your pro requests. Please. Amon, anything to add? I was just going to echo what Aaron and... There's a lot of different ways to contribute. You can contribute in terms of VM code, but there's also... We talked earlier about standard library. We're trying to clean up a lot of the code in there as legacy. It's very old. Going in there is helping split it out into gem or even just improving it, rewriting it to match style. Guys writing more tests for it. Doing documentation. Even the English documentation, a lot of it has typos or was written by non-native English speakers. So there's parts where it's hard to parse in. Someone can easily go in. A lot of times if you're reading documentation, you see something like that. Make it a point to go in and open a pull request and just rewrite those two words in that one sentence because it really pays it forward. The next time somebody is reading through that, it makes it that much easier for them to understand. But at the same time, if you are interested in getting into the deep VM level stuff, Ruby is a great way of doing that. I started as an application developer and I just had that itch. Like Aaron said, I was writing all this application code and I wanted to know what is it actually doing out of the hood. When I write this one line of Ruby that's so expressive, a lot of things are happening and there's n number of objects being created. How does objects actually exist? How does Ruby allocate them and get rid of them? You can dive into the implementation and there's a lot of good resources in terms of Ruby under the microscope and other books like that that really explain how the language is implemented. Even if you don't end up contributing at that level just knowing how that works really can inform how you write Ruby code because if you understand that, if you're writing a line of Ruby and there's a string on there that under the hood every time that a loop is being iterated over there's a new object being created over it because you didn't call freeze at the end, that really informs and makes you that much more aware of when you're writing Ruby code if whether or not it's going to be performed because you actually understand what it's doing under the hood, how is it being executed. That's a scratch that I've scratched a lot and I've written a lot of tools that I would encourage you to also check out. Sam up there has some tools as well, like profilers and debuggers and tracers and those really give you that level of insight where you have an application, all of us have big applications, you can attach these debuggers and stuff to it and start to understand when this request is being processed what's happening and that's really the best way to get in there and a lot of times you'll find random bugs and things that can be made easily better even a few months ago I attached a very simple C memory profiler and found that 20 megs of RAM was just being wasted because every time you require a file we would expand the filename and we were allocating a 4 kilobyte buffer for the filename even if the filename was 4 bytes there was a 4 kilobyte buffer and our app had thousands and thousands of requires added up to 20 megs, you know all I did was attach a memory profiler and just saw that's what was happening. So at this point I want to give a plug as well because even though I said the people here don't really contribute back to Ruby actually in the last year we have seen a very promising project coming out from Singapore itself it's called Ruby Bench which is working on profiling the various Ruby pull requests and making sure that they don't regress in terms of performance so it's actually done by Guo Xiang over there and he's probably going to talk about it more in his talk tomorrow I'm pretty bullish I hope we can see more people over here as well participating and contributing more to Ruby as well Next year it could be you I think that the folks here on stage have done so much hard work to make sure that we don't have to so let's give them a big thanks