 Hello, ElixirConf. Very excited to be here. This is the first time that I get to talk to other Elixir users about Elixir. You can see I've just been sort of basically switching my local Ruby group. So I'm thinking it's Ruby, and next thing I want to talk about Elixir. So my name is Richard Bishop, and I'm talking to one of the first two SIPs. And this is really just going to be about my experience learning the language and really coming from an audit-oriented background in my Ruby group. So a little bit more about me. I'm a software developer, an consultant. I sell a lot of Ruby, a lot of JavaScript, web things. I maintain a blog at www.siprity.com, and you can find me complaining on Twitter. So I'm from Calgary, coming here to Canada. And I recently moved there from San Diego, so you probably wouldn't do crazy stuff. And Elixir isn't really the only thing I'm sitting. Two of my big copies are 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 to start off trying to keep it simple. And we have very, very good cups, right? So this is just human nature, this is what we do. And I'm also a huge craft beer junkie. They track down beer from all over the world. I love beer. I'm like a serial killer of beer. I've got you photographic, 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 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 told us to do. So things to have. But we shouldn't be looking, right? Things are constantly changing. Think about when Rails was created, right? Our problem was all the boiler way to get data out of the database and turn it into HTML. That's not really the case in here. So new solutions arise, new problems arise. And two, I think, is concurrency. Hardware's a lot different now than it was. And 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 you're a bit limited there, right? It wasn't really a big focus when designing the language. Just have, for the most part, operating system processes, threads, and maybe some annotated event limitations. So that sort of led me on a 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 note apps. And I found out that I'm not that good at being a scheduler. So if anybody here who's worked on the 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 two steps. And like I said, it's gonna be about my experiences with my background learning Elixir. I've seen some other people or 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 got it. And then at the end, I wanna wrap it up with maybe a couple suggestions or things to think about to how we can be a more inviting language, right? It's a hundred 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 that, let's get into the first step. So being, I remember the Ruby developer, you see the syntax, right? As far as 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, no, I don't wanna do CSS stuff. So we know it means nothing, but we can't help ourselves. And when you start using a wixar, this falls apart really quickly, right? Because immediately, you're starting a functional programming in the language. So functional programming, in my experience, has been really, really hard for our about to a wixar. I tried some of the other languages without much success. And they 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 helps itself as functional programming for JavaScript. But in reality, it's a library that polyhills 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? Don't they really matter? So with that, you know, again, comparing to my Victorian experience, you know, you spend a lot of time learning about patterns. Patterns, patterns, patterns. Pattern books, I've bought those everywhere, right? That is the solution to all your own problems with patterns. And some of that was refreshing as one night I was Googling and I typed functional programming patterns in, and the very first result is where are all the functional programming design patterns? And maybe realize, yes, I'm home, no more patterns. And so, you know, they might be out there, but I haven't learned them to 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 action, right? Dave talked extensively about this. This is the best feature of the language. This is a requirement for me to go in for any new language everywhere. I'm going to require pattern matching. So there's pattern matching for destructuring complex data. And then, 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 flow, right? So I'm gonna show a little bit of the code and we're programmers, we can't enjoy something without condemning another. So I'm gonna pick on, I'm gonna pick on pattern programming and object-oriented programming a little bit. So, has anybody here ever worked at a Zoom, or built a Zoom app, a model, domain of animals before? Okay, pretty good for you all then. So, we have a function, it looks like you couldn't eat any of character language. It's called Taw, but the main thing I wanna highlight is this bit, Elsa, right? In the character 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 blue, a, we go point point, right? That's it. So, objects-oriented programming goes along and languages usually have a polymorphism. So we say, okay, 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 range these days. And then, we use that common interface that makes sound method as a way of controlling the flow of our application. So, it's a little bit lower than it felt, but we've also introduced tuning types. But, 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 matching with an elixir. We have a module called animal talker, and we have a talk function with two heads. And we're matching them on the map, on the type, gaming, 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 and maintainable code as I've been using elixir. 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 leaves, but that's sounding a bit short, right? That's also for job interviews. In my language, it's that you're just going to get system stackers, right? I don't know why, so many movie interviews have been asked 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 it from compile time to language, no one's going to use it. So, the big thing with recursion is it changes how you codify the problem that you're solving. You get to focus on what you're actually trying to solve, and you can push the outliers out using pattern matching. So, let's pick on imperative programming so long. So, this is, when I'm using an imperative language, this is how I tend to see how I go through writing my code. You start with what we're trying to do, then we move to the outliers. And that really dominates our coding style and imperative language, right? We have early returns, or we might start off immediately branching to an if and else. Or, you know, after that, we want to have some exception or more different returns. So, it really hurts us when we have to do all this because it depends on the indent or code a lot. And we'll always look at that shape that the indentation creates and say, oh, that's, you know, we're having 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 sub-problem, right? If you're building a reducer, that's, you know, looking at the head and passing the tail along, it's not. And then, when you want to actually handle the case of when you reach an empty list, which you can get ugly and imperative languages, you just pattern matching empty lists and you stop, you can pattern them to null. 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, 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. It's a high level, right? We do things like this. Lots of classes like this in like object-oriented code, right? 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, there's, in object-oriented languages, you're gonna deal with a lot of state. And 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 a simple Made Easy talk. It's a great 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, 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 and minutes and seconds or testing time. It is absolutely going to deal with it. And that's really what state is, is you're coupling values with time. And that adds a lot of complexity, as 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, now this is just really on the real language machine. And that's not at all the case because we create support for functional programming on pattern matching. And the courage is to really build understandable systems. So, let's get a sip before I move on to the next sip. So, second sip. He says, okay, looks like coffee's good for early. I've heard this said so many times. So, who would hear? Yeah, this is like the next progression. And that's selling Elixir's short for 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, right? So, clearly, if that's all Elixir offered, there wouldn't be nobody that would switch from early to Elixir. So, let's take a look and see why it's more than just that. The first thing is better to learn. Before I ended up with Elixir, I had some quick stops at some other languages. And it's really hard to get started with those languages because along with learning the language, 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, Elixir has a mix. It's a fantastic tool for such a young language to already have. You can start a new project and produce the same project structure. You have a test suite already up and running. It manages your dependencies. What more can you ask for when you're coming to a new language? 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 Elixir takes documentation very, very seriously. If you're not writing documentation for your code, you have no one to blame but yourself. The first time that I ran a doc test, I think I just about flew out of my seat. I think, like, how crazy is that? Oh, my God, an IAX session inside our test that we can make sure it's still valid as we change our code. So, we're not misleading people. One of the worst cases with documentation is when it just gets out of date, right? So, we have a quick way of knowing that. And then we have different levels of documentation in our code that gets rid of it 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 out 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. So, that's it for tooling. But the language also offers a few other features. Meta-program, right? So, I have to admit when I first came to Elixir, I wasn't excited about Meta-program at all. I didn't touch it for the first few months because I still had a Meta-program 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? Got the macro macho. Never use a macro when you can use a function. So, we're more responsible with our use of macros. Another great benefit in Elixir is that macro extension 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 it 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, it's great about this is, in Elixir, you get to have one of the holy sacred things that whispers love, right? They really, really value what they call bottom-up program, and you can have that in Elixir. You can build language up toward your program. So, we do this with DSL, macros, and it's very intriguing. There's, 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, we bought, okay, it's just coffee script, it's as early as I would, but we realized there's quite a bit more to it than that. Right, we're getting actual language features. We have better tooling, so you can get started and focus on your 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, building our programs differently. So, at this point, you're kind of coming around on a language a bit, and done some functional programming, and maybe you can play with processes a little bit. And that's when everything really kicks in, with overdrive for you. So, you're really coming around, right? You might say to yourself, wow, actors are more object-oriented than objects, right? If you go off the old Dr. Allen King definition, he envisioned cells, communicating, message passing, sort of realized all the object-oriented programs didn't really behave that way. But, when you isolate your code into processes, it's a bit more like that. So, but there's quite a bit of conceptual overhead coming to this type of model, and that's the actor model, right? It's really unfamiliar to you if you haven't used Erlang or I don't really know what they're also really using it. There's implementations in other languages, but it's not the same when you try to bolt on the actor model. They're cellular and Ruby, 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 it 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-dye t-shirt. It's Eric Meyer, of course, where they really explain, right? What is an actor? What can it do? What can it do in L-boxes? And you start to see how that relates to processes in Erlang, right? You have L-boxes, it's all done, communicating, using messages. So, if you do concurrency in any other language, you'll spend a lot of your time messaging, we're messing with new text in this, Vox, right? Pushing something over here into a cube and popping it off over there. You don't have to worry about that in a lister 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 do it before, but it's isolated. It's not just going to change up underneath you. You have to tell actors to do things by sending messages. But when you start to play with processes, you try to glue together all these wacky little abstractions for doing different things with them. Maybe like having a worker pool or something. And it's really bad. 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 the language currently, we come to Erlang. And OTP is using OTP a lot easier. There's a lot of other way to do it. It's very high ceremony to use OTP. And then when it's 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, compiler, a database, and then 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 read about is people trying to implement their own version of the supervisor. So then, you don't realize all the stuff behind the scenes that OTP is doing, point out, right? So we get a lot of error handling behind the scenes, lobbying, however you might actually end up looking, it's fine, and messages. And then there's the whole other side of things too, more administrative for your programs, right? Handling leases can 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, you kind of come in thinking, okay, coming around, actors are more object-oriented than objects in the law 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 the language, right? If they said things differently, everything is about thinking differently. You know, OTP is no different. But it adds a bit of clarity to your color, 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 really hold up. So to look at all four of them, we can strike the first two half immediately. It's nothing like reading. It offers way more than JavaScript and 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? And in other languages, your programs are almost always split up like in a typical web application. Something's serving requests, something's doing background work. And they're probably in different processes and they're probably deployed differently. But 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 or so we can get to 301 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 adding your own functional program. 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 and a string of a world. I don't know, actually I'm sure everybody here can close their eyes and picture the Node.js and go HTTP handler implementations, right? That is like the, 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, right? 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 fire off HTTP requests. And like I said, there's overhead to getting to that. You have to understand a little bit about processes and functional 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, when you first started without language, everything kills magic, right? But you're still able to get stopped on. And then as time goes on, you work with a language a bit more. You start to understand the 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? And then someone comes up to you and asks you, oh, you know, what's Elixir like? And then all these words just 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, right? Elixir's 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 metaprogramming aware of language built on top of the early VM. It is a dynamic language that focuses on tooling to leverage learnings and abilities to develop the current, distributed, all-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. You have the tools, but you have to figure out sort of why. And for the message like this, we're kind of still sitting in our, I agree, burling towers, preaching about all these awesome things we have to solve your problems. Or maybe these aren't any problems. So let's contrast that with Ruby's description. See what I did there with colors. Very programming language colors being pop. So, 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, what, why, wow, simple and productive, wonder how. Now you can check it out to find out how those things are true. So you were curious, you wanna check the language out. So, I'm a programmer, I'm not a marketer, but I'll take a stab at what I think might be a better description for a mixer. Because if I'm gonna criticize it, I should at least offer up something as long as it 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, now we can show them what and a half, right? Now we can show them the early virtual machine and lock free concurrency and hot code upgrades. So, I've really enjoyed working with a mixer a lot, right? And it's a joy of a programming language to use. So, I think it has a really bright future. Thank you. So, your ProDocs, they're not so much. So, would you be in favor of expanding the docs language to support more annotations like Yartags as opposed to RubyDocs or Screform? Because if you're doing both spec and docs, having to return that, 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 Yart and Ruby as opposed to RDoc because it makes it more standard and more parsable. But some people are like too many type annotations. I think right now, it's pretty hard to pick on documentation and what to do. From what I've found, it's the easiest to use so far in comparing to other languages. But it uses Yart a whole lot, so of course that can't really compare those features.