 other buildings. Hi. I'm Casey. This is Nathan. I was just told that he's earning to my burr, which sucks for you guys because I'll be doing most of the talking. So I brought up the idea on the mailing list of doing kind of a comparison of Ruby and Elixir. I'm going to make the assumption that we all love Ruby here. And I'm also going to make the assumption that none of us were born loving Ruby. So there's something about it, how do we leave either the productivity that it gave you or the community that drew you into Ruby as a language. And basically what I'm hoping to leave you with is an idea of where Elixir is in its growth as a language and whether or not it's something that you would also want to learn to love. Okay, so how many people have heard of Elixir? Yeah, that is a lot. So Elixir is a programming language that's roughly based on another programming language called Airlang. And the primary canonical complaint about Airlang as a language is that the syntax is ugly, not particularly in that camp, but whatever that's what most people think. So some people who have a better programming study than I have decided that they would make the syntax look very much like Ruby syntax. And they did and they call that Elixir. Oh by the way, so I'll be doing most of the talking. Nathan is mis-assertions that sideline like Shetter, I guess. Kind of. It's actually my excuse. So it will be pedantic about some technical things so that I don't have to be pedantic about 100 percent of this presentation. Right. Because, yeah, ideology in programming languages that never devolves into that. So Elixir, the syntax looks kind of similar to Ruby and I'm not sure you have a lot of code but enough that you'll kind of go, oh yeah, that looks like Ruby. But it compiles to bytecode for Airlang. So under the hood, it uses Airlang's VM, which is called the beam if I slip or call it the beam. I'll try to call it Airlang's VM. And the code actually runs on that. So I'll lay out a methodology for comparing the two programming languages. Then I'll focus on a couple of those methods and then kind of sum up with a conclusion about where Elixir is. Joey, I'm also going to make this difficult for you because I tend to pace. Okay. So some different ways we can compare languages. One is bias. I'll explain to you what my bias is so that you can take that into account when you're listening to what I say so that I'm pretty sure you can then subtract it and everything that I say is objectively true. So we can look at bias coming to programming languages. Technical virtue, some languages perform well and so on. Learning per, how long it takes to learn programming language. The community around it. The productivity that it gives you as a software engineer. How would we be more important for contractors than people who are FTEs? I'm going to let that one go. Okay. So when the areas that it's useful to use that programming language. These three are less important to me so I'll talk about quickly. My bias, our bias is coming from distributed systems that are highly available. So they always have to give a response and things that like lives depend on or server monitoring depends on stuff like that. Or fault tolerant systems. Systems that are large enough that you optimistically expect that stuff will break. So like if you're running a lot of servers, you know servers are going to go down and you need a system that can anticipate stuff's going to break and just work around it. So that's where we're coming from. I've been programming Ruby. I've got almost 10 years now and Erlang off and on for about three. Learning curve. The learning curve. Elixir as a language has a really small footprint. I didn't count but I think it's safe to say that the standard live is much smaller than Ruby's standard live. I think Ruby's is pretty small compared to other mature programming languages. And so the learning curve isn't for Elixir. It isn't hard. It's pretty low for programming language. Coming from somebody who came programming. And the community is really small because it's still a small programming language. It's still a very young programming language. So it was originally, the first release was about three and a half years ago, something like that. This past year they had the first Elixir comp in Austin. And it's still small. It's very, very pleasant to people in the community currently are very nice. There might be a z-shot in their hiding. But right now, sorry, that's just good. But it's right now it's a really fun community. So we'll just ignore those and focus on the other groups. The technical virtue of the language, the productivity, and the applicative domain. So the technical virtue. I'll talk a little bit about how Elixir works based on a compiling into airline. By comparison to conventions in Ruby Rails in particular that I hope are familiar. So this is heresy. But I'll say it. So modules in Elixir are roughly, you can at least think of them as being somewhat analogous to classes and processes in Elixir as being roughly analogous to objects. So I'm just going to pick on people whose names I can see. So Daniel. Daniel's a classy guy, so we'll assume he is the epitome of the Daniel class, right? So if we're making some sort of web application framework, we're going to say, give us a new instance of Daniel and whole process something and return some HTML, right? Easy enough. And Julio will say is a module in Elixir. Very similar thing. When we want to process some HTML in this app, we'll create an instantiation of Julio, we'll create a process of Julio, and he will compute some stuff and return HTML. Are instances of Julio called Daniel? No, no, no, sorry. Ruby Elixir. Bikeshed yet? Modules are only for code organization. So when you're using classes to namespace stuff, and then export that functionality to the outside world, that is the piece that is analogous between those two things. That was sufficiently pedantic. So so here's an interesting thing about, you know, the technical virtue of people say, oh, Elixir is great because Elang offers concurrency out of the box. And here's roughly how it does that. In the Ruby example, more or less, if requests are coming in for this web page, we say, okay, we'll take Daniel and make an instance of him, and you're now the Daniel object. And you do something, and then you return. And when you're done, then, sorry, you get destroyed. Now, next request comes in, and it's a really, it takes a lot of processing, but same thing, instance of Daniel Ben. So you handle, you have the luck, you're unlucky enough to handle this really long taking process. So it takes you a while, but finally you return it, and HTML comes back. And then we go back to a quick one and a quick one. Okay, it was kind of unfair to the subsequent instances of Daniel that a very long processing one happened before that, right? Ruby blocks, in most cases, it's blocking. So if you have a really long processing request for a single instance of a Rails app, it seems unfair to the request coming after it. Now, in Elixir, so if we take the Julio module and create a process from him, and that's a quick request. Okay, I'm not going to actually ask you to process this. So if some parameters come in, it's just to render some HTML and then return it, but there are more requests. So what happens is we can go ahead and spawn up many processes on that airline VM, and we can give her the first request, and we cannot wait for her to finish processing. We'll go ahead to the next one, and so on. And then we'll come back and we'll say, okay, you have one Mississippi. Do you finish processing requests? Yes. Okay, we're done. We return. You have one Mississippi. Do you finish returning the request? No, he's got the really long running one. Okay, back to the line. Go to the next one, and they both finish. And he just goes through the line more times. He goes to the end of the queue more times. So it's like a more fair way to divvy up the tasks. Now, all else being equal, we didn't actually parallelize the code, we just made it concurrent. So all else being equal over the course of an hour or so, the same amount of work got done. But because it was concurrent, the latency was a little bit more predictable. And from an end user experience, visiting web pages like this, most web users will feel like that's more fair. Did that make sense? So in this case, a process in the elixir and airline world is similar or an approximation of the actor model, which is a concurrency model that is some people probably know about. Celluloid is a Ruby framework that provides a similar type of thing. That part of it is more like an object in the way that the because there's a state that gets tracked around and you can call send messages to it and will do things to, excuse me, to mutate that internal state. But as it's laid out here, it's not exactly a one to one. This is a gross misrepresentation. But it's great as a learning aid. Perfect. So yeah, I mean, so it's more or less the rub of a concurrency story that you can make for why elixir has good technical merit. Another one I want to touch on is security. And this is what security looks like an elixir. There is no. So this is hard to explain to people. So I'm not talking about authentication in the application. I'm talking at the programming language level. So airline was developed for phone networks where they didn't want to send people out to the poll to fix things. They wanted to be able to log on locally and just send code down to the poll and have everyone there or send code down to the poll and have it send code down to the next station and have it run. So what you end up with is if you can connect through an airline shell to any airline process, you can run any command that has airlines permissions on that machine or shut the program down or do any other sort of malicious thing you would want to do. I don't assume anyone here would want to do malicious things. So it's the only way that I've seen to practically secure an airline application is to just put it behind a very strong firewall. So security is kind of not in or it's a different beast to consider. Yes. Question is, does it automatically open up network ports? Sort of. It's always listening on certain ports for other airline virtual machines to connect to it, which is a plus when you want to run a distributed system and you just start airline up on all of these machines and then have one go reach out and they all can just start chatting to each other. So you have to firewall those if those are open to that side world to your house. And another one is logging. This is not in electric favor. This is I just grabbed this off of Stack Overflow a couple hours ago. This is some error message from an airline program. I have no idea what it says. And I would argue that nobody else does either. Yeah, remember these, these are painful. So elixir does not give out error messages in elixir. It gives out stack traces from airline. And they are really curiously difficult to understand. So logging, understanding stack traces and logging is really difficult. Trust me, you do not know what this does. No, it sends in malformed JSON to the React MapReduce. Nope. Yeah, it does. It's a web machine. What was malformed? The there was undefined function that they checked. Oh, fun. You would see that on this page. This goes on for a long time. Yeah, so error messages, that's, yeah, doesn't it's not, it's not great in elixir. So just a hop over to an example. I'm going to pick on Chris McCord a little bit. So I let him know though. So I think that makes it okay. So he put this blog post out. Okay, so he put up a blog post where he says elixir versus Ruby showdown Phoenix versus Rails. So Phoenix is a content management, NBC style framework that you wrote in elixir. And he says, isn't this apples to oranges? No. Well, I'm going to argue that it is. But let's look at some code. So at top is some Phoenix code, or elixir code. And here's some the quote one Rails code. So you can kind of look at it and go, I can make out vaguely what that means. And if I had to change a route from a get to a put, I can figure that out. It's very, very similar. So there's the routing controllers, again, same situation we're looking at, you know, oh, this is the elixir code. And this is the Ruby code. It looks very similar. And it might even be exactly the same number of lines views. This is the elixir template, which looks very similar to your V. So if you use Rails, the learning curve to using Phoenix is not going to be huge. And here are the results. So he ran load testing. And Rails had about 1000 requests per second, and Phoenix had about 12,000 per second. So it's roughly 10 times faster, or was on his local not a great way to test it. He also tested it on Heroku, and it was about eight times faster. So I think this is entirely an apples to oranges, and a misleading comparison for a couple reasons. One elixir gets compiled to bytecode. I don't think it eight to 10 times performance increase is actually very impressive for going from a scripted to a compiled language. That seems a little weak to me. Two, he didn't test the full or m stack. He didn't go through active record. He didn't hit a database. So I don't think that's really representative of a content management system application. Another point, Rails done well, scales horizontally. If your Rails app is stateless, then you just bring up more stateless machines to handle more requests. And properly written, your application from an architectural point of view should be bottlenecking at the state layer. So I, you know, so I have a hard time seeing Phoenix's place because the Rails ecosystem already exists. And you're trading in all of those libraries that Rails offers for a small performance increase. To me, that equation is never going to work out. And find the way easier, the more interesting portion of that comparison? Not really. Well, I already explained that. So because Ruby blocks, the latency is going to be a little bit higher. So technical virtue, that's kind of my really light touch over the technical virtue of Blitz Resolane. So productivity, Erlang has this thing called OTP, you know, open telecom platform, there at that. And which I am going to make another heinous analogy to active stuff. But for a reason, with productivity in mind, so OTP is a set of behaviors that you can invoke, that you can mix in into your modules, that handles a lot of functionality for you, so that you don't have to rewrite, so that's better tested, very similar to what the active frameworks do in Rails. So I'll give you a quick example. So here's an active record thing, right? You inherit from active record, and then you automatically get has many and all the other basic conventions for SQL and validates name. Okay, so if you use Rails, this is very familiar. And if you use Rails, you know what has many does, you know that it's there, and you don't have to write joins based on the underlying data structure, right? So it saves you a lot of work. OTP does something similar, except that the OTP behaviors are much different than the active model behaviors. So here is a supervisor behavior from OTP, where you say, this this module, this bit of code is going to have a supervisor, Nathan will be our supervisor. And we're going to have these processes running, answering web requests or whatever they're doing, or fighting to the death, or not fighting to the death, no, not doing that, making web pages. So we just define in his net, okay, he's, he's got a children array, and the children array has some workers, and they're different modules, and they have different names. And then we call supervise these children with this strategy. And a strategy tells the system tells OTP that if one of those children's die, if something happens, they get malformed JSON and they just stop working, then he as the supervisor will automatically be notified. And because it's a one for one strategy will automatically restart that child. So there are patterns like that, which are incredibly useful if you have to do stuff like that. Here are the five basic ones, a server. So you know, there's a server and a client. One that handles events, a finance state machine, the supervisor, and an application, which is a way to package things together so that these components interrupt pretty well. So similar to the active paradigm in that these conventions handle a lot of work for you. So that's a big plus for productivity. And applicative domain. When Ruby when Rails came out, and when Rails really took off, there were thousands of content management MVC frameworks, we'll even say a couple, you know, couple popular ones in Java, just too many of them in PHP. And Ruby wasn't particularly popular. So why did Rails win? Have any theories? I actually like to hear a quick theory if anybody has some. I'm the only person who's thought about this. We'll leave that as a hypothesis. So, okay, so I spent a lot of time thinking about this. And so my conclusion, for whatever that's worth. Yeah? I think it's sort of like WordPress was like too much on the CMS. It made truing decisions. But Rails made just enough decisions that like, get to the point where you're like, okay, so this is just a decision. I don't agree with the change that picks up. But it was enough along the way, but not too far to be a pool of CMS. Okay, so the porridge was just right. It was like enough over not too much. Okay, right layer of abstraction, right layer of abstraction for the problems that we deal with as developers. Sure, that's plausible. I would say one of the reasons that it certainly gained a lot of attention is because there was a 15 minute demo. So DHH, nice guy, posted on a Riley blog somewhere this 15 minute demo to get Rails out of running. And most of the rest of us who are custom rolling our own NBC frameworks and PHP, we couldn't write a new application in 15 minutes. But there you had a full crud cycle on a resource running against the database, you know, in local host on your web browser in 15 minutes. That seemed like an order of magnitude at least faster than how long it took to build applications previously. Another reason is the conventions. For me, one of the reasons conventions are so important is because most of my time programming is spent sitting back in my chair thinking of variable names. And when you have conventions, you don't have to think of as many variable names. Right? What's the key for this table? Oh, somebody already thought of that for me. It's ID done. Conventions also let you carry information from one project to the next. So ID, that's a good variable. So I can I could, you know, any any conventional Rails application, I could start working on it today and be productive and well, maybe tomorrow and be productive in it that day. Because I know where all the files are, I know how it's going to use active model. So that information carries over from project to project. That's really powerful. And I will say this in quotes, quote me on this, Rails want despite poor performance, a poor deployment story and poor paradigms. So I feel like we've all kind of just swallowed poor performance like, okay, performance is always going to stop. Who cares, it's fun language, or perfectly reasonable or the deployment story. The horror stories from earlier on, in Rails history, I won't even go back that far. But getting the right libraries bundled together in the proper word has been a problem for most of the history of Rails in terms of deployment. It's a lot better now than it's ever been. And poor paradigms, and I'll give you just one example of a poor paradigm in rail. Does anyone know how to pronounce that? It's never. Thank you. Thank you. It's a terrible acronym. This is the index show new edit create update delete. Yeah, this is a fault methods for a controller. That's terrible. So Sinatra gets this right. There's no reason to have that layer of abstraction in it. It could simply just be get put post, then you know what it's doing, you know, when why it's doing this paradigm is just weird, completely arbitrary. And so there's a couple other things like that, that are unfavorable. So the convenience of having an application of the less than running in less than 15 minutes and the conventions that go with it and it being, you know, just the right temperature for porridge made rails really successful. Does elixir Phoenix have that? Well, it's borrowing the conventions. So it can kind of support that. But, you know, it's much younger. So it doesn't have the other libraries that's for those conventions. And it is certainly not in order of magnitude faster to build an application in Phoenix than in rails. So I'm having a hard time seeing what I could really mean to put a strike. But it is a good project. Chris would say that the appeal to for Phoenix isn't the content management system part. It's something called channels, which is like a way to do soft real time for chat type applications. I'm not convinced that that's production right. But so applicative domain, I don't think this is it for for elixir. applicative domain for elixir are these types of things basically anything that airline is good at network applications, chat applications, if that's still a thing, I didn't think it was. But what's that made? Yeah, Snapchat recently. Oh, God. Yeah. Snapchat just raised Internet of things stuff. That seems like a certainly call our systems where you expect things to break expect to go down. So in those types of applications, elixirs are a really good choice. Does anybody here write applications in these things? I'll even remove chat just these three network applications, internet things call our systems. Okay, cool. So the six of us could get I will talk to other people that don't do those things. You don't have to. So yeah, so that was the methodology. And that's an overview of the technical productivity and the application for for elixir. I think it's biggest challenge is one, it doesn't have killer application. You can't look at the elixir community and the way you could at Ruby 10 years ago and say rails, that's the killer app for Ruby, totally was the killer app. Elixir doesn't have that. And it doesn't have a corporate sponsor. It doesn't have anybody yet, as far as I know, who is making a non trivial production bet on the elixir ecosystem, where, you know, money is on the line. Who knows, maybe our sponsor will be back. So follow up information. Chris McCourt's presentation on Phoenix is online, you can Google and find it online on Casey, he's Nathan. And I would just want to close with a poll. If there was an elixir class at airline factory down in San Francisco in March, it's about $2,000 a person refundable by your employer. For three days of training and two days of the conference, would anybody here be interested in going to that? Is it in Portland? Consider relocating to Portland. If it was relocated to Portland. All right. Okay, same six people. So much to learn. Yeah. All right. Thank you.