 I'm Ruth Ann. I'm a junior dev at Spreedley, and I'm going to tell you all about my experience moving to Elixirville. When I decided a number of years ago that it was time I should learn to program, lots of people told me not to worry too super much about what I started with because you know you learn something and then you're just going to have to learn something else in a minute. So I just picked up whatever class I was taking or the tutorial I was working through or the job I was doing required, which was Racket and then Ruby and then JavaScript, Python, Java, SQL, Rails, Ember, Pyramid, Jekyll, Flask, Node, and each time it was a little bit like moving to a new city. The first time you're out on your own, you squint at a map, you read the docs, you spend a lot of time figuring out where you can live that you'll be able to walk from your new apartment to the grocery store. And eventually you find the coffee shop that is your coffee shop. You learn how to write a case statement. You figure out how the public transit works and then it's time to move again. And you move again and again and again and maybe you reminisce about your old favorite bar or variable assignment by value instead of by reference, Python. You know that the town you're going to will have coffee shops so you don't stress too much about finding them before you move there. You settle in, you get on with what you need to do in your life. But as I moved from one language to the next, a funny thing started to happen which was that the town kind of all started to look the same. The maps weren't really telling me things I could actually use. Everything in whatever tutorial or blog post I was reading would be really obvious and then all of a sudden everything would be really opaque and then I would quit the tutorial and go look for a real problem to solve. And by the time I was headed to Elixirville, this was particularly bad. There is some chance my manager is out there somewhere so I'm not going to tell you just how bad it was. But it was a pretty disorganized trip and in case you too would rather just look up the nearest coffee shop when you want a coffee and in case you too should decide one day for whatever reason to visit Elixirville, I'm going to tell you a little bit about a couple of things, a couple of customs if you will, that sort of confused me at first and what I've learned about them. Number one, pipes. So I took a look at our code base. There was a whole bunch of this stuff on the left. It was like what is actually going like okay the passenger is doing something. So what a pipe does is let you pass an expression as the first parameter to a function. So this saves us at a minimum a bunch of repetition and at best a lot of cognitive load. So the functions that I sort of like mocked up here aren't exactly isomorphic but they do kind of the same thing. I tried to make the second one over there at least like a little bit idiomatic and ruby so I wasn't like torturing the example too much. But the result of this is that helper functions get conceptualized a little bit differently. Thinking of Elixir in terms of a spoken language kind of feels like swapping from sentences start with a verb and then you have to wade through everything else in the sentence to figure out who we're actually talking about to sentences start with a subject. But if you're used to waiting then there's a part of your brain that goes, what's going on here? Am I being tricked? Not being tricked. That's actually what's happening. Second thing, pattern matching. So you remember how I mentioned that there's like this point where all the tutorials become super opaque and I threw my hands in the air. For me that was pattern matching. It's like we have the same function defined four times. Why? How can you even do that? The confusing part about this is there's this whole thing in Elixir about how the equal sign doesn't do assignment exactly and I sort of went this is all very strange and I don't know why anyone would want this. Where this really shines is in function definitions. At some point you were probably told one or more arbitrary acceptable lines for a function and then you had to write a conditional that had more than two clauses and that was the end of that. But pattern matching breaks that up a lot as you can see. So here we have some common behaviors for espresso drinks. We have some common behaviors for non-expressor drinks. We have suitable incredulity when you don't actually want to coffee. And we have this final clause that will sort of catch everyone who actually needs to go around the corner to the bar. Finally, probably the most cultural of all of these mixed format will find what code you wrote that isn't appropriately formatted. You can set your formatting on a per project basis. So that offers some granularity for local preferences and it's great. No one likes to be culturally insensitive, especially not an accident. Now when I was writing this I thought there was a way to have mixed format like actually show you what you had done wrong. I can't actually figure out how to do that anymore. But if you like me always forget to check your formatting until after you've committed, then you can just go see what's different in a mentor commit. So those are some things that I got to learn on my way to Elixirville. I am super glad to have all of you here in my physical hometown of Durham. And I love to talk about what I learned in Elixir. I love to talk about Durham. You need any recommendations or thoughts or notice that I wrote something completely incorrect. Please come find me later. Thanks.