 Okie-dokie. So there was a lot of questions about Ruby 3, which makes sense. Yeah, I can't help it. Yeah. Someone asked just static typing question mark. So there's like multiple questions there. I think one could be, are you serious? So so are you see are you serious about static typing? It's up to the definition of seriousness. I like it. I like it. You've parsed my parse. Ok, that's good. So you think it's an interesting idea. Would that be fair to say? But if it doesn't pan out then it might not happen. Does that seem about right? So we have to experiment. Yeah, we have to do some experimenting. I thought it was very interesting watching you kind of describe it. Talk about the fact that the I guess tell me more about how you see so I you one of your slides you gave an example of something that calls to int on that. What's the kind of if you wanted to have that be as a static type? What would what would the type you be? Okay, this would be really easy if I had code. Describing code in words always sucks. So yeah, you have a method that takes X and call on inside the method it does X dot to int. What type do you add to X in the declaration? In your mind? You know, I expect X to be responsible for to the method to to int. Okay. So the and that kind of soft typing the type is described by the set of methods. So but are you thinking of it sort of like goes interfaces where you basically have you have a thing that says like it's it's you wouldn't say that X is a fix num because you don't you know you don't really care you just need to be something that has to int. Yeah, and so you would would you define that as a separate like would you would you have to find that as a module that just has one method in it or there'd be some construct where you describe the signature you want. Is that what you're thinking? Yeah, but it is it was created by inside of the create inside of the compiler. So it would never be disclosed. Oh, okay. So I got you. Okay. So it would be automatically checked in that particular case. So something else would say oh, I see that you're calling to int on X. So let me go ahead and check to make sure that actually to int is defined in that particular case. So are you thinking that you would actually add the programmer with the programmer actually add type declarations? No, are you thinking that the you do more sort of type inference in that case? Yeah, type inference. Okay, interesting. The compiler may give information about their guess. So this is only because we're on video. There you go. So that so that we can add so that ID can use the that info to complete or something. Okay. Are you thinking so in the case of type inference, we are you thinking that it would sort of bubble back out as well. So for instance, is the like if I if I pass that X as an argument to something else, does the the need for the two end kind of bubble back up the call stack? Yeah, yes. Okay. Interesting. All right. So that kind of propagation will tell the compiler about the information or our expectation to type type of the variable X. But you're thinking of it mostly as I say this response to kind of conformance, right? Not so much not so much like runtime performance, you're really just thinking of it as being able to when you type when you load in a Ruby file, having the compiler at that time say, Hey, you pass this thing here, that that's never going to work out. So trying to eliminate no method, a no method, a method missing kind of call. Okay, cool. That definitely kind of clears it up for me. We had a question of it seems like Ruby 3.0 would be a good time to remove things if we're adding other things as well for kind of mixing it up. What kind of things do you have anything in mind that maybe you'd want to remove? Yeah, probably some of the probably inherited weird variables, like a dollar or something, something. So getting rid of more pearlisms if I'm thinking about that, but I'm not sure yet. Just because you know, I don't want that kind of the huge compatibility gap between, for example, between 1.8 and 1.9. So Ruby 2.0 was a kind of successful just because it's dropping new replacement to 1.9. So that kind of things should be happening in Ruby 3.0 as well. But I'm not sure yet. I mean, it's definitely a hard, that's a hard path to navigate, not knocking anybody here, but it seems like that's a path that like, for instance, Python from 2.0 to 3.0 had a really hard time navigating, you know, both removing some things and changing the way some other things worked. So it seems like it's this tightrope that you have to walk. My computer keeps locking itself. That's really awkward. Okay, what about sort of the standard library? I know that one of the things that for years, it's been to try and make sure that you have a maintainer for certain things inside the standard library. And some stuff has a maintainer and some stuff is finished. Do you think Ruby 3.0 maybe time to pull some of that stuff in that isn't really being worked on out of the standard library? Yeah, we are under the process of the gemifying some of the standard library. And in the early stage of 1.8, so we added a bunch of things into the standard library just because it's kind of like a battery included policy. But then we didn't have Ruby gems yet. So yeah, we had but you know, it's not that mainstream. And so we have to do is we have to take that kind of kind of battery included policy. Times passed. And then, you know, the maintainers are gone and some lose lose interest as you know, the some the standard libraries left are maintained or something like that. So so so we are under the the gradual process of removing them actually the gemifying them so that you can update the part of the standard library without operating whole system. Sure. Yeah. So the way we happen maybe in the Ruby 2.0 era or something. Okay, interesting. Yeah, I mean, the the battery and batteries included is totally there. But it's it seems like maybe some of the standard library is sort of like batteries that are such a weird format that nothing uses them anymore. You know, so yeah, that was a good joke, everybody. There you go. I added this and then I saw that someone else asked it as well. We've talked about I think the last couple of years about the idea of, again, we're just talking about sort of new features and Ruby 3.0 and that kind of thing. I think you had described the idea of maybe it would be good to add some kind of thread abstraction, either be an actor or something like that. Have you thought about that lately we are still thinking about that. I have an opinion and ideas and the Koichi has an opinion and ideas and we are not yet have any conclusion yet. Okay. Okay. So but you're still we're still you're still pro that you're you're still in favor of it or you're still not sure. Yeah, we agree to add some kind of the abstract the higher level of destruction to the concurrency, but the concurrent idea are different. Okay. It seems like in the last year or so, the idea of like what the guild should be and that kind of thing has sort of changed that your your opinions of it have changed a little bit. You want to maybe talk about that and what you kind of how you got to your new thinking about the go go. No, Gil, the global interpreter lock. The you know, we can talk about go to if you want, but that's a different topic. Yeah. So so so many people complained about the goal. I mean, now I'm mixing you up. Yeah, I'm confusing. Gail. Okay, Gail. Yeah. So so many people complained complain about it. Gail, but it's so the Gail is there to protect you, right? Not us. So the, you know, to prove that. So I asked an over to, to, to prepare a compiler option to turn off the gale in compile time, so that you can see what would happen without gale. Okay. Yeah. And I'll tell you, it is quite difficult to write through a safe program without gale. That's true. Yeah. So so so in a few days, so you can, you can have the Ruby compiler Ruby interpreter, the virtual machine without gale. So so that you can see what would happen. So but do you feel like do you feel like it's the the right? Do you? How should I put this? The gale is super useful because it's hard to write a thread safe program. So do you see as maybe the the internals of Ruby of C Ruby get more thread safe? Do you see a time where maybe there's a the ability to say, you know what this chunk of Ruby code I know is thread safe, go ahead and, and, and run it without the gale? It's sort of that flexible approach? Or is that scary? Yeah, that that's pretty scary. Yeah. Yeah, right now, right now, the the part of the Ruby, which is thread safe is run without gale. For example, that the calling system calls and the whole, like a file IO or something that so they, the part that part is run without gale, just because it's thread safe. Yeah. So the the right now, so many part is running without gale. But you know, but, but it's still people complains. Yeah, well, I mean, I think that, yeah, it's it's a it's a topic that people love to discuss, I think, because it's it's a hard problem to figuring out how to solve, I think that so I believe we need some kind of the higher abstraction. So that right, the current obstruction thread is too primitive. So that the human human being cannot handle that abstraction pretty well without gale. Sure. Yeah, maybe totally for us. Maybe how about how about this idea? Just I'm just throwing out an idea here. A M Ruby embedded inside C Ruby, where you have actors that are running M Ruby on their own heap. So they're totally isolated from each other. And C Ruby is the coordinator. What do you think about that idea? Yeah, actually, there's a guy who wrote extension that invests in Ruby already. So Ruby in Ruby. Yeah, yeah, shoot. Yeah. And then maybe some, some smart guy playing on that extension will write some kind of the higher abstraction. Challenge accepted. Let's see. We have the traditional question that comes up every year. And it's important that you get your chance to discuss it again. Will Ruby 30 have macros? No. Well, you heard it here first. Definitely no. Okay, I'll get shoulder answer is no. A slightly longer answer is no way. That's so good. We had a question of when, if at all, you think Ruby core would move development to get you have been using get for like 10 years now. Yeah. So, so do you think that that's going to happen for Ruby core? I'm not sure. So just, as I explained last year, so the core, the core development team are highly dependent on the scraps within around the subversion. So that, but I, so I have to discuss with the team, but so with it. So many, we received many pro request and issues on the GitHub. I saw that Nobu uses them. Yeah, yeah. So that if the, the majority of the team, team members agreed, so that we can move on to the GitHub. There's, there's a possibility to we will move, move on to GitHub in very soon. But we have to discuss first. So the nearest developers meeting will be held in some week or two or something. So we will discuss there. Okay. Since I, I mentioned it, and people probably don't know this, I know it because we've been friends for a long time. But tell us a little bit about how you use get personally on your own machine. Because I think it's a fascinating, as I've seen you work before, and you have like, you used to use quilt, I think, did you use quilt before? Yeah, I use the, the tool name the stack it a stack it. Yeah, which is kind of like a git, the tool are on top of the get. So that that just works as a quail. Yeah. Yeah, we can start this. It's kind of like a git stash. Yeah, but we can name it, we can read where we name it, we can change the order of the stocking. That's quite neat need to it's written in Python. Yeah, I, is it, do you still use stack it? Sometimes. Okay. Yeah, and I, for development, I'm Ruby. So I use the raw get. Yeah, just get mainline. Because I know a lot of the features of stack it got put into normal git after a while as I recall to so. Yeah, the stash was weak back then. So yeah, right now, we, we don't need to use that get any number. I remember I asked because I remember. Oh, man, what year was that whenever we were at a, we were at a conference in Copenhagen remember that conference? Yeah, yeah. No, no, it was like Ruby fools, I think. I remember seeing you work and been like, I thought you're on subversion, what are you doing with all these git commands? I was kind of like, like shoulder surfing you at that time. Anyway, I thought it was, I always thought that was fascinating hearing about people's development practices, like how they manage their own workflow on their own machine is always super interesting because everybody has a different way of doing it. Yeah, even though that we have the central repository in subversion, so the probably most of the developers use git as a, they are, they are local environment. So, so everybody uses git, but the upstream is subversion. Nice. Nice. I think this developer meeting is going to go well. Yeah, the, the most things I missed and get is that kind of like the numberized revisions. I can show you how to get it's called git log pipe WC-L. There you go, you get a number back every single time and it just goes up. It only goes up. Okay, okay, I'll try to use that. Okay. So let's see, we are about 330. So we've got, you know, half an hour, 20 minutes left or so. So if you have, if you have questions, we're going to go through, I have a whole bunch more questions. I'm just sort of prepping you here. If you have questions that you want to ask, Matt, let's go ahead and have people line up sort of even with our lovely cameraman here in the aisle here. And then as however many people I see line up, we'll figure out when we're going to get to you. So that's, that's your cue if you really want to do it. So let's see, some other good questions. Someone wanted to know how I pronounce your name, I wonder why. But I know how to pronounce it correctly, so screw you. That was a question for me evidently. Have there any, have there ever been any ruby behaviors that have really surprised you? You've been working with the language for almost 20 years now. You sit down to write a program, be it an M ruby or wherever that you write and you're like, oh, I didn't, I forgot that it worked like this, like features you add in like a long ago. And you're like, if you really asked if we had this feature, oh, I wrote it a long time ago. Does that happen a lot often? Yeah, sometimes. And I'm actually, I'm fortunate that I don't remember that. I forget soon after that. Yeah, definitely I had. Yeah, occasionally. Does it feel like, you know, it's been a long time now and you've got so many people who've worked on the language. Does it feel, it has the feel of sort of almost an organic, like it's its own thing, like ruby and being its own thing, like it's got all these behaviors, it's got all these things that nobody knows all of it anymore. And so it's got all these things that it knows only of itself. Yeah, nobody, not bad, probably Nobu. But yeah, we should just, maybe we should rename Ruby to Nobu. As in Japanese restaurant? I wasn't thinking that, Nobu. Yes. Oh, questions. Okay. Did we did we end up getting an extra mic? Oh, oh, my gods, the deities of loud speakingness bequeath me your wand, wand, wand, scepter. Oh, and it's just lowly Marty. Okay, we've got a question. Go ahead. Hi. Do you ever, like, really get tired of writing Ruby and C and want to write Ruby and Ruby? Have you, so this is a little known fact, actually it's not anymore, but Matz is a C programmer. Yeah. I don't know if you all agree that. I agree that. Matz is a C programmer. So have you gotten bored of writing in C at this point? Not really. I have been a C programmer for, I don't know, 20 something years, maybe 30 years. Are you using C 99? Have you moved up? Are you keeping up with the C? Yeah, I recently started using C 99. Yeah, if you knew that the old Ruby source code. I do. Ruby has been used with the very old K&R style for a long, long, long time. Yeah, I was so conservative. Well, it's good to, you've moved up to C 99. The sky's the limit at this point, right? Yeah, actually recently I work on an M Ruby and it's written in C 99. Okay. The problem is the MSVC does not understand C 99 at all. Oh, I forgot about that. Yeah, so I have to support them. Yeah. Yeah, so I cannot move fully onto the C 99 yet. You could just write it, you know, VCC loves C++. You could just write it in C++. How about that? Actually, okay, let me clear it. I like C++ as a language. Yeah, it's too huge though, but I like that. But you know, writing the object started programming language in object-oriented programming language is kind of confusing for my brain. Yeah, no, I agree. I haven't done it before, I agree. Yeah. So two object system in one. That's insane. It's sort of like writing a garbage collector in a language that already has a garbage collector. I don't know where I am anymore. That's also weird. I suggest you all do that at some point in time just to kind of twist your brain, but yeah. For the same reason, I don't write Ruby, the core Ruby in Ruby. Yeah. So the core is written in C and you know, so some part of the standard library is written in Ruby and that's okay. But for core, it should be written in the other programming language, the fundamental, primitive programming language. Gotcha. Okay. Thank you. Yes, thank you. So when you're looking into the future of threading for Ruby, if you go beyond Ruby 3.0 and just think really long-term vision, what kind of threading model are you hoping to approach for Ruby? Actually, I found some kind of the arc-term model and Koichi has different idea, and I'm not sure which one is right yet. What is Koichi's idea? It's kind of Koichi's idea is that the objects to belong to the thread or the concurrent task that create that object. So every operation need to have the object created by that thread. So would it be like kind of like isolation? Yeah, would it be like a heap per thread then? Okay. Yeah, you can reference, but you cannot process that. Without migrating the position. Would it be like having like the right barrier would check that like you you're touching someone else's object, bad boy, and it would just slap your hand? Yeah, that's kind of stuff. I like it. Would that mean a move to immutability then? You're going to follow that second model, would there be kind of a more of a move? Yeah, from other threads, objects will be seen as immutable, but the thread with the possess the object, you can modify. I like it. Sort of, you know, you have your own sandbox and you can lens an object out to somebody, but they can't change that kind of thing. That's interesting. Thank you. So as a C programmer, have you looked at Rust? I know you look at a lot of languages. I'm curious what you think of Rust and I saw Rust and it's quite a neat combination of the system programming language and the functional programming language. But actually I confess I prefer a goal for its simplicity. There you go. Haha Nathan. Hi. Have you or the Ruby Core team ever considered a change to Ruby syntax to basically explicitly state a method should return nil or have no return value? I've encountered a lot of really strange bugs and misbehavours because people overload a method and make it return a value where it was explicitly expected to turn none. Just wanting your thoughts on that. I haven't think about that, but it's quite interesting. What would that look like? You want to say, do you want to annotate the type of the return or you wanted to annotate that there is a return? This is actually the problem I just fell into recently. Once you say that yes this should be return nil every time or this should return void every time, you've put very you know weird static or static typing in the Ruby so like maybe that doesn't work. Pretty much my thought was saying like this method should never return anything and if it does return something either raise an error or just discard it all together. But that just starts you down a very bizarre path. So I'm not going to explicitly specify the method to return nothing or something like that. Yeah, yeah, exactly. I mean I guess you could, I mean it have to return something. Basically you're saying that the return value be disregarded and it would always return nil at that point. Because even you have to have, in order for Ruby to continue to be Ruby every method has to return something. I mean there's just, otherwise everything breaks. The world just collapses around you and that if that's not true. Yeah, but he's proposing introducing the method to return nothing. Yeah, just like saying disregard. I don't know, that seems strange. Or just nil every time regardless of what you return. Why not just put return in the code? You'd think that that would be easy enough. I've encountered situations where people forget that. Yeah, for some people return nil is a bit different from return void. Yeah, but you, there's no, but you'd have to add an extra type then. You'd have to add, you'd have to add like a void type. You have to have a void thing, object that could be passed around and reasoned about and be exploded upon if it ever got used I guess. Yeah. It's, I mean, what's funny is, CRuby has that thing, you just kind of access it, it's basically Q undef. Yeah. I mean, that's effectively that. That's effectively a bad boy. Yeah. You should, you shouldn't return that. Yeah, there's this. You shouldn't, Q undef should not be a reference. Yeah, there's these four special values inside interpreter. True, false, nil, and Q undef. And Q undef is just sort of special case everywhere. It's like anywhere there's not, there's never supposed to be a value. That value should not be disclosed to the Ruby world. Yeah, right. So that would be very, very secret value. Yeah. The secret's out buddy. Thank you. Thanks. Yeah, but that, that, that idea is kind of interesting input. Yeah. Let me think about that. Yeah, and then you can submit your proposal. We look for your poll request. Yeah. I recently discovered unbound methods, which I'm sure you're familiar with, but for other people, it's a method that... Could you speak slowly? Oh, sorry. I'm a Japanese speaker. I didn't get it either. So it's not just you. I recently discovered unbound methods. Unbound methods. Unbound methods. We're getting this weird echo. That's the other reason it's hard to hear you. And so basically you can have a method that is now, as it sounds, unbound, but can't be called and can only be called once you attach, reattach it to some other object yeah, which can be the original object or another object as long as it's this the same class or subclass. Why is that in there? And how could I possibly, why would one use that? Why? Just because the unbound method is retrieved from class, the class is not an object. Actually, class is object, but the class is not an instance of that class. So by retrieving the method from class, there's a method without any instance. So you cannot call the method with the object attached. So that's with the reason for the unbound method, only you have to bind it before calling it. Did the change go in, this is years ago, Aaron Patterson was working on this change, that allows you to rebind a unbound method that's implemented in Ruby to any class. Do you remember that change? Did that go in? Or does it, when you try to bind an unbound method, does it still make sure that it's in, that the object that's getting the binding is an ancestor of where the unbound method was created? Yeah, it does, it still checks. Because there was this whole at one point, we played around with like removing the check. So you could take an object, you could take a method from some random class and bind it to some other random object and be of the call it in, call it over there. Yeah, now that's possible, I think. Okay, okay, my question is actually if there's like a general use case that was imagined for unbound methods. Use case. That's a good question. The bind unbound things is there to experiment about the object system. So by playing with them, so you can understand more deeply about the Ruby's object system. That's the whole reason. I'll give you an example. You can use it to model very interesting kinds of dispatch. So like let's say you get, you want to set it up so you have a hash of say string keys and the values are unbound methods. And it's say an HTTP router or something like that. You could get a request object from something else and then you could just look up inside the hash to get an unbound method, bind it to the request and then call it. So that way you actually get the methods as actual objects separately. Now you could use send and stuff like that but it's just a different way of being able to glue the thing that you want to call on to the actual receiver. Yeah and it's actually the Python object system does. That's right. Hi boss. Are you going to give me a question? Yeah. Did you want to answer a question? You want to answer the question. So my question is what is the new feature, big feature on Ruby 2.3? Ruby 2.3? Yeah. So we let's think about it after we release Ruby 2.2. Any idea? So it should be, actually it should be faster, it should be more feature-rich and it should be more stable and it should be more interesting. Is Koichi trying to get you to commit to like doing a JIT in Ruby 2.3 or something? It's up to him. I'll use that as a segue. Have you, especially since Koichi is standing here with the mic, I know that you, I'm not sure if it was you Koichi or you Matt's who talked about like maybe Ruby needs a JIT and what would that look like? Have you guys talked about that much? Yeah, you know, the very interesting episode is Ruby, the transition to Ruby 1.8 to 1.9 was succeeded just because of the we had new virtual machine and then we have gained a huge performance boost and at the same time the compatibility gap. But on the other hand, in contrast, the Python 3 had a very consistent syntax improvement but no performance gain. So for me users, so there's no gain, so the Python 3 has very big, big obstacles to migrate communication, I mean community. So if I introduce a JIT, so it will be same to the, it should be at the same timing to making something incompatible. The carrot and the stick, if you will. Yeah, yeah, yeah. Python 3 just, Python 2 to 3 just had a stick that people whipped themselves with in order to do it, I guess, and yeah. Any other questions, Kweechi? It's kind of like a e-stop, like a sand and no swing. Yeah, absolutely. The hat is back to its rightful owner. Have you thought about giving us the ability to define custom falsi methods or custom falsi objects? Yeah, I have to think about that and I abandoned that idea. Don't do it. Don't do it. Mostly because it's the Boolean check, like the conditional check has happened so many times and that kind of phook will slow down the language and even now people complain about the Ruby slowness, even after they introduced a new virtual machine, so I don't want to introduce that kind of things to make the language even slower. That's one reason and the second reason is in some cases we kind of have the tri-value logic, like true, false, near or something like that, so they're having that kind of, say, two-ball method would hinder that kind of style so that for those reasons I'm not going to introduce that kind of phook. Please don't. Please don't do it. Hello! I have two questions. Okay, you're the last one in line so you get to mobilize the mic. Alright, so I guess they're both for features that I was thinking about or I would like but I don't know how to do it. So one is it would be nice if we had, I guess, a first-class way to do delegation and what I mean, I'll explain what I mean by that, so when you like a lot of times in Rails we define delegate methods that all they do is just delegate that same method off to a different object but we still have to pay a price for that intermediate defined method. Is there a way we could optimize that out? Like, could we get rid of that extra method call in between? Okay, great. Yeah, submit the idea to the, I mean, RedMind so we can discuss so that we can discuss. Alright, so the other one, the other one I'm wondering. Maybe we can implement that by writing some kind of C extension, probably. I was thinking either a C extension or possibly you could tell compile time that all you're doing is just passing through to the next one like. I don't know. Eliminate, maybe it's a question for Koichi. I don't know. Use an unbound method. Yeah, I'm pushing the unbound method so slow. I guess so the other question I was wondering about is, could we add away like maybe syntax for getting access to methods easier? So for example, like in Scheme I can refer to a function just by its name so when I want to map over something I just say all right, you know, call this function but when I use map in Ruby in order to do the same thing I have to go okay block and then actually call that or I have to say like okay method colon method name and then cast it to a proc and then pass it into map. It seems really cumbersome. Yeah, I actually like the idea of having the special notation to retrieve the method from object or maybe from class but I think we run out of the characters. Slash is still available. No, you can start using emoji. Emojis. Come on. Aaron, I thought that we were saving all the emoji for your language. Yes, yes. There's only one emoji in my language. Yeah, it's the poo-lang. I also have two questions. So the first question is how do we get involved with the whole soft typing paradigm? And the second, what is your take on the different Ruby interpreters that are currently happening out there? So the first one is what how do you get involved with soft typing? Is that what you asked? Okay. Right now we have only a big idea so we in the near future we are going to have some kind of static analysis tools so maybe... What did you did you see any other languages that had soft typing that you liked or you know like read anything like how are there any systems out there that you said oh well they've got gradual typing that's a good example for us to kind of pull from. Yeah, some like a some language like a strong talk has a gradual and the soft typing and there's several research paper on the soft typing and and recently Facebook released the tool named the flow which is the some kind of static analysis tool on top for JavaScript and interestingly the little developer was used to research on soft typing on Ruby. And then he got a job at Facebook. Yeah. That's quite interesting. So that we have some kind of the you know preceding research so we have to survey first. So actually soon after that I gave the keynote so several several people contact me about you have this paper you have to check out this paper with that so this is quite interesting so I have to the tons of paper to survey. So let's let's start. Lots of reading from the holidays. Yeah. Yeah. Yeah. In the near future we will we will I will start working on some kind of the static analysis tool so maybe based on our sense or something but so after I will use that it on say GitHub so we I will welcome the full request and the suggestions. And your other question was all about the other Ruby implementations and VMs and stuff like that. What does he what does he think of them. Yeah. Exactly. Do you think of other Ruby compilers. How do you feel about Rubinius and J Ruby. Yeah Rubinius is great. Yeah. Actually did you get to the J Ruby 9000 talk this year. No no I missed that. OK. But you know the I pretty respect the effort and you know accomplishment that they did and then we are working together so to make the community better. So do you feel like you know one thing on this that I thought was interesting is when you started and Ruby which is it's been a few years now it kind of it kind of said I think to everyone that like hey you know we can build these in more interesting Ruby implementations Ruby VMs that are useful in various different contexts right and Ruby is really good for and it was built for embedding on and hardware and that kind of thing and J Ruby can fit into the really nice Java ecosystem and Rubinius tries to bring a lot of performance to it. They can all have their own little niche and happily code this sort of that's kind of that was at least yeah optimistic way of looking at it if you will. Yeah I like the say 10 15 years ago so the Ruby world is getting bigger and the bigger so that we have the each implementation of each niche to to live in so that we can be a little happily together. Great. All right thanks. Sure. All right. I think we're probably going to call it now give it up for Matt's. Thanks so much. Thank you.