 Good afternoon everyone. Thank you for making it all the way to the end. This is my second Red Dot Ruby conference. Probably the third time I've been back to Singapore. So I want to thank the team for organizing this entire conference and then once and I guess for reaching out and inviting me back to Singapore. Hopefully this talk will be better than the one I did in 2012. So I'm Terence Lee. Like I said, I go by hone02 on Twitter. I come from Austin, Texas where we do really, really good tacos. I like to call it the taco capital of the nation. If you're ever in town and I'm also in town, reach out to me and I'd be happy to take you out for tacos. Most people don't actually hold me to this but I have actually done this for people so it's not an empty offer. I known for my blue hats. I do also have blue hat stickers. So if you do want one, I'd be more than happy to give you one probably after party as you head over there. Like Nat said, I work for Heroku and I'm just excited that for all the stuff we've done for Ruby and the opportunity to kind of do all the stuff that we've done. So today is Friday and that means that we have to do the Friday hug. So for people who aren't familiar because you're new to the Ruby community and you haven't heard of it, I believe it's a thing that Aaron Patterson started. He worked remote and he would basically take a picture himself hugging the camera and then people would tweet photos back out. And I've gone around to various conferences and basically done this with the entire crowd and it's been I think just cool to have a collection of these Friday hug photos. So if everyone would stand up, I would appreciate giving the chance to take this photo. Oh sweet, house lights. So I guess just make look like you're hugging a camera. If you don't, you're doing probably just look at the person next to you. They probably know what they're doing. So, ready? One, two, three, happy Friday. Thanks everyone. I'll tweet a photo of that when I'm done with my talk. I also learned recently that Godfrey, who you heard from yesterday, is doing this thing called solo selfie while wearing this awesome Han Solo shirt. So I asked him to come on stage to do yet another photo where we will demonstrate doing a solo selfie so you can then do it at the after party with him while he collects all these photos. So definitely catch Godfrey at the after party if you haven't gotten a solo selfie with him. I know he's trying to create a large collection of them. The other thing that I like to do at conferences besides Friday hugs is Ruby karaoke. And I've been very fortunate that we've been able to successfully do one for basically like the last year and a half at every Ruby conference that I've been to. And so this is us doing Ruby karaoke at RubyConf last year in the U.S. And if you've never done karaoke, it's totally fine, like Godfrey said. But in fact, most people who actually come out to these things have never done karaoke before. And so it's usually their first experience at karaoke. And I've never had someone who has complained to me that they didn't have a good time. And if you're scared about singing, I think the point of karaoke is that you aren't good at singing and that's like half the fun of it. And you also won't be pressured to sing. So you can just come and have fun and kind of just enjoy the company of your fellow Rubyists in a totally different light. And this is just a picture of us doing this at Verruco last year. And that's PJ Haggerty who goes by Espleenek on Twitter. And he has been instrumental in just making this happen. So shout out to him. And so we'll be doing it at 10 p.m. tonight, I guess in the middle of the after-party. I got approval from Winston from Stealing People Away. We'll be doing it at K-Box in Chinatown. It's about a 10-minute walk or so. So we'll be leading a crowd of people if you want to join in. Feel free to come join us. And it will be probably Winston booked a room, but I think around 38 per person. So come join us for karaoke. It will be a pretty good time. And so this is my third conference I've actually closed. And when I first started doing it, I asked Aaron who's done a bunch of these, like, what are you supposed to do for these things? And he told me that you're supposed to try to actually incorporate every single talk in the conference into your actual talk, which sounded like a Herclian task. So what I decided to do was try to encapsulate before my closing talk all the other talks of the conference. And so I first wanted to congratulate just like the local Singapore Ruby Group. Like, it's pretty amazing that it's been around for 10 years. I know that's not true for lots of other Ruby communities out there. And it actually makes me feel pretty old because I've also been doing Ruby for 10 years. So it's pretty awesome that this group has been this healthy and this strong for so long. So yeah. And so with the opening keynote, Matt's talked about soft typing and a bunch of other things. I was super happy to find out that in the Ruby community we can cross off naming things because with the soft typing inference now we don't have to name these types. So that's pretty awesome. In Jason's talk when he talked about playing the dragon, he showed that you can actually build like a Lisp language like very quickly, which was really cool. And I was pretty amazed that you can actually just use this single and for doing a tokenizer thing like this is actually not a very long regular expression. So the first time I've seen something like this. So that's pretty awesome. For the Ruby golf talk that Joy did, it was really neat to, I guess, learn all the ways I should probably not write my Ruby code. But it was definitely neat to see like all the different secrets. I did not know numbers two to four at all. And I definitely think she's right. Like number four is really neat. The fact that you can pass that regular expression in is very cool. Profimatch did a great job of talking about all the changes in Rails 5 testing. I didn't realize that all these changes have actually happened. But I think the conclusion for me was that I've basically been doing controller tests wrong. Like the fact that we should not be doing them. So I thought this meme was appropriate there. Godfrey talked about software education and I think it was great to kind of, A, like kind of tackle that up front with both the boot camps and computer science. And I think he really cracked the nut of it that what we're trying to teach is how to think about things abstractly. And abstractions are a great way to kind of form a mental model for things. But of course like any abstraction they'll leak. And so being able to figure out how to deal with the fact that things will eventually leak as you go forward and like how to deal with those issues is an important part of, I think, that career and road path for being a good programmer in this industry. Next slide. I think I also can't pronounce Gregor's first name. I like to just take away that your API is probably fast enough and I think that is great. But apparently this is, okay, there we go. Sorry, technical problems. And also enjoyed his advice. He gave us a lot of great advice for how to do things with CDNs and whatnot. But I did enjoy his advice about don't be a smart ass with that. On to the lightning talks for the first day. Joe did a great job of talking about why people are leaving companies in general. I think the turnover rate in tech is astoundingly high. I think like if you make it up to like a whole year at a company, that's like you're basically really old and a veteran at that point, which is kind of crazy. But for me, I learned that basically Google is filled with lies, which is news because I thought everything on the internet was true and that people don't leave because of managers, which is something that I never thought of. So that was neat to learn. Shabata-san talked about how you can easily contribute to Ruby. I think it's nice that he highlighted in a single place that you can basically run the test with six simple commands. And the other thing that I learned was that documentation is really hard in Ruby, which is nice to know because I feel like that's the common advice you get oftentimes about contributing to open source projects. Like, oh, you can just contribute documentation. And like actually understanding how all that stuff works can be difficult. And Keeta talked about speeding up the test suite. But I did appreciate in the beginning. She gave a bunch of advice, but the fact that, man, these slides are not changing. Okay, there we go. That if you have no tests, there will be no slow tests. I thought that was pretty neat. And then next we talked about basically like flexible authorization. Having done some authorization stuff in the past, this would definitely be challenging. But it was neat to kind of see the forward progress in making a better authorization system that allows, I guess, more power to the end user and not have to kind of step in and dive towards those things. And I also didn't know there was an open standard, so that was new for me. That was a CML. And then Tim gave a talk about kind of next generation web apps. And it was neat to see how you can basically build an architecture of stuff where, like, the ability to easily change things is kind of at the forefront of it. So just having like a positive architecture provides maintainable, sustainable, and joyful development. And I'm pretty sure people who have dealt with legacy Rails applications are aware of kind of the issues that come from dealing with older code bases. So seeing something that tackles those problems up front was really neat to see. And then Xiao Xiang had this great talk at the end of the first day where he showed us a bunch of simulations. And I think I was just amazed by when he actually opened the code of how simple it was. And it was neat to kind of see, like, oh, it doesn't actually take a rocket scientist to do, like, kind of these crazy simulations. You can actually do it inside of Ruby and kind of run your own experiments. So I thought that was really neat. So for the opening keynote today, Aaron talked about a reference to my talk, but that's kind of weird because I'm doing my talk now. So I took a picture of him doing this so we could have a circular reference at this conference. Samir talked about scientific computing and Ruby was really awesome. I thought that the iBook thing was just kind of just a really impressive demo that you can just do all that stuff in line. But for me, the thing that I learned was about Daru in Hindi that it meant alcohol. So I thought I would put up a thing for the Singapore sling, which was what I think about for alcohol when I come to Singapore. I thought Constantine did a great job of just kind of disrupting salary stuff in general and kind of the thought process behind how Travis reached the point where it did. And I mean besides, foreign currency is being really hard and I thought that gold example was kind of crazy for the redeems. Just like salary stuff in general is really tricky, so kudos to Travis for paving a better way forward and I'm looking forward to kind of how all that stuff works out and as they get closer to open sourcing and having those discussions. Vipple talked about a bunch of stuff about speaking up front-end. There were many things that were actually happening in Rails 5 and I talked to him after and he said, oh yeah, that's only kind of the tip of the iceberg of all these changes that are actually happening. So looking forward to all the things that are coming in Rails 5. But it's nice to know that we can now cross another thing off of hard things in computer science because from all the caching stuff, I remember back in the day when Russian doll caching came out, DHH was saying they solved caching. So decided that we've now crossed off like two of the hard things in computer science. As Sianis talked about the Internet of Things, it was just like really impressive to kind of see all the stuff and how approachable it is. I don't think I've seen people talk about it a lot at various, well not a lot, but I've seen a few talks about it at Ruby Conferences. And I think the crux of it for me, the takeaway was now that it's becoming more consumer friendly and more developers are digging into it, like what are we going to do with the data and how we handle all that data is going to be really important in the future with both machine learning and other things and big data, and it'll be neat to see how we as a community kind of tackle those problems. Yasuko did a great job of talking about upgrading Rails. One of the quotes for me that really stuck out was I think it's very easy when you talk about legacy systems to kind of throw all that stuff away. And one of the things that Yuuda's told me a lot while working with an open source is like it's dangerous to just throw away that old legacy code. And I think this quote from her talk really highlights that, is that the fact that this system exists and it's solving real problems means that there's probably things that you may not understand, but it's actually solving real problems and you should think twice about just starting stuff from scratch and throwing all that stuff away because there's a lot of intelligence and knowledge built into that code. So on to the blog posts. I really enjoyed this Japanese quote from the blogging thing, or the proverb I guess, three years on a cold stone will make the stone warm. But I think this applies beyond just blogging like perseverance and kind of dedication to something really pays off in order to either learn a new language or really want, like if you want to contribute to Rails, it definitely takes a lot of effort and time and having that motivation to keep going I think makes a big difference there. I thought that the kind of whole story that Jack gave of interacting the maintainer is unfortunately not a rare thing, but it was sad to see the results of that ended up the way it did, but I'm glad that you learned many things from it. Yeah, I definitely don't believe in the stars on GitHub, it can definitely reflect different things and I think the other key takeaway from that talk for me was that PRs can be used as a conversation opener and you shouldn't make them this absolute perfect thing. You should definitely put work in front for them, but definitely use it as a way to start a conversation with the contributors and maintainers of that project to then work towards an eventual thing that would yet merge. Yuki talked about a bunch of stuff I actually had no idea about the experimental stuff so that's neat to see hopefully we'll see that stuff soon in a new release of Ruby so I don't have to require a specific thing for it, but he talked about a bunch of different tips, some of them I've heard before and many of them I didn't but I'm definitely most excited about the explainshell.com because there's definitely a lot of archaic things I think in shell that it would just be nice to have someone kind of tell me what those things are and what they're actually doing. Steven did a cool job just talking about React and telling why people really flock to this framework and how you can kind of apply those paradigms down into your Rails itself and I think it's neat to see that there's a lot of additional programming languages like Elixir and Framework Phoenix Beyond the Rise that these kind of declarative paradigms allow you to easily reason about where problems are in your codebase and how to make sense of all those things and where you need to look which is really neat and welcome to the Ruby community it's nice to see people I think one of the great things is that people always being welcomed and joined into this ecosystem and for sure like the stuff in those code schools are very far from what things are in reality but I think just this whole journey is pretty magical of just having that feedback loop and having access to mentors and being part of a larger community so good luck on your journey there thank you for taking the time to give that lightning talk and finally for the Keras talk of course regular expressions are really hard and I'm glad that we're pursuing stuff where as an end user I don't have to write very fragile code and I'm looking forward to seeing how those things progress so yeah so that's kind of what I had for all the other talks for mine so let me get to I guess like my story and I guess the crux of the talk itself so before I get to my Ruby story the first real programming language that I learned was Perl and I really enjoyed Perl at the time but then when I went back and actually read my code I found it really hard and the moniker of like a right only language started to make sense to me and this relates to kind of the Ruby golf things like all those short hands and things could make things very unclear to write but it was really cool I think Perl's like one of those like epitome like golf kind of languages like the amount of stuff you can do on a single line is kind of crazy but it was great for scripting and then when I got into web development like I went towards PHP and I think there was probably many of us back in the day in Ruby who dabbled or did a lot of PHP but we were definitely left like fairly unhappy and I heard about Rails which was kind of this holy grail in my mind at the time when I was young and I was like oh this is like the silver bullet that's going to solve all my web development problems so after hearing a bunch about Rails I picked up this pickaxe book back in 2006 and starting learning Ruby and since then this was a language that really spoke to me and I've been very fortunate to be able to work on various different open source projects in addition to having a full-time job that paid me to actually use the Ruby language every day which was really cool so I got to work on Bundler for a few years and then maintain rescue for short stints Matz for some reason gave me Commit to Ruby and I've helped with I know Rails Girls used to have a strong following in Singapore that's now changed to its own thing but I was I hope with open sourcing the Rails Girls guys which was a really cool kind of just experience to see that whole community there so kind of after doing this for ten years like why am I still using Ruby like there's so much other stuff that's happening and so much interesting tech that is happening around us and I think first and foremost for a lot of us like the Ruby community is a really special place there's a lot of I've met so many amazing people in my journey for the last ten years that are now like really close friends of mine but even beyond that like every conference I go to I always meet really cool people that are doing some pretty amazing things and the fact that RailsBridge and RailsGirls are both successful in the community means that we've done at least a decent job of trying to be inclusive and trying to make it better the fact that we care about things like diversity is just really neat to see where at the forefront of a lot of that you know we're not where we want to be but like the fact that it's an open issue and like people talk about it is really great to be in that community and something I'm very proud of and then even beyond just like that stuff I think it's really neat that we in the community itself like encourage people to explore other languages and go to learn and do stuff and not just do everything inside of Ruby itself I know Matt says he can't leave Ruby but like I know he examines and does research on other languages too and you know for some people they leave and they don't come back they find greener pastures elsewhere and for others they do stuff and then bring stuff back and make Ruby better I think it's great to see Ruby conferences like bake this into a thing so like at RailsConf this year Rella gave a talk on Phoenix this Rails like framework inside of Elixir and the fact that there was this alternate framework track that is like sanctioned as a part of RailsConf and is just like great to see that you don't see in many other languages and one of the things that Ruby's been around for a long time is that it's not considered cool and I think you know like this blog post by Jared Freeman really kind of hits that point home a little bit that like oh back in the inflection I think around 2014-ish like Node.js was more popular search term and like it's climbing and skyrocketing while the popularity of Rails is kind of diving down and in his blog post he talks about how if he was to start a new company he would not choose Ruby or Ruby in Rails as the kind of language and framework of choice to kind of base but on the flip side of that coin is that you know like we're starting to become a more mature ecosystem I think Rails came out in the first release of Rails was in 2005 so it's 2016 so it's over 10 years old and a lot of these things have means that for web development specifically like we have all these efficiencies and being able to do like if you're going to build a new app in and something like Rails it's actually fairly quick and I think it would be hard you'd be hard pressed to find something that you could do just as well as Ruby I think that's something we do really well and like like Matt's talking about just like forgetting like I don't want to worry about small things I think there's something really unique about the really ecosystem community and like one of the values we have that I think other communities don't is that we have this unique attention to detail that we care about we care about the developer experience like I think the tools that we generate in our community care about error messages like that error messages are good that like you don't have to do extra steps to do things and so this is a quote that you could have gave me when I was talking with him the other day just like coming back to Ruby and doing some things every now and then it feels like a breath of fresh air so it isn't something you get to do all the time it feels really nice to come back and use this language and the tools that are in this ecosystem but of course there are also downsides to doing stuff in Ruby not everything is on this golden path there are less well-traveled paths that aren't as well-developed and so I'm gonna go for the meat of this talk into like three different use cases that I think Ruby has maybe not done as well over the years and kind of explore like what we can do about that so I think probably the biggest sticking point that most people talk about is that people think Ruby is slow and at this point definitely at Heroku 2 like fast as a feature like people want things that are performant and I think like as a community we've taken that to heart right like at Folio and I think that's why I think that Ruby 3 and Matt's have gotten together and started this Ruby 3 by 3 initiative which I think is really great I'm excited to see when Ruby 3 actually lands and to see kind of all those performance gains but even before like Ruby 3 hits I'm very happy that Heroku has sponsored Matt's Koichi Nobu for the last I think like five years we've had like regular release cycles like every Christmas now since 2.0 like 2.1, 2.2, 2.3, 2.4 coming out this year most likely will land on time and we've also seen actual iterative improvements that we can use on a regular basis right so like in 2.1 we got the generation garbage collector in 2.2 we got the incremental garbage collector both of those Koichi worked on and 2.3 there's a bunch of other performance improvements like ahead of time compilation stuff that Koichi's exploring and it's neat to see that this isn't stuff that's like you have to wait when Ruby 3 lands it's stuff that you get to use and is free to use by just upgrading your Ruby which is great so thank you to the Ruby core team thank you Appfolio, thank you Heroku and everyone else who's contributed to kind of make this a just better run time and so I'm super thankful that is things that we don't have to do and we just get better performance but the perception of Ruby being fast is still a thing that we have to tackle there has been in the last five years or so a handful of companies who have started off in Ruby or had departments that started off in Ruby and have moved off, one example this is LinkedIn there's only one that was Groupon and specifically for LinkedIn they moved from Ruby I believe to Node and the reason why was because of the fact that Node does such a good job like in Keras Talk we're talking about leveraging like IO performance so I think about doing like micro web services that maybe call a bunch APIs or do a bunch of database calls and you have all these micro web services that do this work and Node from the ground up does a really good job of doing all these things so when you're building a micro web service to do that like as a technology stack Node makes a lot of sense you have in your standard library non-blocking evented IO libraries and functions right which is not the case in Ruby and I am thankful that in Ruby when I'm doing stuff that this is not a thing that I have to do but it does make a lot of sense when you're building these kind of apps and so I don't know how many of you are familiar with the JVM ecosystem it sounds like some of you because Pitbull I know is doing a bunch of that but there's this micro framework called Rat Pack and I think we're really fortunate to have a bunch of different VMs like J Ruby out there that allows us to leverage basically the entire JVM ecosystem but still do stuff in Ruby and Rat Pack Rat Pack is a HP framework that is invented from the ground up and it leverages Netty if you're not familiar with which is an event driven networking engine at the low level that allows it to be highly performant so a lot of similar things that make like NodeGrate and so I said reactive like and so what does reactive actually mean so I think for most people it means the non-blocking communication so the ability to kind of do that work like in the chat bot where you don't have to wait for the server or for the for some call to come back while you're doing IO and just block the whole time and I think a really good real world example of that is like if you're calling customer service so I think the standard case is like you call like customer service and you get put on hold and you basically have to wait there until like the next customer service representative is available and that is the example of like a blocking call but there are some customer service places that actually just take your phone number and then you can get off the phone do whatever you want and then they eventually call you back and so to me this is like a very close example of like what a real world blocking versus non-blocking looks like and so Rat Pack gives us the ability as we're doing any IO in it we have this async non-blocking communication and we're able to leverage the concurrent libraries inside the JVM to kind of do this and have all this non-blocking stuff from the ground up so what's nice about Rat Pack and doing it inside of JRuby is that we can write code so this is a simple hello world that looks very similar to Sinatra not knowing like any Rat Pack stuff I'm sure you could read this and more or less understand what it's doing of course this is very simple but the handlers block basically allows the handlers inside of Rat Pack it basically defines like all the asynchronous non-blocking code that we want to do and inside of that we're just setting up the various routes that we're going to have so you have a chain for get and you can use any of the HDP verbs and then as a parameter to that you just pass the path that you want to do so very similar to how Sinatra's get and post and all those things work but where Rat Pack really starts to show a difference versus doing something in Sinatra is the fact that you can do streaming super easily so you can do streaming and leverage the fact that this stuff is async so you're not going to block on the stuff like you would inside of Rack and not have to use like Rack Mallow or something like that and so in this example what's nice is that while we're streaming we're consuming work on the server by any time that it blocked it has to basically wait for stuff like another route can get processed or that stream while it's waiting can work on another thing and so that allows us to achieve a lot more concurrency and throughput while writing fairly like understandable code and so to set up a simple benchmark to show what kind of performance you would get from doing this kind of stuff I wrote a very simple thing that simulated basically like doing some type of IOCALL like fetching results from a database so in this case I'm just sleeping for 300 milliseconds and then I'm just returning some response back and when I compare this with basically the comparable code in Node which I'm not showing but I'm happy to show anyone after the talk we see we actually get fairly comparable performance numbers the Rat Pack stuff looks better but I would just go and say that you can get comparable performance writing this kind of JRuby code that is fairly easy to read and understand especially as a Rubius and not have to reach out to something like Node when you want to build micro web services so to me that's like very exciting because this is stuff that you can use today this isn't some like future tech that is around but you can use Rat Pack today with JRuby to write stuff in Ruby itself and do things that Node is really good at and if you want to learn more you can go to this link there's a blog post that basically details all these slides and it walks through kind of explaining Rat Pack more and the things you can do with it and kind of setting up running it and deploying it to our Heroku so that's there I'll publish the slides and tweet it so you don't have to write in that stuff down so we talked about IO for a little bit so now let's talk about like CPU bound performance so for this you probably you would think of like number crunching machine learning any kind of intensive algorithm for that kind of stuff and I think this applies beyond just that kind of work like this what you would think is the quintessential thing you would do for CPU bound work and in Ruby itself when you're doing a Rails app Sam Saffron in this pull request actually posted this graph of the kind of the CPU time of the call methods and at the top that he highlighted in blue you see blank which is active support blank and he said that it marks basically like almost 4% of the total CPU call time to process this request what you're thinking about like that's actually kind of crazy like blank is not a very complicated method so this is the implementation of blank it basically just checks if you're if the string is empty or you have white space characters and if it does it returns true or else it returns false like not a very complicated method but the fact that it consumes almost 4% of like a request is a lot of CPU time so what can we do about it I think the standard solution to any kind of CPU intensive thing is to write a native extension so of course that's what Sam did and so he wrote this thing called fast blank and this is the code you're not expected to read it and with that he was able to actually achieve pretty nice improvements right so when you're just doing a normal benchmark he was able to get 20 times up to 20 times performance improvement over the active support implementation of blank and then on some macro benchmarks he was able to improve the performance by 5% which thing about for just a simple optimization like this is actually a lot of performance for a running Rails app but the problem with that is that writing stuff in C for I think a lot of people is not easy and actually learning like learning the language of C is not tricky it's like becoming good enough to feel confident about the C code that you've written so as an example that this is Noka Gary which is a if you're not familiar a rapper around libxml2 and just going through and searching for it you see that there are issues that come up for just segfaulting and issues with using it that come up so even like seasoned veterans of libraries that basically that's all that this library does runs a problem so like doing stuff in C I think for a lot of people is non-trivial and can be very tricky to write safe code so let me introduce you to Rust which is a systems programming language kind of meant to tackle these kind of issues and problems and so this is a copy and paste from the if you just go to rustlang.org of what it is but I think what makes it really neat is that it tries to tackle these safety concerns that people have with doing stuff in systems level programming languages and also introduces like higher level primitives that we're used to inside of Ruby like iterators and macros and things like that so for instance when you actually compile a Rust program the compiler guarantees that you won't actually run into a segfault in the future at runtime so this is really nice because as people who are used to not dealing with small things like this kind of stuff that you have to do with C is definitely like a lot of small concerns that you definitely don't want to deal with so that level of confidence and the other nice thing benefit of doing something in Rust is that you have this thing called zero cost abstractions and what I mean by that is in Ruby every time you define a method or your factor or something into something cleaner like we saw throughout this conference there is a minor performance hit to doing a method call you put on the stack and you have to call it and generally this doesn't matter but if you actually care about the performance of that thing like every little bit counts right but in Rust you don't actually have to make this trade off because you pay that cost at compile time the compiler is able to see these methods and kind of optimize the code in that way where we're not able to do that in interpreted language like Ruby and I was talking about higher level primitives like each in map and things like that and it goes so far that when you do something like each in map it actually gives the compiler more information so you it's actually faster than writing the loop by hand with like a for loop and because it doesn't actually have to do any of the bounce checks which you would have to do with a for loop so it's nice that it actually encourages you to use these higher level primitives that you're used to using in Ruby so in Ruby like it might be slower to actually like do something like these fancy things but in Rust it's actually not so that's what I mean by zero cost abstractions and so the implementation of blank versus that C code the kind of Corvid is this so not knowing any Rust at all if you're to read this you may not know everything that it's doing but this is actually fairly readable code like there's pretty high level primitives here where like is white space the fact that it has this all iterator so it uses you know parentheses instead of curly braces and it is statically typed as we see because there's signatures and stuff there but this code isn't actually that crazy as a Rubyist reading it not knowing anything about Rust and so Godfrey and you could actually ran some benchmarks of this implementation of blank versus fast blank and of course Ruby and you can see that versus the C implementation of fast blank we actually get fairly comparable performance which both are simply faster than doing an impure Ruby this code in yellow are the codes I put on the slides that were earlier and all the other code and so that's like kind of the unique code that kind of describes solving that problem and the gray code around it is kind of the boilerplate code that you have to write to get this Ruby gem to actually work so as you've seen in the Rust case it's kind of a fib to say like it's not actually that much code because we're writing all this other boilerplate to kind of make the Rust part work so that's not that great if we actually want to do this on a more regular basis to have to copy paste and do those things all the time so let me introduce you to this other project it's called Helix they work on this project called Helix which is kind of named after this bridge in Singapore so I went out actually on Wednesday night to take this photo so I could put this in the slide and so this is a picture if you don't know of Yehuda and Godfrey who are actually working on this project and what Helix is it's this bridge between Rust and Ruby that allows you to kind of remove all that boilerplate code all that stuff in gray so you can just focus on solving the problem that you want to do in Rust and so you can actually define like Ruby classes inside of Rust that do the work that you want to do so all that stuff can be replaced by this simple slide here and this is all the code that you have to write in Rust to make that happen so it's definitely smaller than that code from a few slides ago and what makes this really exciting is kind of having something like Helix unlocks a lot of different opportunities I think if the cognitive load of actually writing a C extension is sniffing lower, you can start talking about doing it for other things beyond Fast Blank like even for a specific app that is not like a general Rails thing you could start profiling your app like Gregor talked about and if there are things that are called a lot or take a lot of CPU call time you can actually reimplement those things using Helix inside of Rust to get the performance you need and massively improve the performance of your application there is also talk of like inside of active support like stable APIs that would make sense to reimplement in Rust to kind of get performance and kind of extrapolate those kind of things out I think there is a really exciting future where we can do more things like Fast Blank where all you have to do is basically include some type of gem like turbo blank or turbo whatever and actually just get that performance for free because we are running inside of a native extension and if you want to learn more about that Gottfried did a talk at RailsConf which is on confreaks.tv if you look it up under RailsConf 2016 or you can actually go to this blog post where he kind of deserialized that talk into a blog post that kind of describes all this stuff in more detail and the last kind of big problem I want to talk about is packaging in Ruby and you know like in Java you have stuff like wars and stuff but in Ruby you kind of have to deploy all this source code and then bundle install and do all this stuff just to deploy your app and to kind of illustrate this story I want to talk about the Heroku tool about if you aren't familiar with it it's the CLI command line that you use to interact with Heroku instead of using the dashboard you can do stuff on the command line and it has a long history Heroku has been around for I don't know like nine years or something at this point and when we first started trying to build something like this we started with a Ruby gem so you would gem install Heroku and you can still do this today though I don't think it's kept up to date and this was kind of a decision at the time because Heroku started for Ruby developers and it made a lot of sense to build something that was native for Rubyists to use so you would just gem install Heroku and then you know you create a Heroku account you log in and you're kind of off to the races but it had its own set of problems as we became polyglot and started supporting other stacks and languages it was an issue because as a Python person in order to use Heroku I had to now install Heroku just to gem install Heroku to then use this product where I had no interest potentially in Ruby at all so that was an issue for us and beyond that even for Rubyists like it became a support issue because people could have totally different versions of Ruby and then this was even before like RBM was a thing so most people were using system level Ruby so like if you were running a different version of OS X or version of Ruby so then we had to make stuff always compatible with Ruby 187 because that was the oldest version of Ruby that Apple kept keeping around for a long time so we could never use any of the nice syntax and things that came out in Ruby 19 so then to solve that problem we decided to package the Ruby runtime inside of like a tarball itself and distribute that in and of itself and that was really great to solve that like what Ruby runtime are we using and what are we supporting but then it kind of turned all this work of actually packaging into our hands so then we had to have like actually a separate windows box that sat under someone's desk with like windows licenses and things and build that Ruby binary with the package and distribute that we had to do the same thing for OS X and then when Apple decided to add all the signing stuff like it broke and we had to go fix that and then same thing for Linux we had to do special things for Linux and then you run to all the distribution problems with Linux being fragmented too and so as you imagine this is like not a great experience and it made it hard to actually like package and release new versions of the tool belt whereas before like publishing and doing stuff inside of RubyGem is actually easy you just like publish the gem you just run a single write task and you're up and running and since then there's been a project and so now the current tool belt is a mix of like Go JavaScript and Ruby though the Ruby code is being removed and at the start of that was this project called HK that a parochial employee worked on and the main there was two really big motivating factors for that one of them was that like I was saying fast as a feature and so the speed of the HK binary was simply faster than doing stuff inside of Ruby so if you just look at this top benchmark here running Heroku version on the Ruby CLI at that point took over a second and then the Go version, mainly it did less things was like 16 milliseconds so if you want something that's like highly interactive you can imagine that that kind of sucks to have to wait a second every time you're trying to do something with your product and part of the crux of that is that like require Ruby is not very fast so as we modularize the code base because we didn't want to have like one single file that was huge that had all the commands and things we broke stuff out like you have to actually pay that cost every time at boot up and so then we did a bunch of work to kind of minimize all that stuff so we don't require the files that we actually needed and then the second part of that was Go was able to basically create the stackly compiled binaries that were portable so we could compile specific ones for each of the different language versions that we needed so that made a lot of sense and even beyond the Heroku case there are examples of like inside of Hashicorp they've done a bunch of stuff in Ruby they had Ruby CLIs and I think Vagarin is still a Ruby CLI but all their new projects now are written in Go for CLIs because of just the benefits I elicit like it just makes a lot of sense when you're distributing this to actual customers and I kind of found at the end of the day that there aren't any real great packaging stories like there's traveling in Ruby there's other things out there but all these things are kind of this manual process where you have to trust on them to build these packages for you and if you kind of stray off that golden path you're kind of out of luck so I started a project called MRBCLI that was really focused on trying to tackle this problem and at the crux of it is this project called MRB that Matt started which is to get another Ruby VM and it's an embedded Ruby that is meant to be embedded in other languages which provide a lot of benefits but also had various trade-offs so it's a lighter weight Ruby it uses less memory but also forgoes like all the IO and kind of other things that are associated with platforms a lot of things that you're used to inside of standard Lib don't exist and the fact that it also doesn't have a standard Lib and we had a bunch of design goals when working on this project the first one being I want to be able to write stuff in Ruby I don't want to write like a CLI in Go or C or something else and so inside of MRB, MRBCLI MRB uses this MRB Lib directory and we generate all these files and you can actually just write this Ruby code and you just write straight up MRB and it looks very much it pretty much is like regular Ruby code minus a few differences fast is a feature I know I've said that a bunch of times in this talk but it's true and specifically what I mean for this case is the boot of time right like how fast can I get to actually executing Ruby code and in this case in MRI here's the typical like Hello World MRI use case and this is a few versions old so I think this like Ruby 2.2 it takes like 41 milliseconds just to print out Hello World to the screen and then when I was able to do this in CLI we can get it down to 3 milliseconds which is a significant speed improvement and fast enough where it doesn't make a difference like you don't have to get it that much faster to make that experience good and how we do that is inside of MRB there's no require so all the stuff is loaded up front in memory so you're not paying that cost of searching the disk because it's compiled into the binary and then we also want to have this portable solution that generated a single binary for every platform so with MRB CLI when you run the compile command you get a 32-bit and a 64-bit binary for both Linux OSX and Windows so you can package that up and distribute that to your customers and then we also want to file size that wasn't massive because we're packaging the entire MRB interpreter and it's meant to be small so the OSX version of MRB CLI is under a it's like 421k and then for people to actually use this it has to be pretty simple to set up all these cross compilers to actually build these binaries you don't want to have to do all that stuff by hand in order to get started you have to download all these various versions of GCC you have to download them in GW you have to download all these things to get started so we actually set up a set up for you that will cross compile from Linux to Linux itself, Linux to Mac and Linux to Windows and kind of tackles all that set up work that you have to do up front to get a working system so using this thing here's what a hello world example for just running through the workflow is you download MRB CLI from the MRB CLI project it's just a binary you can put it anywhere on your path and just run it it's like Rails new and it generates a bunch of files you go into that directory you run the compile command with docker and then you're able to just execute the command and then you see hello world so that's all it takes to really get started there and here are all the files that we generate I think Rails does a good job of like making sure we don't have to bike shed on stuff so we want to provide a similar experience there so you don't have to set up any of these things by hand and then all you really have to do is you have to edit this file and this is really the hook into how you run stuff inside of MRB CLI so there's this underscore and underscore main underscore and underscore that you can just write whatever code and then any class or whatever that you put inside of MRB lib will become available that you can call and then the argv is just like the standard array of arguments that are passed in and so you can learn more at mrbcli.org and after I gave a talk about MRB CLI Steve gave this talked about this tweet about kind of just like it's great to learn on the languages I don't think you should stop exploring and learning those things but it's also good to recognize like what Ruby isn't good at and if we want to continue doing stuff with Ruby we kind of have to look at these weaknesses and look at actual solutions because people are running into these every day in the real world are causing people to leave and I've been doing this for 10 years at this point Ruby specifically and I'm definitely super excited about the future of Ruby and I've never been more excited about kind of where things are going both all the things I've seen with Ruby 3 the Ruby 3.3 project the projects that I've talked about in this talk like being able to work on things that solve the IO bound problem the fact that I mean Helix isn't totally there yet but like a future where being able to write native extensions that improve the performance of my running Ruby app and the fact that we can start looking at packaging things and making that a better story is really neat and even this year there's this index that kind of measures the ratings of like engineers and kind of searches for the language itself Ruby went from 16 all the way to 8 last month which was really cool to see it like spike up again and so it's the highest it's been since kind of the peak rails hype so that's also exciting that there's kind of this resurgence of stuff in Ruby itself and I implore you to keep writing stuff in Ruby and without the fear that you're going to hit some wall because it really sucks to pick a technology and then be forced to move away from it because of some technical limitation I think we're getting to a point where there's going to be a future where that won't be true anymore so thank you Red Dot I'm really excited to be here and thanks for having me I assume we don't have time for questions Thanks Terrence for your wonderful talk it's been a while since I practiced some Ruby and I think I'm getting a bit rusty nice we have I believe we have time for questions for Terrence I see people moving to the mic awesome I have two first question when you were doing the example of the blank method in Ruby C and Rust it just kind of like slammed into my head why aren't we testing for a blank string first return true if the string is blank and then create the regular expression or whatever only if we need to I don't I feel like Godfrey could probably tell you a better answer I don't know if you want to come up and answer that I guess it's slower Rails 5 actually the example on the slide was actually the Rails 4 implementation for simplicity I believe I believe of this very moment the version on Rails 5 on master actually has the empty check in front there are some ongoing it does not according to them okay so there are basically people try different things and then like the current version is more fast in the in a general case like if you can get different styles in very long strings very short strings padded strings and stuff like that and I think it's hard the takeaway is it's hard to do it generally for a lot of cases with those kind of micro optimizations okay thanks my next question is will Rust work on JRuby? this was something I was actually talking to Godfrey about I think there's a way we can get it to work with J&I in Helix and making that code work but probably out of the box not yet there's this stuff inside of Rails like we would probably maintain both I was talking to Matthew Draper about this actually the speakers last night we would probably maintain both the Ruby version to fall back to if your platform didn't support it and then we would have the Rust thing to for the cases where we could get that I think JRuby specifically is significantly less affected by this problem the MRI because of the VM itself and also when you're writing stuff and if you wrote a native extension inside of Java you're probably able to achieve the performance delta would be significantly smaller than it would be an MRI thank you hi writing the extension in Rust is great a lot of us don't really know C but I tried learning Rust and I ran into a lot of harm speed bumps the borough checker so do you have any tips for people like that for basically fighting the borough checker I definitely have had to read in Rustlang basically the borough's documentation a bunch of times I think that's just a thing that will be a thing for a long time for anyone who's learning Rust but I think that's also kind of a huge benefit of Rust the fact that there is the borough checker is that they didn't let you compile that code because you're doing something that's unsafe and so that's just a thing that over time you'll have to learn I don't have any great tips I also run to I still fight the borough checker all the time today as well but I just recognize that's me doing something dumb that the compiler is telling me I shouldn't be doing and in C I probably would be able to just compile this code and then I would find out later in production at runtime that I did something dumb right Any more questions? Okay It seems like there's no more Thank you, Terrence again