 So I'm going to be talking more, um, some weird combination of down-to-earth and, or cody and high-level and hopefully down-to-earth, um, but what I really want to talk about today is, um, what I want to talk about today is sort of where we are in the growth path of Ruby and where I see you need to be. And I think, um, we are at a point in Ruby where it's still very viable and something that gets a lot of athletes to go write yet another HTTP client and not talk in the US. Um, but all the people write it in sort of the 20%, uh, write another testing library, and that's in Vogue, but I think we're actually getting to the point where we're outgrowing that and we need to actually start focusing on completeness and getting to the end. Um, if we don't do that, we're just probably going to be a blue slash scripting language that people use to script the JVN or people use to script C and don't actually, can actually filter to stop them. And you could argue about whether that's important or not. I personally feel like getting Ruby to the point where it's a, uh, a real language that people do serious stuff in actually matters. Um, and I actually think to some degree, while I don't want to endorse everything that's said, um, I actually kind of agree with that, that Rails, um, holds us back somewhat in that. So I'm going to talk today about, uh, about a little bit about that. I will serve it as the official conference a little bit. Um, but I really, I just want to talk about sort of where I go Ruby goes. I definitely see two of us in the world. I think the popularity of J Ruby definitely gives us the potential to be in a scripting language for the JVN, but I don't think that's not, I don't know if that could be all we ever are. So, I want to start out by talking a little bit about what I see are the important basis of Ruby development and I could spend, I could do a little talk on this and I could go along the granular but I'm just going to talk about a few, a few big ones. So, uh, Ruby was developed for a few years. Um, a bunch of people mostly in Japan but eventually outside of Japan had some time to flesh it out, writing a standard library, etc. Rails came around in 2004, um, that pretty much dominated the Ruby scene for a while. And I think, uh, there was a lot of focus during that period of time on just building stuff A for the web and B, getting, like, B for getting out stuff that works, that solved the 8.20 rule. I think Rails didn't advise the 8.20 rule. Um, especially back when Rails was first created, they advised the 8.20 rule. So, uh, a lot of the libraries that came out around during this period of time are very 8.20 rule libraries. And then, sort of, around 2000 miles we started getting serious Ruby, serious Rubinius, people using Ruby for serious things like Chef, right? And, uh, what started down was that people started to notice that there are efficiencies that are not in the 80%, right? So, most people don't ever pick these, but when you start writing, uh, a high-performance web server you really start to get efficiencies. And a lot of people, um, and we've heard some of that today, argue that that's okay, because, uh, you shouldn't care about it. Nobody cares about the 20%. Only a few people care about it. But the fact it matters is that the people who worry about it are actually building software for everyone else, right? So, if you say that that HTTP doesn't need to support streaming, for instance, then all that means is that all the 12 people who write the clients or the servers or whatever aren't going to be able to actually implement the things that are needed. And we saw that Wes actually wrote an HTTP library because that HTTP wasn't good enough, right? So, Matt probably took some time out of building the thought that maybe it was a more, uh, better use of building the thought. So we definitely have a problem in the Ruby community where, uh, think there's efficiencies and a lot of the way that we deal with those efficiencies are by saying it's okay, 80% rule, everybody should build an HTTP client that solves the 80%. So I sort of consider the phases being these four phases. I don't really know where we're heading with the growing up phase, but I know that there's definitely been a shift in how people have talked about things in the past few years. A lot of us do it. There are more implementations that are taken seriously, and a lot of us do Ruby, using Ruby for things other than the web, which sort of goes back to the beginning, right? So the growing up period is a lot like when I have your flushing out period, right, where Ruby is being used for a lot of things, so maybe each one of you doesn't really make as much sense because you can't really figure out what the 80% is. When everybody's focusing on the web, it's actually really even clearer. So I want to talk a little bit about the standard library before I move on. It's much more aligned. Um, but the standard library, uh, serves as a foundation for a lot of other things. And if you go look at sort of the dependency graph of Ruby, you'll find that for all the people saying, you know, nobody uses this library, that library, almost all the libraries in Ruby are used somewhere. Some exceptions might be the RSS library, which isn't used that much because there is in fact a better one, but I think when people say a better one or there's a superior version of this, they really, almost nobody has actually looked at the code or tried to use it for some kind of stuff. They just know they like the API library the standard library has. And sort of the point of the standard library is not necessarily to build the best, prettiest, and most awesome API in the world, it's to be complete. It's when you implement a protocol or a specification to actually get to the end. And, uh, like I said, the standard library didn't do all that perfectly, but the standard library actually cares about that a lot. And so if we go look at something like that at HMP for, um, Rex and Mel, which goes so much online, you'll find that it's actually pretty complete. A lot of times it's slow, um, but these things are relatively robust, and also these things consider threads and areas. So this is something that I think the vast majority of libraries written during the Rails era I don't care about at all is threading. Part of that is because no Ruby Web server that anybody uses except for JRuby servers actually have thread support. So if you turn on a call, if you think that thread's like banging in the Rails app and putting in a passenger, you might not find it. The faster it doesn't actually serve multiple threads. And if you think that thread's like banging in the Chrome, you're not finding it. And the uniform of passenger guys will argue that it's okay, it doesn't matter. We think that that's a better way to put it in apps. And that's fine, but the fact that there's no alternative solution that's actually any good for MRI, that supports threads, means that nobody can actually make that decision for themselves. Right? So nobody can actually be able to check to see whether threading is going to affect their application because there's no way to actually try it. And I think that that's actually bad and it's one of the reasons why the first five years of Ruby Standard Library development considered creating scenarios and the next five years basically don't. So many, many libraries that exist out there don't really support threads, sometimes recently and sometimes at all. And it's very hard to tell. Right? So if you just have Ruby developers that are cranking their libraries and nobody, you can't tell what's broken because nobody actually wants to see threading them. The Standard Library, libraries tend to begin for the long haul which actually means that they tend to be somewhat crafty. Right? So in my mind, craftiness for protocol libraries is probably a good thing. And that's heresy a little bit. But I actually think that if you look at a library and it hasn't been updated that much, there were people who said in the famous Ruby Standard Library together post, there were people who said what you should do is check to see how often it's been updated. If it hasn't been updated recently, it probably means it's too old and it seems worn out. I actually feel the opposite about things implementing protocols. Right? If something implemented protocol has been updated in a while, it probably means it's pretty good. It probably means it's serving its purpose. And what that means is that there's a lot of code in the Standard Library that was written before idiomatic Ruby became developed. And so there's a lot of code in HTTP and WrexML and all these other things that people love to ate that is ugly, that dump that uses the curly braces for multiple line blocks is one thing that like blurs how to even start to look at it. But honestly the people who wrote them wrote them 10 years ago before we had these idioms. And the fact that somebody uses code for these instead of doing it is not actually good reason to throw out a library instead of doing it. So, which begs the question, is the Standard Library stagnating? So, there was this famous post that I said by my firm, he said go look at some of the codes in the classes you've never used. Chances are it's wrong. 10 years ago, it doesn't even look like idiomatic Ruby. I don't know about classes you should remove so that higher quality replacements can take their place. So, like I said, I expected that we should see some proper protocol limitations. That doesn't mean that we should never go and clean up the prof, but it means that prof does not necessarily equal battle library. It means old library, right? But that's okay. It might not actually be a great sign if you have a lot of charming protocol libraries. You don't want that issue to be changing a lot. It's actually good that it's not. And I would say in general, from my perspective, when I'm using a library, something that is robust and complete actually beats something that is idiomatic. Idiomatic just means it was done recently. And idiomatic obviously changes, right? Idiomatic C, 2010 may not be idiomatic C from 1990, 1980, 1970. And that's okay. It doesn't mean that a library written in 1980 is a battle library. People in C know that, right? People in Ruby don't have to know that. So, I would say we need to pay more attention to what robust and complete means. We need to actually read the library like someone said and see what's actually going to happen. So, what changes about the Rails work? So, first of all, the Rails itself is a somewhat standard language. It somewhat follows the things that I said earlier about the standard library of Rails. So, it's robust, it's pretty complete. If you look at, for instance, although further than animals, the HTTP request response is a lot of quotes like IIS, weird hacks, there's a full unicode library written in C, they put it written in Ruby in AccuScore, right? So, there's all this weird crop, people talk about crop all the time, but at the end of the day Rails actually solves a lot of problems. And solves a lot of problems, you know, maybe from a primary Ruby community, which is trying to hide the fact that it actually solves the problem. So, the Ruby standard library solves problems in a way that's very obvious, because there's an API around the solution. Rails solves problems like dealing with HTTP for you in a very hidden way. So, people have sort of, not only is there a crop internally, there is no crop in the API, so people are like, what is this going to do? Why is AccuScore our action controller response even there? I don't understand, right? AccuScore and lab important stuff, like generating e-tags for Ruby in a secure way. That is the subject of timing for the Ruby attacks, right? So, I know Ruby cares about this stuff, but it actually matters. And so Rails itself ended up having the same sort of like, this is cruffy, etc, etc. Rails itself, sorry, Rails, but Rails gems are a little bit different. Rails gems can't do not be robust and complete. They tend to do very narrow target things, which is good, right? That's where Rails plumbing should be. It should implement the API, like the Twitter API. That's great. And if it implements the part of the Twitter API that Rails developers care about, that's also fine. And we tend to get into a situation where a lot of people care, a lot of people care, they would just go and attach a Twitter API and give our viewers help. That's a situation where the types of things that Rails developers were doing by plugins were inherently narrower and tended to be sort of not assorting standard library. You want something that's standard library to do typically if it was web-related, it would go into Rails. If it was not web-related, it just didn't get done enough for right libraries. Sometimes these libraries are robust. So there are some libraries when you like them or not, like device or paperclip, that have been around for a long time. They were very much specific, but they were not long enough that they saw more than each one of them. They saw a lot of problems. And then there's a lot of other libraries that are, there are 45 of and all of them saw the 80-20 of that particular guy and there's not a lot of collaboration and they're not very robust. So this is what I mean. Sometimes there are less. These libraries are sometimes really good, but it's actually very hard to tell. There isn't a really consistent way of saying, this library is awesome. This library is less awesome. There's attempts to solve it, but it's difficult. You expect to have a high churn. This is actually not a bad thing for Rails plugins. Rails plugins are the sort of thing that the Twitter API changes and that's what we write the entire library, right? That's fine. That's the sort of thing that Rails plugins are doing. You expect this to go out of churn. Not a good thing is that we made a pragmatic decision as a community to just assume a single credit operation which worked good as the 80-20 rule and then people started to actually do things like make web requests a lot inside of their requests. Suddenly the single credit rule didn't help that much. So there was a talk here about concurrency in general, but the thing that I think everyone should know if they don't know about concurrency is that MRI and pretty much anybody who supports threads has pretty good IO concurrency. Which means that you can make two HTTP requests at the same time or you can make two SQL requests at the same time. And that tends to work in MRI. And unfortunately, as they have gone from mostly CPU bound to most IO bound, so more and more people are making requests into their API or a long request to SQL databases. As we do more more of this, the fact that we just never bothered to care about threads in any of our libraries starts to matter. And we sort of patch it over and ignore it by not bothering to support threads in our servers, right? But some people do care that you use JRuby in one of these issues. So that's what, when you hear people bitching about things, it's usually people using JRuby who care about this stuff and then end up having to write jobs. So what's the result of all of this, the result of the poor performance management event? Anybody who cares is using JRuby while having Ruby libraries that people care about and use. And some people who care about this stuff use red locals as a solution. So they understand that threading is a problem, so then they just start using red locals for everything. And that gets us over a little girl and then causes further pain downward. I had a couple slides earlier to show what I mean by that. But there is a lot of use of, there's sort of an I now understand and this is sort of a generic problem. I now understand that there is a problem that would just, the card would call the solution. But you start out having a radical people are trying to solve really hard problems and the simple solution doesn't always work. So you're trying to throw an 820 solution at the 20%. That usually doesn't actually work. Once you get to the 20%, you have to actually know what you're doing. And in general we use a lot of the economic people. I think that's good for rail plugins and that's good for protocol spec stuff. But even rail plugins should possibly be thinking about not being impossible to extend with harder things. So you can always, it's reasonably simple to write interfaces that can be extended. But we usually don't think about that that much. We usually just act with what we need and we get it done. Again, I think that this is probably was a good thing for Ruby and Rails that we did this. I think this is something that Rails taught us. But I think we got boiled into a false sense of complacency about it always being the right answer. Monkey patching is another example of this. A lot of get stuff done, we were doing stuff and blah, awesome. Monkey patching is great. Actually, it lets us be productive. It's a thing that Ruby lets us be productive. But we use monkey patching a lot in libraries. So when monkey patching apps is fine, probably some of the patches go together. A lot of libraries are like monkey patching at HTTP. I'll talk a little bit more about that later. In ways that are not really compatible. So you end up with very crazy stuff happening because there's a lot of monkey patching and not a lot of submitting patches. So I know that if you can monkey patch, that's great. It's a good feature of Ruby. But we can also submit patches to the maintainer and probably if there's any good, they will get accepted. So you don't have to monkey patch all the time. Even though it's a good feature of Ruby. A really good thing about all this, all the things that I just said that some of you are too bad, is that we get bad implementation that we've got. So Twitter, if that comes out, we have a library the next day. React comes out, we have a library. That means that the Ruby community, especially the Rails community, tends to be a head of most of the languages in terms of like finding out whether the Mongo or React or Cassandra or whatever works. Because we don't have to use it. Because someone has to get into the library. So a lot of the things that I'm saying about that have this flip side effect of letting us try things out and experiment this fast. Unfortunately, what I think should happen is that once these libraries get done, equals sort of have coalesced, they'll be moving on to solve the last 20%. Too often these libraries, where a hack is going to be gathered together, it's going to be done, put on GitHub, and then nobody ever finishes it. So then there's another one, another one, another one has someone, has another company feels like they need to use this, you know, React. React is not an example, but this is actually the reasonable library. But there are a lot of cases where you just get a lot of churn, because people throw up libraries that don't really plan anything. I think this may all be summed up by the fact that in the Ruby community, we like to operate outside of our comfort zone. And this is a good thing. I intentionally used a positive version of this, right? There are ways I could say that would be bad. We buy off more than we could chew, or I could make it, I could use a spectrum without that. I think that this is the right way to describe it, right? We Ruby people like to operate outside of our comfort zone. But what ends up happening is that people without adequate expertise in some area end up writing a whole library on that thing. If you don't really know HDP, it's probably a better idea for you to be working on that HDP than writing your own HDP library. That is not part of your annuals. You should know that you're working on, right? You don't know yet that there are plenty of libraries you can work on. I think a lot of people feel like that each eye is not good enough. So there you go, write your own thing. And just by definition, because the Ruby community feels strongly about going out and working on things that are not, that you don't know yet to learn, right? I think this is a great aspect of our community. We tend to do a lot of that. I would just encourage people to harness that more as fixed existing stuff and less as build a whole new thing that I don't really know that much about yet. I think it's very hard. The reason why I even care about this, honestly, is that it's very hard to tell the difference, right? I can't tell if you actually know anything about HDP or FDP or React. If I see a library, because I can't, I don't know, I myself don't know enough to be able to evaluate it, right? But you really won't know. So just don't go wrong. So let me show you, I have some cool examples just to show things that I find particularly egregious, just because I weight my hands a lot and I don't want to show what I really mean. So this is a common question, you go to Stack Overflow and it says, how do you bypass SSL certificate verification? And there's about 150 questions like this on Stack Overflow and dozens on various Ruby mail analysts. And 98% of the time they tell you to do this. Why does that work? It works because someone else is saying to whatever library, to the SSL library that their verification should be verified here, which means yes, verified, right? But you have not a whole Ruby, because constants are really constants in Ruby, right? You have a whole Ruby that verified here means don't verify. So now anybody in the Ruby process that tries to tell SSL to verify SSL cert gets verified just to be clear here is what's going on. Here is how verified here gets set in the first place. In the C code is finding the verified here, the SSL verified here macro and is assigning that thing, that constant to a constant Ruby. This is not something that should be changing, right? This is a, in the SSL library verified here means is one, incidentally and when you see that, it means to verify. You should not be changing the meaning of verified here or going together on this problem, right? So I get very angry when I see this but unfortunately everyone says this, everyone, that is the economical solution to this problem is rewrite a meaning of verified to you don't verify for the entire Ruby process. There are solutions to this problem I can actually tell them that HTTP not to verify and oh, I'm sorry that OpenURI doesn't support this in 18,000-19, so I guess if you don't, if you want to not verify you have to use that HTTP for that case or some other library that supports this feature I'm sorry. What we should not be doing in general is rewrite the entire process as definition of the worker but it's common, right? So this is an example. Another example, and this is where I talk to Wes is just overuse of credible so here's the thing that NextCon, so Wes is trying to use, he's trying to produce software and that's probably not a terrible idea but he's saying if you want Google.com 480 a bunch of times, try not, you don't need to use software, try to use the same software and what he's doing is he's storing the list of all those things software key is basically it's the host in the port and some NextCon name he's storing back those sockets in the thread local pool and the reason why he assumes that that's okay is because he assumes that people are not using multiple requests in the same host and port in the same thread if you want to make multiple requests use another thread, right? Unfortunately what happens is that there is a way to make multiple requests in the same host and port in the same thread and that is if you get a callback that you have some data ready you can then go make a request and so people don't know this is an issue in Ruby, they use things like NextCon and it does the same thing or someone tells them you should and so they do that which I think is what Ripple did and then they say wait, I'm having a corrupt handle which is in fact what's happening because they are using the same socket to make two requests at the same time so what Ripple did is they created an object called a pump and if you want to look at this code it's mind-bendingly crazy what the pump does is you initialize it with a block and then it makes a new fiber which uses threads that just essentially doesn't loop and whenever you resume the fiber it will go call the block so basically it seems like what it's doing is calling the block inside a fiber that is in fact what it's doing why is this happening? so the first time I said what's going on why is someone doing this why is somebody creating a fiber just called block the reason why they are using doing this is because Xcon and their own implementation and other things are using sockets and thread locals so they are using this crazy hack here to get a new set of thread locals so that they are storing the socket in another place so what we have here is somebody using thread locals to get around the writing problem without really solving the problem fully then it results in somebody doing very crazy stuff this is actually the same what should you do so there's a known solution to this problem no one uses thread locals for this by the way any other language everybody uses pools some kind of socket pool connection pool I just have an implementation here so you can look at it so maybe the socket pool and to fall the socket pool to a hue set the max and make a new test so yes I know that this requires understanding of the result unfortunately you cannot write red zip code on that red zip code it's a crime to make that possible and I don't think it is and I think when you're writing a QQ library you need to be able to write red zip code so so then there's a socket pool the checkout method basically just goes it synchronizes it goes in and gets the hue out of the socket list and it says if I already made if I haven't made that many then make a new one check in so I don't need to look at all this code I put it on slides just to show that it's not a lot of code it's actually a small amount of code and part of the reason why it's a small amount of code is that everybody has a formula called Q which already handles the hard part of this which is I want to make sure that I have at most I've created 5 sockets for Google.com for 80 and I want to make sure that if I can't if I already made 5 and I can't make any more and so basically what the Q object does is you have an object that looks like a rage it will pop off of it if there's nothing in the Q it just waits on the thread if you throw something into the Q then the thread will be woken up notice that it has received something and then moved on to the site so there is this object called Q it's very simple solves a large number of threading problems and you don't really have to worry about the condition variables and the symboling and all this stuff all you do is you just have something listening on Q and then you push it and it's like a ray that happens to the wall so the nice thing also is that most of you don't have to care about this most of you should just use net-htd or xcon or curve or whatever and they should already handle this unfortunately a lot of people don't so you end up in a situation where if someone wants to share sockets you can't actually solve this problem you just say we're going to have a new socket if you want to share a socket just have an object that you care about you get back an object that has the that is google.com480 and if you want to make another if you request you can make it on that thing and you can share it however you want it's probably better if you find some way to do a pull or something like that but probably not better if it's available another general problem and this may be sacrilegious but there's too much and what do I mean by too much inheritance so here's an example from Rails I can probably get you to agree with me here by writing on Rails so here we have an active model named that inheritance string there's no worth the reason why this thing should inheritance string it's ridiculous it's not a string it may be in some sense to work there's a large amount of code that is not a string what is the damage from an inheritance string what is the danger of it so the danger is a problem that is known as fragile based class I encourage people to go read this would be our whole annual limit step but essentially fragile based class is a problem that occurs in our big learning programming and occurs on mass Ruby in ways that I can both people reason about super well so the problem is a problem that is caused by a feature of Ruby and Java and I don't know why it's called open query and basically the way the conversion works and I'm going to show you an example of why we wanted to work this way we have a class in that class you can see the top method this batch calls 2A at the end and we implement the method 2A to do some behavior and what open recursions it does it says if you have a subclass of action controller and you implement 2A yourself when this slide calls 2A you call yourself you call the class the subclass and in the case of action controller we want that to be the behavior we are creating 2A the reason why we are calling 2A is because we want people in subclass to be able to override this behavior we are using the feature of open version in a way that is convenient to use so basically what open version is you have an object which has a class this batch is being called the action controller object and it basically goes up that method is on action controller so it calls it and then action controller invokes 2A and the important thing to realize is that it basically goes all the way back down when you invoke something it's invoking a dynamic it's invoking it and invoking it outside the object it doesn't know that it's inside the object so it calls it from the bottom because Rails wants to give you that feature it's so common that there's a pattern called template the template pattern or something what Rails implements which gives you an object that you are supposed to inherit and then implement methods to provide certain behavior so this is a common goal unfortunately also on the flip side I didn't intend for you to do that if you have unintentional results so let's add a pair of hash and that's fine I didn't call it a fine entry and that's great Ruby doesn't call it a fine entry and then imagine Ruby 2.0 they add a method called and start calling that all of a sudden my code which worked fine explodes because it's calling a fine entry I had no way to know that it wasn't reserved I never told me I couldn't use it but now it's coming to API of a new version so that in a nutshell is what fragile base class is there is a base class that I inherited from and it starts calling methods on B instead of itself it doesn't know that I had to find a trigger and that causes exposure and that causes problems and this is pretty normal if you use Rails you will find that you sometimes implement a method on a super class that you didn't need to implement and Rails didn't expect to implement the whole problem is that open recursion is a good feature but sometimes you don't want it so when we want it we're usually pretty explicit about it or should be and when we don't want it we can't stop before we can use it anyway so one problem is that it is not documented anyway so even if you want to go upgrade to Ruby 2.0 it would probably never tell you FYI where do you address please make sure you subclass and use them you need to fix that now Ruby is a OO implementation so the thing to realize there is that Ruby 128.1.9 does not implement OO patches the way that you would expect it to behave is that there would be a project that would call the brackets method or some method that would be the underlying method and if you implemented that rejected call that but that's actually not how Ruby works it just breaks things so what ends up happening is Ruby2.0 has exposes on mass a lot of people run into this when they try to use Ruby2.0 but it is a problem that could exist in any version of Ruby that introduces new methods so this is the same diagram that I showed you before so reject calls on by instance of hash it calls off into hash and then you expect hash to call brackets but no that actually isn't what happens it doesn't provide any intentional recursion notes to take advantage of so basically there is no benefit to subclass and RubyNash the reason we don't know these subclasses is if that behavior works but it doesn't so subclass and RubyNash only provides pain it only provides if Ruby ever adds this feature over binnings and has this feature crazy stuff so if you have a desire to use open recursion because for instance real provides an API 2A totally do that for instance if you are not using that feature to use composition so specifically there is a way to handle this problem but instead an error from hash composed of a hash a lot of people have said you have a competition over a subclass a million times this is what it means you avoid the problem of open recursion happening randomly and the only time it really matters is if in the case of Rails because Ruby hasn't actually given you any way to make use of this feature there is no reason to subclass actually there is no reason to subclass string there is no reason to subclass a render so typically don't do it if you do it you are like be aware of this problem and know that when you upgrade Ruby this is the likelihood of open break I want to close by listening a bunch of what I would call new rules for Ruby but really they are old rules they are rules that you can copy for a lot of people doing old languages or even inside Ruby I just want to list them for completeness to canonize what I have said in so called so in general I am using the same style of favor x over y that doesn't mean y is not good it means at this point in Ruby's history we should care about the thing I thought so favor complete the so called quick release now I wouldn't have said this 5 years ago I think 5 years ago getting engaged but today we actually need to finish on that so maybe in 5 years we will want to spend more time on quick release but in 2011 we really need to finish on these libraries we need to not get something out there that's always 8 to 20 rule we need to not get another test library we need to finish the ones that we already have cooperation over an age so there is obviously the case that sometimes an age is a good idea it's not the same that's never the idea in fact Evan who suggested this wording to me is a person who we wrote Ruby sometimes it's an okay thing to rewrite things but you should think long and hard about why you're doing it I was happy I was able to escape a list make sure you have that list it is not easily default before you go on to an age it is actually possible to submit patches it is even possible today to make a fork so I would prefer forking a library that already exists and adding patches to starting from scratch we've done that a lot and at this point we should make do with what comes along now at some point you may find that there are very good reasons to start over and in that case go do it but commit to making the thing that you started at this point it's not useful for someone to say this robust library that already exists doesn't meet my needs for these 6 reasons I'm going to release a library that solves my 80% and anybody else who has the same set of reasons like oh well you need to actually commit to releasing and maintaining when you do an age and I think the reason why I'm not upset at everything or less or many of the other people or myself who doesn't age I grow artists when fake web existed and why did I do that to make it even more stable all the time artifice and sorry fake web and sham rap they do the same thing all do it in a way that is great and will break in that version of it I didn't want that so I have a good reason I would be happy to get my pathisms so just make sure that you're willing to maintain make sure that you can do an age and you have good reasons to do an age that you're willing to maintain the library of course there's a robust library that's not maintained probably you need to take over making sort of lines with it this is a little more controversial and again I spoke to Aaron who runs Noble Theory and Psyche which is a little bit about this to make sure that I was saying the right thing there I think there are some cases where the world really needs to share so XML is a complicated problem it's great for the world to share with XML YAML is a pretty hard problem although I think it can be done really but YAML is a hard enough problem everyone's sharing things and that's great we should use that but there are other problems like HTTP that while they're definitely complicated and have a bunch of moving parts at the end of the day they're not so complicated that they can't actually work in Ruby I want to make a point that I think you probably haven't worked before about writing things in Ruby it is the case that it's the only way to get things working reliably but the more important thing is that we have a bigger choice between having a fast VM with slow C extensions or a slow VM with fast C extensions MRIs with slow VM with fast C extensions Rubinis and JRuby are a fast VM with slow C extensions we have to choose between those two things that is the choice and that means that if we rely heavily on C extensions we are in either slow VM with fast C extensions or fast VM with slow C extensions and they're commonly not made with slow VM so we're going to get very very fast running Ruby programs that align C extensions in Ruby so as a result we need to write more things in Ruby that doesn't mean that today they'll be faster than they go running in C even in Rubinis what it doesn't mean is that we want to actually get to the point where Ruby is running fast where we can be proud of the performance of Ruby which I think is actually going to happen I think both JRuby and Rubinis actually can in C extensions and I think to start with XML it's okay because the problem is hard enough that you should be willing to accept it I have only a couple more slides I know people are going to get out of here so diligence over acts the best example is that verified peer thing I know that verified peer works I know that everyone calls it a hack and it was back over to the post my hack, where do I put the hack? don't put the hack figure out if people are complaining that SSL some Ruby because some library over verified peer, we should be re-evaluating why we're doing that why the entire ecosystem has gems that we're writing the meaning of what verified means we should be revisiting that and we need to as a community if we're writing an app into our library we should really think much longer and much harder about it I get that it makes things work but it means that people literally say constantly SSL sucks in Ruby and this is really the only way I've investigated a lot what people mean by this what they mean is crazy shit happens with SSL I don't know how to make it work and it's because of this problem so just stop doing it and in general don't do ads I already described this in some detail this isn't a totally not new idea it's so easy to Ruby to like multi-pass your way around problems I'll just work on it I'll fix that problem when anything comes out that people don't think too much about it if that person writes about libraries I can say that I have a lot of keeping it stable via using composition to public interfaces you have to use composition you have to compose things that add public interfaces compose objects from public interfaces your back is in trouble but most people do a better job of exposing public interfaces via the object boundary itself and via what is available in the subclass and then I have one last thing and this seems sort of out of place compared to the high level but I think this is somewhat important so Ruby itself does a very good job I have two slides left Ruby itself does a very good job of giving you a low level non-block environment so the IO object in Ruby actually does isn't those how you would do non-block there's a bunch of like all the low level you guys do this and Ruby went on to solve a couple of niggling issues with this but almost everybody who builds the other level in the Ion system builds libraries that as soon as you make a request from the HEP server you get back a thing you have to do a lot of time there's no HEP I for giving you a chunk of that and what that means is that people are building concurrency imperatives like reactors around it can't just use that HEP they can't just say I'll use that HEP and I'll follow Ruby, non-block, I'll get chunks and I'll go in a loop which would be great, a stack would be right and you have the HEP client and the reason for that is because of this when you're writing a library which uses under the hood Ruby IO Ruby socket you're building another HEP client think about how to build an IO that lets you say I want another 100 bucks because it actually will let other people who are not you but who care a lot about this problem like William write abstractions that work better than the existing libraries I don't like the fact that we have to write the blocking and non-blocking version of every library that provides the features that we need to make this work so in closing Solving for age one will provide a really good person productivity then it can take a lot of fun but at some point the language ecosystem needs to solve the last 100% and I think we're there I think we're at the point where we have to solve the last 100% so let's grab the other