 The full title of this talk, which does not actually fit on most CFP submission forms, is the Illustrated Adventure Survival Guide for New Rustations and Natives of Rubyville, with apologies to Why the Lucky Stiff. How many of you are familiar with Why the Lucky Stiff's work? Awesome! That's so great! That's the most people I've seen in a room, and I've given this talk like ten times. Well, okay, so if you are familiar with which many of you are, you'll recognize a few things in this talk. If you're not, I would strongly recommend looking him up after this. He was a Rubyist who did a lot of really interesting work. That was a big reason for me getting into programming, and this whole talk is kind of an, well, half the talk is an homage to Why's Pointing Guide to Ruby, which I think you can find online somewhere for free if you want to check it out. Anyway, welcome. I really have to commend you. It took a lot of courage to sign up for this mission. This adventure we're about to embark on is not for the weak or the faint of heart. So if any of you are pregnant or nursing, or suffer from any kind of heart condition, or if your doctor has advised against the eating of spicy foods, I ask that you consider consulting your physician, spiritual advisor, psychic medium, or nosy next door neighbor before accompanying me on this journey. While we wait to board the ship, some of you might want to know a little bit about me, your guide, before moving forward with this seafaring journey, and I get it. I understand. I don't look quite like a seasoned ship's captain, and you are right. I'm not. I'm Liz. I used to be a cartoonist. I drew comic books. I went to art school. I drew a few graphic novels. A few years ago, I learned to code. I went to the Flatiron School in New York, and I started working in web development. Nowadays I work at Tilda in Portland, Oregon. Mainly I work on our product Skylight, which is an application that helps developers working in Rails or other Ruby-based frameworks to optimize their own apps. We also use Rust, which is a big part of why I started learning Rust in the first place. So before we get on the ship, I'll show you a map of where we'll be going. Right now, our ship is docked at the port of JavaScript, just off the coast of Rubyville. We'll be sailing the seas of chunky bacon, and should be landing at the cargo bay of Rustlandia in no time. So let's get on board, take your seats. No standing. No eating or drinking, but most importantly, no staring at the ship captain's eye. He's really sensitive about it. So say goodbye to your loved ones, and off we go. Sailing, this is a song about sailing. I don't know the rest of the words. If you all look out your windows to the west, you'll notice a beautiful sight, some foliage that's native to Rubyville, an abstract syntax tree. Its nodes are particularly lovely this time of year. You're probably used to seeing these if you're from Rubyville. They tend to sprout any time some code gets thrown into the interpreter just before it gets turned into bytecode so the Ruby virtual machine can run it. As you might already know, Ruby is an interpreted language, so this is more or less what you're used to if you're a Rubyist. But in Rustlandia, we have to remember to compile our code before we can run it, otherwise it won't work. So when we get there, just remember two key phrases. Cargo build and cargo run. They will come in handy when we reach the shore and start trying to chat up the locals. If you try to just run your code directly like you did in Rubyville, they won't know what you're talking about. I almost forgot to mention on the way out, you'll notice a big pile of mains. Don't forget to take one. You'll need to put all the code that gets run for your program inside of main unless you're building a library but we're not there just yet, so very important. All right, everybody off the ship. Here we are. Welcome to Rustlandia. Let's check out the town. Remember, things move a lot faster here, so be careful. Look it out. It's the stack and the heap group of let's go inside. You're probably used to not giving much thought to memory back in Rubyville. Before I came to Rustlandia, I had heard of the stack and the heap, but I knew what it's like to do with memory, but I didn't really understand it. So watch how things work at the bar. People come in and they give their programs to the bartender and she compiles and runs them. Someone wants a fancy whiskey and a cheap whiskey. The good stuff is fancy, so we put that in a box and store it on the heap. Because we want it to be able to stick around for a while, even though it's high up and it's a bit slower to get to. So most things in Rust are stored on the stack unless you specify otherwise, which is why we had to put the fancy whiskey in a box in order to store it on the heap. So when we run this program, the good whiskey gets a spot on the heap at the far, far end of our available memory. And we put a pointer on the stack that points to that spot on the heap. Next on the stack, we put the cheap stuff. In this case, it is old granddad, which is a very terrible bourbon if you didn't know. The cheap stuff gets served up first because it's on top, and then we have the pointer to the fancy stuff, which the bartender has to go way, way, way up to the top of the heap to get, which she does. All that sea travel made me hungry, I think. Let's check out one of the local eateries. I've heard good things about this one. It's called Cafe Destruct. Oh, sir, I can't quite read this menu. I'm used to seeing things like this. There's a defined class, and the instance methods for that class are defined with a simple def, and they end with the word end. Instead, I see all these strange new things, like structs and impulse, and what's this all about, huh? Waiter! So I'm sorry, madam. I know this isn't something you're used to back in Rubyville, but we here in Rustlandia, we have no class. No class! I believe it. This is terrible. How are we going to get along without class? It's the one thing separating us from the animals. Don't worry. Don't worry at all. You can still get what you need. Here, here. Here's the chunky bacon struct. This is where we define all the attributes we expect out of it, like flavor, chunkiness, price, et cetera. So then I can just do something like this, and I'll be all set. No, no, my good lady. For that, you'll need to write an impulse. That's an implementation of chunky bacon. So if you want a new instance of chunky bacon, you'll have to write a new method yourself. It doesn't just happen automatically. Well then, very good. I'll have a salad. And now a word from our sponsors. Me? Yeah, you there. You want to try some rust? You mean the iron oxide produced as a result of a redox reaction of iron and oxygen in the presence of water or air moisture? What have you been reading, Wikipedia? No, not that rustful. Rustland, my friend. Oh yeah, that cool new systems programming language all the kids at school are talking about. The very same. Well, what about it? Do you like abstraction without overhead? Concurrency without data races? I think. What about memory safety without garbage collection? That sounds good. Love rust. Welcome to Mutability Lake. It's a lovely day, and so many of our distinguished towns people are out sailing their toy ships. Some are fancier than others. Some are mutable. Some aren't. This one here is a nice one. This one's not mutable. So we can't change anything about it, but I can pick it up and show it to you. Look how nice. But if we try to change anything about it, hey, you can't do that. Ah, the compiler is yelling at us. So we know we can't change this boat. It's immutable. Let's try another one. Let's look back what other ships are in the lake. Cool. This one's definitely mutable. It has a little flag that says mute. Let's just make a few changes before we return it. Let's add some wheels to this boat. Perfect. Compiler, what do you think? Matter compiler. You put wheels on a boat. It's not a boat anymore. It's a car. You said you would return a boat. You must return a boat, as is clearly illustrated here. The boat struct does not include anything about wheels. OK, OK. I'll take the wheels off. I thought it looked pretty cool, though. Let's look for another boat in the lake. Hey, that one looks pretty cool. You're like, oh, it doesn't belong to you. Oh, I'm sorry, compiler. Who owns this boat? I do. So sorry. Can I borrow it? I was hoping to play with it in my bathtub. Well, will you bring it back? Of course. Go right ahead. Don't forget this ampersand so everyone knows you're just borrowing it. And now a musical montage. Hey, thanks for returning my boat. Compiler, does everything look good to you? I'm not in a tugboat. That's not OK. But compiler, these boats are all vectors of strings. All I did was push a tugboat onto it. A tugboat is a string. The tugboat isn't yours, and neither is the boat. Yeah, that tugboat is mine. Well, what if I just, boom, punch the tugboat guy in the face and hit him with a remove? Looks like no one owns this tugboat now. You want a tugboat on your boat, sir? Sure. Let's do boat.push and pass in the tugboat. Now you have one. And now another word from our sponsors. Hey, kid. What? Did you get all that information about ownership and borrowing? A lot of the cool stuff I was telling you about before. You mean like when you were yelling, memory safe, David Algarg, I'm just calling a hand at me. Yes, you got it. I only know Ruby though, so these aren't really problems I've had to deal with. Well, let me tell you, if you were a C programmer, you'd be really excited. You bet it's OK. Can you just teach me something about rust so the kids at school will finally think I'm cool? Sure thing, kid. Let's try a less convoluted metaphor. Watch this. Hello again, travelers. Have you seen our esteemed library? It's pretty great. You can borrow just about anything as long as you return it. They even have this great big pile of books over there that don't belong to anyone. You can just take them if you want, and then they're yours. Every so often people will come by with donations of books they don't need anymore. It's great. If you want to borrow a book, you just need your ampersand. If you try to change a book while you're borrowing it, we'll yell at you and your code won't compile. However, if you see something you like in the free pile, you can just take it and do whatever you want with it. It's yours. You there in the back. You had a question? Yes, what about if the book is a mutable reference? Great question, friend. Well, you might very well be borrowing something that's mutable, like our collection of coloring books here. You can continue coloring in them while you have them, and you can return them altered. Only one person can have one out at a time though. We also have some exquisite corpse books that are pretty cool. Every time someone borrows one of these, they add a little bit of it themselves before bringing it back. I want to borrow the exquisite corpse book. Me too, I want to borrow it too. No, no more than one mutable reference at a time. You can have it now, but you have to wait until the first person is done before you can borrow it. Aw, man. No complaining. Do you want a data race? Do you? So you might have noticed how clean and beautiful Rustlandia is. And yet you might have also noticed there are no garbage cans anywhere. It's actually because of that system of borrowing and ownership that Rustlandia is able to do without garbage collection. It's a big part of what makes everything so fast and safe here. But isn't it annoying having the compiler yelling at you all the time? Hey now, don't judge the compiler. Look, you hurt his feelings. He's not such a bad guy. He's just making sure everything we do is good before we can run it. The compiler is our friend. He just wants the best for us. Sure, his advice might be a little hard to understand at times, but once you get to know him, he's really a good guy, I promise. And now, another word from our sponsors. Tonight on WRST, it's the true story of how one statically typed programming language risked it all to figure out how to handle it when things go wrong. Being and nothingness and error handling based on a true story. If everything goes right, the reactor will cool down and the city will be saved. But if something goes wrong, if this whole thing goes south, I guess I'll just do nothing. I mean, it seems like it's time to return an option, right? I mean, the compiler feels fine about it, right? Looking good. Meanwhile, across town, the grocery store doesn't have the mustard I like. Pay attention to me. Shut everything down. I need my Dijon. Compiler, you agree. Don't you, compiler? Looking good. Public service announcement. Just because the code compiles doesn't mean it's something you should do. Results, for when something could go terribly wrong and you need to throw an error. Option, for when it's okay to just do nothing. Live it, learn it, love it. Hey, welcome back. Just in time for the last boat back to Rubyville. I sincerely hope you enjoyed your stay and that you visit again soon. If you wanna stay a little longer, there are some very nice boxes at the heap. Otherwise, the boat is ready to board. On your way back, we do have some very nice reading material if you're interested in learning more about Rust. I strongly recommend starting with Rust by Example. This is an online book that will lead you by the hand, step by step, through many examples, explaining everything along the way. After that, you can look at the official Rust reference documentation, which is very helpful. If you'd like to try your hand at some Rust of your very own from scratch, there are many excellent exercises available at Exorcism. If you have questions, there's the Rust Reddit and the user forums, or you can chat on one of the many channels on IRC. In preparation for the original version of this talk at RustConf last year with some help from my boss, I've developed a playable text-based adventure game in both Ruby and Rust. This way, you can check out Ruby and Rust code that do similar things side by side. I've written a few very little ones over the years, usually when I'm trying to learn a new language or if I'm playing with a new idea. Some of you may never have played one, but it's basically a game where everything is text. In my case, the whole game is played in your terminal like it's the 80s. So the way it works is you get a prompt, usually a sentence or two followed by a question, like, you are in a dark forest. You see a light in the north. You have a map. What do you do? And then you type something like, look at map. Then the computer responds with something else. And you type something else. The computer responds to that, so on and so forth, until your character dies or the game is over. I think nowadays games like this are also called interactive fiction. Let's take a quick look at the actual game I wrote to give you a better idea of what I'm talking about. Let's see how this goes. Let me put this up quite a bit. What is your name? My name is Liz. What would you like to do? Look around. This room contains a rare and glorious unicorn. It's amazing. This room contains a jar of unicorn forts. Unicorn doctor is here too. What now? Talk. Hi, I'm a unicorn doctor. It's pretty cool. I have a vial of unicorn blood. Do you want it? What now? Let's see. Take a vial of unicorn blood. Because who doesn't want a vial of unicorn blood? Okay, I wrote it wrong. Take vial of unicorn blood. Maybe? Vial of unicorn blood has been added to your inventory and removed from the doctor's inventory. Okay, I want to use vial of unicorn blood. I want to know what this does. It's made me invincible. It's amazing. So great. Okay, I want to get out of here. So that's the game. But how did I actually build it? Before writing a single line of code, I had to think about the architecture of the game. There were a million different ways I could find a structure. In the end, I wanted something super simple. So I went with a really basic loop. It continues to ask what the player wants to do until a particular condition is met at which point the game ends. So in this example, which I stress is not real code, just an example of the structure I was using, we start by defining playing is true and while playing is true, the game asks, what do you want to do next? Then it parses whatever the subsequent user input is and it performs an action based on that input. Like if the user says move north, then the player's position has changed and maybe we output something like you have moved north. We don't exit the loop unless the user dies or the game ends at which point playing is redefined as false. So what does this look like in Ruby or Rust? In Ruby, there's a lot going on before we get to the play method, but that's where the loop is, so that's what I'm showing you. This is a method on the game class which is initialized with a player, a map, an array of rooms and with the value of playing as true. So as long as playing remains true, the game will keep asking what now. Then it'll parse whatever the user types and respond to that. So this example is ignoring a lot of other code I wrote to support this, so it wouldn't fit on the screen, much like the Ruby example, but for the sake of simplicity, here you can see we are creating a player, a map and a game, and you can see that while game.playing, game play, pretty close to what I illustrated earlier. What you can't see though is that unlike Ruby, I had to write my own new method because Rust doesn't automatically give you anything like Ruby's initialized and isn't object oriented by nature the way Ruby is. So there are no classes per se. Otherwise, it seems pretty similar to the Ruby version. It's just a little more code, which is fine. So what differences did I notice in writing the game? With Ruby, I felt like I could just write whatever I wanted, make something work quickly, and then reorganize the code as I went. It's really easy to have a flow like you're just writing your ideas in your journal and you're making things up as you go along, but the downside of this is that it's really easy to get caught up in that flow and forget to check things out as you go and forget to test, forget to run every single part of the program you just wrote, which I did many times. I periodically run the program and things would just break without adding a whole bunch of tests after the fact, which isn't great. I didn't have a lot of confidence that something wouldn't just unexpectedly fall apart at runtime, all because I got caught up right in the game and I forgot to check things out as I went along. Rust, on the other hand, is kind of the reverse experience. Since Rust needs to be compiled before you run it, the compiler literally won't let you run the program until you fix all the stuff it doesn't like. Not coincidentally, I have not run into any of these pesky random bugs in the Rust version of the game, probably because the compiler caught them before they would become a problem. This can be super frustrating, though, when you're first learning Rust because it can be so satisfying just to see something working and you could be working for hours and seeing errors like this over and over and it can easily become really disheartening if you're new to it. Yeah, it's just, yeah, Rust is good. This might seem like a weird simile. The best thing I can think of to compare Ruby and Rust in terms of my personal experience with the two is their two different parenting styles. This might seem like an odd comparison, but bear with me. Ruby is like the hippie parents who let their kids do whatever they want. They don't put a whole lot of restrictions on them because they're like, you'll figure it out, man, it's cool. You'll be okay in the end, I trust you. The downside, of course, is the kids will hit all these bumps on the road along the way because no one told them, like, you shouldn't go walk into traffic or whatever. Rust is like those parents who are constantly telling their kids what's best for them. They're a little bit strict. It's not that bad, but they're just always giving this unsolicited advice based on their own experience and maybe it turns out their advice was right, but it's definitely annoying to be hearing it all the time. And just like parents, you can't really say one way of doing things is better or worse than another, but they both have their pros and cons depending on what you're trying to do and how you prefer to work. I'm sure someone with more experience could give a more in-depth analysis, but this is my opinion based on my limited experience just writing a simple text game. So if you're thinking of learning Rust or Ruby, I'm sure you're all Ruby people anyway, or both, I say go for it. You can check out the game I built at github.com slash tilde IO slash learning dash rust. Both versions are playable and both have kind of filler stories in them. The Ruby versions filler game is a little more fun though, if you can only play one of them. Thank you for having me. I have been Liz. I'm on Twitter at underscore L Bailey. That's it, the end.