 Hello, ElixirConf. I'm very excited to be here. This is the first time that I get to talk to other Elixir users about Elixir. So, please, yeah, that's sort of basically switching my local loopy group. So, I'm thinking it's Ruby. Next thing you know, we're talking about Elixir. So, my name is Richard Bishop, and I'm going to talk a little bit about the first two steps. And this is really, it's going to be about my experience learning the language and really coming from an object-oriented background and learning the group. So, a little bit more about me. I'm a software developer and consultant. I set a lot of Ruby, a lot of JavaScript, a lot of things. I maintain a blog at www.scribbling.com and you can find me complaining on Twitter. So, I'm from Calgary, from Canada, and recently moved there from San Diego, so you probably wouldn't do crazy stuff. And Elixir isn't really the only thing I'm sipping. Two of my big copies. I'm really big in their coffee. This is my setup of how I make coffee. Very, very manual process. And I find coffee and software really similar. I'm not trying to keep it simple. And we end up very, very fast, right? So, this is just human age. This is what we do. I'm also a huge craft beer junkie. I track down beer from all over the world. I love beer. I'm like a serial killer for beer. I photograph it, categorize it, store it, and I drink it. So, that's that. So, let's sort of, before I get into it, why Elixir? Really, why any language? There's a lot of choices. So, there's closure, and go, and rest. There's a lot to choose from. So, the first reason really, and what Dave talked about a lot, is curiosity and learning new things, right? Dave told us we have to learn a new language every year, and we do everything that Dave tells us to do. So, things like that. We should be looking, right? Things are constantly changing. Think about when Rails was created, right? Our problem was all the boilerplate to get data out of the database and turn it into HTML. That's not really the case in. So, new solutions arise. New problems arise. And two, I think, is concurrency. Hardware is a lot different now than it was. And, you know, I've been fortunate, or unfortunate, to work on some pretty big-scale Rails applications where you kind of end up with really big Amazon EC2 builds. And that led me to get more curious about concurrency in Ruby, but we were a bit limited there, right? It wasn't really a big focus when designing the language. We just have, for the most part, operating system processes and threads, and maybe some kind of data to prevent limitations. So, that sort of led me under quest, and then eventually how I ended up discovering Erlang and Elixir in that virtual machine. And then along the way, I did write some node apps, and I found out that I'm not that good at being a scheduler, so if anybody here who's worked on an Erlang scheduler, that's up to you. So, the third reason would be maintainability. You can't write maintainable software. What good is it anyway, no matter how fast it is? And I think Elixir gives you a unique combination of those two things. So, the talk is the first few steps, and like I said, it's going to be about my experiences with my background learning Elixir. I've seen some other people, I've heard some other people say it had similar things, so maybe you can relate, or it's just another view to how I went about it. And then, at the end, I want to wrap it up with maybe a couple suggestions or things to think about to how we can be a more inviting language, right? There are 100 titles here today, someone said it has to be 301 or 501 next year, so let's see how maybe some things we can do a little bit better. So with that, let's get into the first step. So being, primarily, a Ruby developer, you see the syntax, right? As programmers we know syntax means nothing, but we can't help it, right? It's the first thing we do when we look at a new language, okay, it looks like this, it's kind of like this, or oh, there's no way I'm going to use this language because it doesn't, you know, not only do you see the stats there. So we know it means nothing, but we can't help ourselves. And when you start using a web server, this falls apart really quickly, right? Because immediately you're starting a functional programmer in the language. So functional programming, in my experience, has been really, really hard for our about-to-web server. I tried some of the other languages without much success. And we have a really embarrassing story about functional programming, and it's embarrassing because I thought I was doing it when I wasn't. So I was writing some JavaScript, right? And I was pairing with someone, and we were using this library called Underscore, and it touts itself as functional programming for JavaScript. But in reality, it's a library that polyfoils all the missing iterators into the browser. There's not really much functional about it other than iterators and such. So because I ended up using the merits of functional programming, right? There's a lot more to it than just iterated functions and broken closures and assigning or first-class functions, right? A lot of languages have those these days, and they're not functional languages. So you can say I was doing, oh, shithole programming, right? Another way to do it. So with that, you know, again, comparing my Victorian experience, you know, you spend a lot of time learning about patterns. Patterns, patterns, patterns. Pattern books and blog posts everywhere, right? That is the solution to all your own problems with patterns. And something that was refreshing is one night I was Googling and I typed functional programming patterns in it. And the very first result is, where are all the functional programming design patterns? And it made me realize, yes, I'm home. No more patterns. And so, you know, they might be out there, but I haven't really run into too many yet. So a lot of functional programming is just by itself in a whole lot. There's a few other things that kind of go with it. And pattern matching, right? Dave talked extensively about this. This is the best feature of the language. This is a requirement for me going forward. Any language I learn, I'm going to require pattern matching. So there's pattern matching for destructuring complex data. But I'm also going to focus on pattern matching and function heads, which to me is, I look at that as a form of low-level control for it, right? So, I'm going to show a little bit of the code and we're programmers. We can't enjoy something without condemning another. So I'm going to pick on imperative programming and object-oriented programming a little bit. So, has anybody here ever worked at a zoo or built a zoo app along the domain of animals before? Okay. Pretty good for you all then. So, we have a function. It looks like it could be any imperative language. It's called talk. But the main thing I want to highlight is this if-elsef. In a paragraph language, this might be the lowest form of flow control you have or a switch. So, we look at this animal. Check out its type. It's cow. We go new. We pay. We go point point. That's it. So, object-oriented programming comes along and languages usually have a polymorphism. So, we say, okay, you know, we can push that flow control a little bit lower, right? We make a cow, a pig class, a type. And then we use an animal presenter because everybody knows those are all the rage these days. And then we use that common interface that makes sound method as a way of controlling the flow or application. So, it's a little bit lower than it felt, but we've also introduced two new types. Whether, you know, that's a win for you. In this case, maybe not. In other cases, it might be. So, let's look at using pattern language. We have a mixer. We have a module called animal talker. And we have a talk function with two heads. And we're matching on a map on the type key, being cow, a pig. So, in terms of flow control, we've taken it out of the body of the function completely and we pushed it up into the head of the function. And I've found so far that this has helped me write so much more easily understood in maintainable code as I've been using the mixer. So, let's look at another little ingredient that really helps us come together even more. And that's recursion. So, a lot of people will tell you recursion is just for implementing loops. But that's sounding a bit short, right? It's also for job interviews in languages that you're just going to get system stackers. Right? I don't know why. So many Ruby interviews have been on asking me to do recursion. And yeah, I know you can turn on telecall optimization at compile time, but if you have to turn a feature on at compile time to language, no one's going to use it. So, the big thing with recursion is it changes how you codify the problems that you're solving. You get to focus on what you're actually trying to solve and you can push the outliers out using data matching. So, let's pick on imperative for anything so long. So this is, when I'm using an imperative layer, this is how I tend to see how I go through writing my code. You start with what we're trying to do and then we move to the outliers. In our coding style and imperative language, we add early returns or we might start off immediately branching to an if and else. Or, you know, after that I want to have some exception or more different returns. So, it really hurts us when we have to do all this because it ends up indent our code a lot. And a lot of us look at that shape that the indentation creates and say, oh, that's, you know, we're having it in our own direction. So, what you realize is your programs, you know, imperative languages, they kind of grow wider over time, right? All this branching. So, when you're able to use recursion and pattern matching, you're able to focus and flip things, right? You can immediately start focusing on the cell problem, right? If you're building a reducer, that's, you know, looking at the head and asking it's how long it's not. And then, when you want to actually handle the case, of when you reach an empty list, which can get ugly and imperative languages, you just pattern match the empty list and you stop bringing pattern into nil. So, when you code in this style, you notice that your programs tend to grow taller over time, rather than wider. And then another key ingredient here is immutable data structures. So, anytime you read advice from sort of the SAGE programs, they all say, what differentiates an average developer from a great developer? They always say data structures, knowing how to use them. And in object-oriented languages, I find we kind of, we don't really learn how to use data structures, we hide them, right? We do things like this, lots of classes like this in object-oriented code, we have some sort of array or hash, we tuck it away inside of a class, and then we implement tons of behavior around it. We're not really using data structures any better. And then one way of immutability is, in object-oriented languages, you're going to deal with a lot of state. It's like you're doing different things based on state. And I want to share this really great quote from Rich Hickey on state, from the Simple Made Easy Talk. If you haven't watched it before, I really recommend it. But this is the definition he gives. He says, state is a specific value for an identity at a point in time. And when I heard that, I kind of went back and listened to it a few more times. Something was jumping out of me, and I couldn't quite figure out what it was. And then it hit me. And anytime you're a programmer and you see this word, it should send chills at your spine. So, do you see it? Yeah. I'm talking about time, right? Whether it's time zones, or hours, minutes, and seconds, or testing time. It is absolutely pain to deal with. And that's really what state is, is you're coupling values with time. And that adds a lot of complexity, that's Rich Hickey says. So getting rid of that makes your programs a lot more reasonable. So let's recap that first step. So we came in thinking, okay, this is just Rudy on a real language machine. And that's not at all the case, because we have great support for functional programming, all the pattern matching, and recursion to really build understandable systems. So, let's get a step before I move on to the next step. Okay, so, second step. You say to yourself, okay, looks like coffee script for early. I've heard this said so many times. Who would hear? Absolutely. This is like the next progression. And that's something that looks short, or value really short, right? Because the only benefit of coffee script is that you don't have to write long script. From what I understand, there's people out there that like writing early. So, clearly, if that's all Lixar offered, there would be nobody that would switch from a language to a Lixar. So, let's take a look and see why. It's more than just that. The first thing is better tooling. Before I ended up with a Lixar, I had some quick stops at some other languages. And it's really hard to get started with those languages, because you're kind of learning how you need to set up a few other things, dependencies, or how you want to structure your projects. Or, if you're using dependencies, everybody's got a different project structure. So, Lixar has mixed. It's a fantastic tool for such a young language to already have. You can start a new project, a pretty same project structure. You have a test suite and it manages your dependencies. What more could you ask for when you're coming to a new language? It makes it so easy to focus on learning the actual language. And, of course, we have hacks. So, we already have a package manager for restricting programs and getting hands-on programs. The next thing you really notice is that Lixar takes documentation very, very seriously. If you're not writing documentation for your code, you don't know how to blame it yourself. The first time that I ran a doc test, I think I just about flew out of my seat. Like, how crazy is that? Oh, my God. An IAX session inside of a test that we can make sure it's still valid as we change our code. So, we're not mis-meaning people. One of the worst cases with documentation is when it just gets out of date. So, we have a quick way of going. And then we have different levels of documentation that gets rendered differently, right? We can document modules. We can document functions. Of course, we can document types as well. And then there's a lot of convenience for getting at the documentation. You can easily look at it in IAX. It's in the H2N. And then we have XDoc if you want a web-based version. So, there's really no reason to not be writing documentation or reading documentation. It's so simple and straightforward. There's tooling. But the language also offers a few other features. Metaprogramming, right? So, I have to admit when I first came to Alexa I wasn't excited about metaprogramming at all. I didn't touch it for the first few months because I still had a metaprogramming hangover from Ruby. So, but as you start to use it you realize it's a little bit different. Number one is that we've learned, right? We've got the macro matchup. You can use macro when you can use a function. So, we're more responsible with our use of macros. Another great benefit in Alexa is that macro expansion happens at compile time, not at runtime. So, you can easily more easily debug the reason about what's actually going on and just kind of running and seeing what happens. And another interesting thing is that Elixir itself is mostly implemented in macros. So, we have if here implemented and then we have the last implemented using if. So, that changes the language, right? In a lot of languages, there's a lot of keywords that are sacred. You can't touch those. You can't change those. In Elixir, you can if you want to. You can extend the language if you want. So, what's great about this is in Elixir you get to have one of the holy sacred things that people love, right? They really, really value what they call bottom-up program. You can have that in Elixir. You can build the language up toward your program. So, you do this with DSLs and macros and it's very intriguing. You'll see some of it out there already but maybe we'll start to see some more of it. So, let's recap that second step. So, we came in and we thought, it's because there are lines I would but we realized there's quite a bit more to it than that. We're getting actual language features. We have better tooling so you can get started and focus on the program, rather than application structure and getting test suites and things to run. And then, of course, we have a robust macro system for extending the language and building our programs differently. So, at this point, you're kind of coming around on the language a bit and you've done some punctual programming and maybe you've played with processes a little bit and that's when everything really kicks in with overdrive for you. So, you're really coming around, right? So, you might say to yourself, wow, actors are more object-oriented than objects, right? If you go off the old Dr. L. M. K. definition of, you know, he envisioned cells and communicating with message passing. All the object-oriented programs didn't really behave that way, but when you isolate your code and the processes, it's a bit more like that. So, but there's pretty bit of conceptual overhead coming to this type of model. And that's the actor model, right? It's really unfamiliar to if you haven't used Erlang or I don't really know what else it's really using. There's this implementation in other languages but it's not the same when you try to bolt on the actor model. They're cellulose where actors are backed by positive spreads so you can't really have millions of them. So, there's nothing quite like a virtual machine that's designed for actors. And I didn't really get out there until there's this really off-the-cuff video of Carl Hewitt and this Danish guy with a really great tie-eye t-shirt. It's Eric Mayer, of course, where they really explain, right? What is an actor? What can it do? What can it do in mailboxes? And you start to see how that relates to processes in Erlang, right? We have mailboxes. It's all done communicating using messages. So if you do concurrency in any other language, you'll spend a lot of your time messing with new text in this, right? Pushing something over here into a queue and popping it off over there. You don't have to worry about that in what makes it start at all, right? Erlang virtual machine takes care of that for you. The other thing with processes is this is where you finally can put some state into your programs. Whereas you didn't provide before. But it's isolated. It's not just going to change up underneath you. You have to tell actors the same messages. So when you start to play with processes you try to glue together all these wacky little abstractions for doing different things with them. Maybe only having a worker pool or something. And it's really that. It doesn't work how you think it is. Thankfully we have this, right? We like to hate it. It's also there for us, right? So OTP is why a lot of people come to Erlang when it's current. People come to Erlang. And OTP is using OTP a lot easier. There's a lot of boilerplate. It's a very high ceremony to use OTP. And then what is OTP even? I feel like on a weekly basis my definition of OTP is changing. One day I just think it's for servers and supervisors. And then, oh then you find out it's actually a package of tools, right? The Erlang interpreter, the compiler, a database and some other standard libraries. So it's confusing what it even sort of what it all is. But either way, you should be using it and learning more about it because it's going to help you a lot. Something you'll read about is people trying to implement their own version of the supervisor. But then, you don't realize all the stuff behind the scenes that OTP's doing put up, right? So we get a lot of Erlang behind the scenes, a lot of you. However, you might actually end up looking. That's fine. And messages. And then there's the whole other side of this too, more administrative for your programs, right? handling releases and hot code really. So these are the things that we like to brag about that we have for our programs. So to recap the third sip we kind of came in thinking coming around actors are more object-oriented than objects in all of language. But it changes the way you create your programs, right? You have to start thinking in supervision trees. That's really the recurring theme when you're learning like so, right? Everything is about thinking differently. And OTP is no different. But it adds a bit of clarity to your program because when things are running concurrently you can usually look at your module and sort of picture it as that particular process. So finally, your last sip is that it's a language in its own right, right? We can stop these silly parallels to other languages that we use because they just don't fully hold up. So to look at all four of them we can strike the first two out immediately. It's nothing like read. It offers way more than JavaScript or JavaScript does. And then we can start embracing the things that really make it unique and make it useful. But the one thing, though, to get to this point is it's a bit tricky because things are so conceptually different than we're used to, right? In other languages your programs are almost always split up like in a typical web application. Some things serving requests, some things doing background work. And they're probably in different processes and deployed differently. It's not like that. So I want to quickly load some ideas and talk about some things that I think we should consider to kind of make the language a little bit more entitled so we can get to three hundred and one people. The first thing is productivity that sort of you're stuck from first using a language to creating something that you find cool. Now there's, you can't get around having to learn functional programming that's just that's just part of the deal picking up a language like this. But there are some things that maybe we can do to help build things that make people feel good, right? For some reason whenever someone looks at a new language they like to be able to build web applications or just return a 200k string of a world. I don't know if actually I'm sure everybody here can close their eyes and picture the Node.js and go HTTP handler implementations, right? That is like it's just all around the internet, right? You could be laying on the beach and a jet will drive by with the implementation of an HTTP handler and go. That's just really how they get people to use the languages. People are excited to set up an HTTP handler. So maybe we should think of a way to make that easier for people to do. Or connect to a database very easily or, you know, fire off an HTTP request. And like I said there's overhead to getting into that. You have to understand a little bit about processes in the publishing program. But could we use maybe a little more as we like to say magic at first? Think about if you come here from Ruby and you don't understand a language everything feels magic. But you're still able to get stuff done. And then as time goes on you work with a language a bit more. You start to understand a language. Magic isn't around anymore, right? Because you understand what's actually going on now. The next thing is our elevators pitch. How many people rant and rave about Elixir like, oh, you know, what's Elixir like? And then all these words start fumbling out of your mouth. Fault tolerance, distributed concurrent, right? But what does that mean to someone who maybe doesn't even have those issues? Elixir is a pretty good language all on its own. It doesn't have to just be used for those types of programs. You don't want to pigeonhole ourselves. So let's look at Elixir's description. You can see that it's so Elixir is a functional meta-programming aware of language built on top of the early VN. It is a dynamic language that focuses on tooling, leverage, early capabilities to build concurrent, distributed, full-time applications with hot code upgrades. Wow. Whenever I go to look at a new language I'm more interested in why I should use it. And not so much as the what. Yeah, they're tools, but you have to figure out sort of why. And with a message like this we're kind of still sitting in our ivory burlang towers preaching about all these awesome things we have to solve your problems. Or maybe these aren't your problems. So let's contrast that with Ruby's description. See what I did there with the colors? Very programming language color theme. Talk. So Ruby, a dynamic open source programming language with a focus on simplicity and productivity. That's the why, right? If you're looking at that language you say, wow, simple and productive. I wonder how. Now you can check it out to find out how those things are true. So you're curious, we want to check the language out. So I'm a programmer. I'm not a marketer. But I'll take a stab at what I think why to be a better description for a mixer. Because if I'm going to criticize it I should at least offer up something. Otherwise it would just be a jerk. So this is what I'm thinking. A dynamic functional language designed for building scalable maintainable applications. That's the why. These are important things now. Scalability and maintainability is always. So if we pick someone's interest now what and a half, we can show an early virtual machine and lock free concurrency and hot code updates. So I really enjoy working with a mixer and lock. It's a joy of a program that you should use. I think it has a really bright future. Thank you. So your products they're not so much. So would you be in favor of expanding the docs language to support more annotations like Yard has as opposed to Ruby docs first freeform? Because if you're doing both spec and docs having to return to it that does the spec for you would be really nice and you would have to do spec at the same time. I guess in general would anyone think a more feature rich doc language in xdoc would be helpful? I really like Yard and Ruby because it looks to our doc. Because it makes it more standard and more parsable. But some people are like to me type annotations. I think right now it's pretty hard to pick on documentation on what's it. From what I found it's the easiest to use so far in comparing to other languages. I didn't use Yard a whole lot so of course that can't really compare those features. Thank you.