The Changelog: Software Development, Open Source - Elixir and Phoenix (Interview)

Episode Date: March 20, 2015

Chris McCord joined the show to take us on a deep dive into the Phoenix web framework and Elixir. We covered the similarities between Ruby and Erlang, getting started with Elixir, and deploying Phoenix. He also shared his plans for the 1.0 release and the future of Phoenix.

Welcome back everyone, this is the Change Log and I'm your host Adam Stachowiak, this is episode 147 and today Jared and I are talking to Chris McCord, talking about Elixir on top of Erlang, Phoenix the web framework, definitely got me and Jared thinking about concurrency and Elixir for an upcoming project. Phoenix sounds really cool and I love this conversation with Chris. We've got some awesome sponsors, CodeShip, TopTile, and Postico.

We'll tell you about TopTile and Postico later in the show, but our friends at CodeShip have this awesome new feature that'll help you deploy to production so much faster than you're doing right now. It's called Parallel CI and if you want to run faster tests and have your builds built and in production quicker you've got to run your tests in parallel with Parallel CI you can now split your test commands into 10 test pipelines or up to 10 test pipelines this lets

you run your tests much faster than before and drastically reduce the time it takes for you to push your code to production and get your builds run. They integrate with GitHub and Bitbucket. You can deploy to cloud services like Roku, AWS, and many more. And you can get started today by trying out their free plan, which includes 100 builds a month and five private projects. Or you can use our offer code, TheChangeLolPodcast. Again, that offer code is the change law podcast and with that code you'll get 20 off any plan you choose with code ship three months head to codeship.com slash the change law to get started and now on to the show

all right everybody we're back we got ch got Chris McCord on the call today. We're talking about some cool stuff today. Elixir, the language, Phoenix, the framework. Chris, welcome to the show. How's it going? And we also got Jared Santola on the line. Jared, how are you today, man? Doing better, better than I was yesterday.

Yeah, yesterday was a bad day. That was a bad day. Bad day. Did you sleep a lot of time? I was trying to sleep, mostly tossing and turning, you know. But all good today. Feeling better. Did Slack keep you up?

Hinging and whatnot? Everything was keeping me up. It was a bad day. So, Chris, you hail from Dayton, Ohio, right? That's right. Not Phoenix, Arizona. No, not yet. We established in the pre-show

that Chris would be slightly cooler, or at least I did, if he were from Phoenix, Arizona, because of Phoenix, the framework. It just would make sense. Or maybe he had named the framework Dayton Framework. See?

Come on, Chris. The logo wouldn't have been nearly as cool, though so i don't know i mean you got some you got the date what the daytona 500 up there right no that's that's that's wrong state is that a different state that's uh florida so that's right florida florida what's in date well you know isn't there something racing there no we we like where were the wright brothers were from so we were first in flight, except they built it here, but they flew it in North Carolina.

So both states claim that we're both first in flight. So that's probably our only claim to fame. Gotcha. Well, you got some other claims to fame here. So let's dig deep here. So for those who do not know who you are, how do you introduce yourself to an audience like we got today? I created the Phoenix framework.

It's an Elixir web framework. And I also just recently authored a metaprogramming Elixir for PragProg. And during the day, I build web applications at LittleLions. LittleLions. I like that. You got a little shout out to in that uh in your talk recently it was an elixir con yep yeah um was there people in the crowd that knew who little lines was i think we got yeah we had like that one little whoop

small following i don't know i don't know who that was but yeah someone did so yes jared's singing in the chat room behind the scenes daytona 500 classic yeah that's that's just i i confuse it all the time with dayton and i'm sorry it's classic we get that a lot we get that a lot yeah you google date and you get daytona 500 every time every time all right well chris we've been excited to get you on the show. We've had multiple requests to have shows on Elixir, a show on Phoenix. We have to thank a few of our listeners. Alexander Quine was the one who originally said, hey, let's talk about Elixir on the show. And then following up to that was Sebastian Siduro.

Sorry, Sebastian, if I butchered that name. Siduro, who said, yes yes let's talk about Elixir and specifically let's get Chris on the show to talk about Phoenix so thanks to those guys for requesting this and we're happy to have you here to talk about where did they request that at? they requested that on our ping repo

which is github.com slash the changelog slash ping and I think they reached out to me someone reached out to me on IRC, Elixirling, and then opened that issue and made it happen. Nice, love that man. There's Elixir advocates out there apparently. And little lines too.

Yep. Yeah, so Elixir is an interesting young language, seems to be growing quite the following. And seems like it's got your, it's caught your fancy. And so why don't you just start off, we'll talk about Elixir, and then we'll get into Phoenix later. But I'd like to hear about Elixir from your perspective, Chris, as one who is now developing lots of stuff in the language. Sure. So yeah, so you mentioned Elixir is a young language, and that's true. But we are at a 1.0 stable release. We've been there since July last year. And kind of the cool thing about Elixir is it's built on top of the Erlang virtual machine.

So we are a very young language, but we're using Erlang to kind of bootstrap the language itself. So we didn't have to kind of reinvent the wheel for a lot of the underpinnings. And that let Elixir kind of get out of the gates quickly. And then we also have, you know, 20 plus years of innovation and libraries under the hood that we can take advantage of today. So for those that don't know, Elixir compiles down to Erlang bytecode. And it runs on the Erlang virtual machine. And Erlang was kind of an obscure language, at least for me, a few years ago. I had heard of it, but I wasn't really aware of it, never heard about it in college.

Erlang kind of had this nugget of innovation for the last 25 years, is what I tell people. They basically run half the world's telecommunication systems. And so it's been operating at high scale and high reliability for decades. And only now, recently, people are starting to take notice of our, most of our modern languages aren't really great at concurrency. And now they're kind of finding out that Erlang solved these problems 20 years ago. So it's pretty cool that, you know, you might say that other modern languages like Go kind of, you know, tackle concurrency, but Erlang from the very beginning had three core values, which I think most, not any language that I'm aware of targets. It was a language that needed

to be highly concurrent, highly distributed, because they wanted to run it on multiple telecom switches in the 80s, and then highly fault tolerant because you wanted these things to stay online forever. And they kind of built the language around those needs and developed kind of the standard library around these specific problems. And those specific problems actually map perfectly onto kind of the multi-core age that we have today. So Elixir builds on top of that Erlang innovation, adding some modern features that you would expect with a language like metaprogramming was big for me. It adds polymorphism through protocols. So it borrows some ideas from Clojure and some other places to really give you this modern language with all this great innovation for the last couple decades. So had you previously tried Erlang directly, or did you come through it from

the Elixir side? So I went straight to Elixir, but so what got me into it initially is I've been doing Ruby development professionally for the last six years or so, and I wanted to do WebSockets in my Rails app. I was building some kind of real-time features into my Rails app. I was building some kind of real-time features into my Rails app. I built this gem called Sync that let you build, let you do like real-time Rails partials. And it worked well, but I had to jump through kind of all these hoops to push out real-time events. I couldn't do it in my Rails app itself. I had to kind of offload it to an event machine thread, or I had to offload

it to like a separate Faye server. And it was like all this messiness and I got into it and it wasn't going to scale, scale well at all. And so then I started looking at like, you know, what are some other people doing? What languages are they using? And that's when I looked at Erlang. And I think that was when, that was when WhatsApp was not yet sold for $20 billion. But at the time there was an article I read a couple years ago, two or three years ago, that was about, they were using Erlang and they were getting a million concurrent connections per server. And that kind of blew my mind because I was looking at getting maybe, you know, 100 connections on my Rails app. So that kind of spiked my interest into Erlang. And then I remembered Elixir that I had just kind of come across. So I kind of checked Elixir out and then that kind of got the ball rolling on everything.

So you came at it from the Ruby perspective, which seems like it's fitting because Elixir also has a kind of a Ruby pedigree. Is that right? Yeah. So we'll see, we see a lot of people coming over from Ruby. I think, you know, a large part of that is Jose Valim, the creator of Elixir, was a Rails core team member. And he's written probably, if you're doing Rails development, you use half of the gems he's ever created. So I think his proximity to the Ruby community has brought a lot of people over. And then also, yeah, at a glance, the syntax does look familiar. I would say that that's kind of like a veneer because once you get into it, the semantics are very different. But at least at a glance, you're like, hey, this looks kind of similar. So it's kind of like a double whammy for Ruby to kind of jump in.

Awesome. So tell us a little bit more about the language itself. So it builds on top of Erlang. It has some metaprogramming. Is it a functional language? Is it an object-oriented language? Give us some of the aspects sure yeah so it's a it's a functional language and it's immutable and it interrupts it has full interoperability with erlang so you can call erlang from elixir and you can call elixir from erlang so any off-the-shelf erlang library you can just drop in and it just works and that's what kind of let us as a community move forward and get a release out soon because we didn't have to kind of, you know,

ream it the wheel for everything. But it adds, it solves some pain points that people have had with Erlang. One is, at least for me, some people really dislike metaprogramming, but for me coming from like a Ruby background, I love metaprogramming. It kind of lets me distill my domain problems and write beautiful code. So it adds metaprogramming,

which is kind of a big feature for me. And then it adds, like I said, polymorphism. It borrowed the idea from Clojure, where you can get polymorphism, but without object orientation. So you can go to functional programming, you don't have to throw away all these ideas of polymorphism, which are good, and you can kind of get that in a functional paradigm. So for me, that's been really nice. And then it has really great, like, just simple things that you expect in a modern language,

like really great Unicode string handling, which has been historically problematic in Erlang. And it really focuses on great experiences, like developer experience. So it has a build tool that it ships with a project generator. So you can just say mix new, give it a project name and it will generate, you know, idiomatic project structure for you. It ships with a test unit framework, I can just say mix test to run my tests. And then it also comes with a package manager. And kind of all these things were missing or not missing. They were not shipping with the base Erlang installation and it kind of

Erlang didn't focus on getting up and running quickly because historically they've been solving, I'd say like grittier problems. So it came in and I think solved some, some filled in some big gaps. And I think, you know, Jose said it best that when he first looked into Erlang, he loved everything he saw, but he hated the things that he didn't see. And that's what kind of Elixir came about, is filling in those gaps and still building off all the things that he loved. That's interesting. I have a little bit of a history with Erlang,

like a few days, like a weekend with Erlang, where I thought, oh, I'm going to kind of bend my mind a little bit of a history with Erlang, like a few days, like a weekend with Erlang, where I thought, oh, I'm going to kind of bend my mind a little bit. And the syntax itself was, for me, difficult to stretch my mind around. Started to get to it by the end of the weekend, but didn't have a real use case for it back then, so it didn't stick. What's the syntax of Elixir? I know it's kind of difficult to describe code in words, but if you had to compare it to a language or to a few languages, what would you say that it feels like writing? Well, so I would say the syntax is beautiful,

and it definitely feels like Ruby to some degree, but it has even more of a natural syntax than Ruby. And it has some neat, it stole, we stole the idea of the pipeline operator. If you're familiar, Clojure has like threading macros and F sharp has the pipe operator. So when you write Elixir, you structure your code, I'd say very differently than other functional program languages that I've seen. Just by virtue of having the pipeline operator allows you to kind of flatten out a list of nested function calls so it pipes the argument the result of one operation into the first argument of another function so instead of like kind of trying to read your code backwards in a bunch

of parentheses it kind of flattens that out and just compiles down to the same nested function call um so it kind of it made when i first it, it made me feel like when I was writing Ruby, it feels very natural and it's really pleasant to write, but even more, which is surprising for me to say. So it gives you things like pattern matching, which anytime I go back to my Ruby code, I lack these features and it makes me kind of sad. So it's like the first time I had language envy coming from a Ruby mindset of a Ruby mindset of, you know, code should be beautiful. It should be a pleasant, you know, experience to write. Can you explain pattern matching a little bit?

Yeah, so explain pattern matching in words. So I can write multiple functions with the same name and I can give the value of an argument. And that function will only be invoked if that pattern matches. So if I wrote like a countdown function, I can pattern match, I could recursively call countdown and pattern match on zero and that would be like the case

where I'm done counting down and then I could just pattern match on a variable like number and then recurse on countdown minus one, if that makes any sense. That's a very simple example, but the virtual machine lets you kind of destructure any data structure. So I can say if I have a list, I want to – I could pattern match out the first three elements of that list and then get the head of – or get the tail of the list,

like all the remaining elements, and I could have those all in separate variables. So it lets you kind of destructure things really naturally. So does the arguments to the method or to the function, they become part of the method signature? Yes, exactly. So you'd have multiple ones with the same name, and as long as the arguments vary, they would call different methods. Yeah, exactly.

Is that fair to say? Yep. Okay. And that's how you'll see. Interesting. You'll see that's kind of like idiomatic code. So Elixir has like standard branch, like if statements unless, or if expressions unless expressions, but you use them a lot less often because you have pattern matching.

That's kind of one of the staples of functional programming, correct? You're going to find that in Enclosure. You're going to find that in,closure, you're going to find that in LISPs, right? Yeah, I think you'll find that in most functional areas. And to me, it's huge. Once you experience it, it makes

writing any code without it, for me, kind of a painful process. Yeah, it seems like it helped melt away conditionals that would otherwise be checking these things and then branching, depending on the arguments, you could just melt those away with different methods. Yep, so you'll use if occasionally, but if I'm using if a couple times in a function, I start sweating a little bit,

thinking something here is not quite right. Interesting. So you're building a web framework. Elixir comes from a Rails core team member. Is Elixir built for the web or is it more of a general purpose programming language? It's built, I would say it wasn't, I mean, Jose comes from a web background, but the neat thing about Erlang is

you can target kind of like the embedded space or the web. So it's kind of, I would say, a general purpose in that you can go both high level and low level with it. Because Erlang comes from running on telecom switches. So people are using it in the embedded space pretty successfully today. But then it's also great for higher level building, any kind of thing that you would run, you would consider a server. So kind of web applications come into that naturally. You look at like WhatsApp, they're running their entire operation on it.

I think they were, I mentioned a million connections per server, but now I heard they're up to 2 million connections per server. And I think they hit 3 million during a spike once. And they're running 400 plus million users all on Erlang. And that, you know, that's...

Yeah, they had something like 30 engineers too. Yes, exactly. So ridiculously small amount of engineers for how many users they were supporting. 400 million users and 30 engineers to kind of prove how robust Erlang is and Elixir builds on top of that. So the standard library kind of gives you these tried and true mechanisms for building out distributed fault tolerant applications and things tend to just work. Cool. So I saw your video on ElixirConf, which we'll link up to in the show notes.

And one thing you said is that you'd love if all of your consulting work, not just your personal projects, but all your consulting projects, hopefully, eventually, at some point, will be written in Elixir. If you had to describe it in one phrase, what is it about Elixir that has you so excited? You've got to distill it down. What would you say? Two phrases.

So one, it lets me – I can write highly performant code without sacrificing productivity, and I can be highly productive without sacrificing performance. And it's kind of a play on words, but it's kind of the holy grail. Like I come from writing a lot of Rails applications where I'm sacrificing that concurrency and that performance, but the productivity and the feeling of building these things is so great. Elixir gives me both of those, performance and productivity. Any drawbacks or things you've run into that have been not so great? So because Elixir is so young, you're definitely going to have access to a lot less off-the-shelf libraries. So you can't just do gem install, devise, and have user authentication yet. So I'd say that lack of off-the-shelf packages and also the learning curve is pretty steep

compared to if you're coming from any kind of object-oriented background and you want to get into Ruby or get into Python, it's pretty straightforward because, you know, an object's an object. But coming into functional programming, at least for me, Elixir was my first functional language. The learning curve initially, I call it like the frustration gap where you're like, you feel dumb, you're not getting anything done, something that looks like it should be simple, you can't figure out.

It takes a little bit to get past that for things to actually click in your mind, thinking about programming differently. Awesome. Well, we're going to take a break now to hear a word from a show sponsor, but we'll be right back. And when we come back, we'll talk about Phoenix, the web framework. Top Tile is the best place to work as a freelance software developer. If you're freelancing right now as a software developer and you're looking for a way to work with top clients on projects that are interesting, challenging, and using the technologies you want to use, TopTile might just be the place for you. Working as a freelance software developer with TopTile means that your days of searching for long-term, high-quality work and getting paid what you're worth will be over. Let's face it, you're an awesome developer, and you deserve to be compensated like Juan. Joining TopTal means you'll have the opportunity to travel the world as an elite engineer. On top of that, TopTal can help provide the software, hardware, and support you need to work effectively no matter where you are in the world. Head to toptal.com slash developers. That's T-O-P-T-A-L.com slash developers

to learn more and tell them the change law sent you. All right, we are back with Chris McCord. Chris, you fell in love with Elixir. You've been doing a lot of Rails. You decided there needs to be a Rails for Elixir? Is that kind of the thought process there? Yes and no. So I would say we definitely borrow some ideas from Rails,

but we're not trying to recreate Rails in Elixir. But I will say we are trying to borrow a lot of the spirits of Rails. What Rails showed is if you have a community to get together around common conventions, you can build great tooling. So I would caution to say that we aren't building Rails for Elixir, but in some ways we are. We want to build a full-featured framework

that the community can get together and build great tooling around. So if I come into your Phoenix project, I can kind of know where things are, how to name them. So to that degree, we are kind of replicating that similar experience. It's not unique. We've heard this before, though. I mean, when we had Taylor Outwell on recently talking about Laravel, that was the case there, too, where you sort of go to the camp you like to hang out best at, and you create the rails of that world, more or less. I mean, right?

So DHH was just on the show a couple of shows back, and a lot of people love that show. And we're hearing, I think you hear it repetitively, in a good way, though. It's a good testament back to a lot of the things he helped instill into GoodWeb frameworks. Oh, definitely. I still do Rails every other day, and I love it. So I think, you know, Rails got a ton right. And, you know, so we borrow, if you look at our router, we borrow some ideas there. So if someone doing Rails comes in and looks at Phoenix without having any Elixir experience, they'll kind of be like, hey, if they squint a little bit, that looks pretty similar.

The DNA of Rails comes out. Yeah, but we aren't just trying to go feature for feature saying, okay, like, you know, we need feature X. Right, gotcha. Kind of like those movies that aren't, they're not like a retelling of a of a non-fiction they're like based on a true story you know those where you know like this is not actually a true story it's just based on a true story it's kind of like you know you want inspired by yeah and you want to you want to think differently and we've definitely borrowed some ideas um from other areas too so we're not just looking at rails we're looking looking at like, you know, Socket.io was a big inspiration for our real-time layer. And I think the problem that people coming

into Elixir initially from any other language will say, okay, well, we don't have a device for Phoenix yet, let's make device. So instead of, which is the wrong way to think about it. If you need user authentication, then you should start thinking about how do I solve user authentication, you know, in a functional mindset. So I think that's why I just want to caution that we're not just trying to say, okay, how do we clone Rails in Phoenix? No, it's like how do we think about the spirit of Rails and how do we apply that and some of the good stuff that we can bring over to what works best in Elixir and what we need to fulfill our needs? Yeah, I mean, you've got to play to the strengths of your language and your environment. Where are you drawing those different ideas from, if not directly from Rails,

from other experiences, from other projects in the Elixir ecosystem, from elsewhere? Yeah, so I mentioned, so the big thing for me when I started getting into, looking into this was doing real-time events from my Rails app. So when I saw elixir and right up on erling you know i immediately realized that this would be perfect for solving the real-time nature that i wanted with my application so socket io i had a little bit of like node experience played with socket io a little bit and socket io is awesome because it just lets you gives you a browser client and the Node server side, you can just push and receive events.

And it's super simple. So I kind of drew on that API a little bit in that experience to say, I want real-time events from my browser to my Phoenix app to be as trivial as building a REST backend. If you're building a REST backend in whatever framework you're using, you can just snap your fingers and you know instantly how you would build that. So that's kind of the big push on our real-time layer was looking at Socket.io and then we kind of extended that a little bit to kind of namespace events. But I'd say that's been a big inspiration for us.

So WebSocket support came in early and is production ready or what's the status of your, of your WebSocket support? Yeah. So WebSocket support is production ready. And since then, since ElixirConf we've added, it falls back to long polling. So it's going to work in, I think IE8 plus now, falls back to long polling transparently and you can just drop it in Phoenix JS and it just works. Awesome. Have you had success with people out there in the community trying it?

Have you built any of your own projects with it? Yeah, so we're using it in one of our own projects, which unfortunately I can't share publicly, but people are using it kind of all over the place. Someone recently built like a right around Christmas time, you could play jingle bells remotely with like a party of people. So kind of like, you know, you could coordinate, they did this like timing algorithm. So you could ring your bell and play like, you know, the jingle bells chime,

you know, across iPhone to iPhone, just using Phoenix Channels. So I think gaming could be a big area. Like someone, I haven't seen this come to fruition, but someone was looking into using Phoenix Channels over to like an Unreal Engine. So like a native desktop app, but, you know, pushing out the real-time events back and forth. So kind of outside of the HTML server web space, I think Phoenix could have a happy home there too. Yeah, I even saw that you have some iOS support going on. Want to talk about that? Sure. Yeah. So I think, you know, as I mentioned at LuxorConf, Phoenix is great at building just what you would think of as HTML web applications and APIs, but I kind of wanted to go

beyond that because the web is kind of transitioning, changing a little bit. You know, I don't think browsers are going anywhere, and I'm a web developer, but I think we have all these native apps, native clients, internet of thing movement coming on, and we need a framework to be able to connect all these devices and push out events and talk to them. So I think Phoenix is well positioned for that. And I kind of, for version 1.0, we have an iOS client that is, I think it works on, it's a Swift client. So it's not going to work on any of your Objective-C libraries, but someone has put together an Objective-C library. And we're going to ship with an Android client as well for 1.0. So you should be able to write mobile applications that are native

and have them talking to the same back end that your web application is talking to from the browser. That's pretty nice. We're hearing lots more about the Internet of Things. I mean, I think that's, we heard that, Jared, with some things we haven't released yet with Beyond the Code. When we talked about what in software inspires and excites people was a lot of the things that ties into like devices um things like the watch for example or other things that are inside your home i'm a little bit wishy-washy on the internet

of things myself it seems like it's very nebulous and kind of i don't know i don't think aspirational is the right word but pie in the sky but there had like the real world of, I don't know, I don't think aspirational is the right word, but pie in the sky, but they're like the real world applications of it. Don't seem like they're actually all that useful. Like, you know, your toaster can tell you when your toast is done. It's like, yeah, but I can, I can look at my toast and see that it's burnt. Right. Um, or your toaster, your toaster can list itself on eBay. Did you see that? There was someone made one where if you didn't use it in X amount of days, it would automatically eBay itself. Oh, man.

So it could be sold to someone that would use it. That's hilarious. Yeah, I mean, most of our applications are just kind of like – I somewhat agree with you. Yeah, they're very kind of silly kind of novelties right now. I'm sure just because it's very fringe and just upcoming and very much a buzzword but um no doubt we'll need software to drive those you know those interactions um whether

or not they're valuable or not we're gonna have to find out find out i guess well for you chris though what when you say internet of things as as in regards to phoenix and elixir what are you thinking of so for me i so i think i i kind of agree that, you know, Internet of Things is just a it's a hype right now that we haven't really seen great applications of it. But I think even even in the mobile space, if we just talk smartphones, you know, that is we already have the Internet of Things in my mind. Everyone's walking around permanently connected to the Internet with a square in their hand. So I think from that perspective, coming from, again, I'm not trying to pick on Rails, but coming from a Rails background, I just don't see it in that mindset of being able to have all these connected devices. I can't do that in Ruby just based on the concurrency model, at least not super well. So for me, just from like the mobile landscape, I want to

have a framework that I can maintain a persistent connection to my devices and push out real-time updates. Like someone recently wrote an app that they use Phoenix Channels to track shipments for a new startup. So they have a web browser. It's an Ember app, and it's listing where the drivers are at all times. So it's a native application pushing out updates over Phoenix channels and shows you in real time on a map in the browser where your drivers are. So things like that, I think, is what I'm talking about with Internet of Things. But I think the toaster and stuff, I think maybe in four or five years, we'll see useful applications.

I think a good application of what you're talking about, just with the device connectedness is, is the meerkat app, which kind of has blown up in the last couple of weeks, which is a Twitter base. It's an IO, it's an iPhone app. You guys probably have seen it posted to Twitter where you can immediately

start streaming live. Just post a tweet out to Twitter. I think it's like a single click to start streaming video from your phone. And anybody from their phones can just click and they're now streaming your video live to their phones. Very simply. And this is the kind of thing that just wasn't even possible a couple years ago, right? I mean, now we have the pervasiveness of LTE. We all have the devices. We have the software. There has to be infrastructure behind that, right right you get the

bandwidth costs which is what i think about is like man how long can these guys just burn money before they probably open twitter buys them or something but how long can they just burn money on bandwidth you know before they start making some money of their own but then also like there's servers back there driving these things and the ability that all of a sudden have thousands of streaming video connections seems like Erlang and the OTP stuff that it does is kind of well suited for those kinds of large communities. What do you think about that? Exactly. I was going to say I went to Erlang Factory last last year i think that's the first time i talked about phoenix publicly and uh one of the whatsapp engineers was there and they

were he was talking about that where they um turned on the feature for sharing image and video and they weren't sure how it was going to scale because he was talking about you can't really you can't really load test these things you can't't fake it, yeah. Yeah, if you have 400 million users, you can't say, okay, let's see how this is going to work, throw some servers behind it. You can't really load test it. So they had to do a live, and it just worked. And they were able to turn on the,

and that was kind of sharing video and images. So I think very similar to what you were just talking about. Awesome. So the channel support is really unique, I think, and interesting. What else does Phoenix bring to the table as far as a framework goes? Do you consider it a full stack framework? Yes. Yeah. So the goal is, I think, you know, it's not a micro framework. I hate that word. I think, you know, if you want to be a library, libraries are fine. Some people like building their applications out from small composable pieces. But I think

in practice, at least building a lot of Rails applications and inheriting a lot of Rails applications, I think having a set of conventions and a set of full features and obvious ways to do things is great for a community. So yeah, it's definitely the, it's a batteries included framework. Give us some of those batteries. What you got in there? Cool. So we have a similar to, I mentioned our router is somewhat similar to rails. So you can have this DSL for routing requests into your controllers.

And we have a, our view layer is kind of neat because you can render, we kind of separated the idea of views and templates. So views are more your presentation layer and views render templates. And a special thing, at least about what we do, is we precompile all the templates into the view module. So at runtime, you're just calling a function

and it's returning you, it's basically doing string concatenation. Whereas, you know, other frameworks can't really precompile these things, so they have to read from disk and cache it and go through all this work. But since we have metaprogramming in Elixir, all that content in your template files is just pre-compiled and baked directly in as a function call. Is that how all the metaprogramming works in Elixir? It's all at compile time? Yeah, all at compile time. So we can do a bunch of work at compile time and at

runtime. It's super fast. You don't have to worry about caching these things. You're not doing any disk reads because it's all just in memory. But it's just as robust and powerful as what you would think of in a scripted language that's not being compiled. So people are seeing microsecond response times rendering templates in Phoenix,

which is kind of cool. What else you got? You got, so routing is, I'm sure there's, it seems like you have MVC, but you also have what you call a view layer and a template layer. Can you talk about that? Yeah, views are basically like a presenter,

the presenter pattern, if you're coming from an object-oriented mindset, but we push it further too. So if I'm in a controller, I can say, you know, render my show template. And you can explicitly specify the content type or we'll use the content type from the accept headers. So if it was an HTML request, it's going to render the HTML template. But we also are promoting the mindset of your view should render everything. So if you want to render JSON, if you're just building like a JSON API, your view is just a module that's going to construct that JSON for

the caller. So we kind of, I think I at least haven't seen that in other areas where we're kind of pushing things out of the controller and keeping your controllers really clean and making the view present whatever was requested. And then obviously on on top of that our channel layer is probably the biggest i'd say innovation and what draws people in and that's what you can do you can push out real-time pub sub events to the browser today and hopefully you know ios and Android coming soon. Cool, so that view layer, I mean, it's kind of like a presenter or a decorator layer, but it can itself just serialize JSON,

so you wouldn't even have to have templates at all. Is that what you're saying? Yeah, exactly, exactly. But you would still be rendering a view. You wouldn't be constructing the JSON as a map in the controller. What if you do want to have just straight up HTML templates with generated server-side markup?

Is that all good too? Yeah, you would just create a HTML.ex template and say render index.html and it would pre-compile that and render it. So it would be just the same. And that, I assume, has your typical helper methods or whatever they're called in Elixir. Are they called functions?

Is everything a function? Yeah, everything's a function. Helpers is an accurate way to describe it, too. So your views can define all the helper methods for its templates, whether that's going to be your HTML template or just JSON directly in the module body. Awesome. So as far as full stack goes, is there anything missing at this point?

So we're pretty close to 1.0, although I say that and I don't want to give any hard dates, but I'd say what's missing for sure... Yeah, I saw in your video that you said by the end of the year you'd be at 1.0, but that was last year. I didn't say which year. He's pulling a pearl on us here. He's pulling a software developer on us. Yeah, I pushed it back to – I've said quarter one this year, but we're coming up on that. But no, really, I think we're actually quite close now.

What is missing is like internationalization. We used to have, we tore it out because we're working on something better. So we might release 1.0 without internationalization, and then release like a 1.1 with it. So that's been taken out now. And I think for now, we're just trying to settle on our channel API and make sure our, you know, the current APIs that we have are good, because we don't want to lose, we can't release one own immediately break things. But the core features there, you know, are baked in. So we have routers, controllers views, we even have, we refer to them as endpoints. So we're not like a monolith like Rails. So you can kind of bring in Phoenix into an existing OTP app, or you can run multiple Phoenix endpoints

within an app. And everything kind of just works along the lines of you can have as many of these things running as you want. And then along with that, what we've recently done is, you know, we've had channels for a long time, but we recently supported different PubSub adapters. So the channels operate on top of a PubSub layer. And the problem that we used to have is if you weren't running Elixir nodes clustered together, like on Heroku, dynos can't talk to each other. You couldn't really make use of channels over dynos that weren't clustered. So we recently added a Redis adapter, and anyone can implement their own PubSub adapter now where we kind of use a PubSub adapter to broker the events. So now on Heroku, cross your dynos, it's just going to work.

Or if you're running Elixir distributively, it's just going to fall back to the standard library. So that was a big feature for us recently. One term I think we've glazed over a little bit is OTP. Could you unpack that for the audience? Sure, yeah. And when I first saw this too, I was thinking like, what the heck is that? So OTP stands for Open Telecom Platform, which doesn't really tell you anything about what it is.

So it started off, this is historically Erlang was built for telecommunication systems. That's where the OpenTelecom platform comes from. But really, the best way to describe it is it's Erlang's standard library for building concurrent distributed fault-tolerant applications. And that's what Elixir ships with as well. So anything you're doing as far as holding state or we build applications, we call them in like supervision trees. So you have supervisors that are going to supervise different parts of your application. So if something crashes or something goes wrong,

it's going to automatically be restarted by its supervisor. And that will kind of travel up the chain and all the way up to your application supervisor. And so if everything crashes, the whole world's on fire, it will keep trying to restart in the entire, you know, different chains of the application uh so that's what otp is and um you're going to use it um everywhere use it everywhere what what is it actually what's the benefit yeah so uh lixures concurrency models we call them uh our unit of concurrency is a process it's not an operating system process

it's like a really lightweight thread and you can run like a million of them on like your like on my MacBook, I can spin up a million processes. So what OTP is, it's just it built out a set of conventions for managing state in an application and responding to failure. And those are processes, and we call them gen servers. If we want to hold state in a process, we have to basically recurse on a process with its state over and over since we're in a mutable language. So it's basically just a set of conventions that kind of naturally came about when Erlang was solving these problems,

and they codified it into OTP. So actually, the best way I've heard it described is it's the rails of concurrency. Nice. And that's pretty accurate. All right, let's take a break real quick and hear from a sponsor when we come back. We'll talk about deploying Phoenix to production. So we'll come back in just a second. I could not be more excited about this sponsor, Postico.

Postico is a Postgres client for OS X developed by a single independent developer named Jacob Egger. Jacob has open source chops as well. You may know him as the maintainer of Postgres.app, and he even used to work on SQL Pro back in the day. SQL Pro is a MySQL client for OS X that has a special place in my heart. It is a great client with a capital G, but unfortunately it only supports MySQL. I'm a Postgres convert, and I've long been clamoring for a high-quality Postgres GUI for OS X. Postico aims to be just that. It has all the features you come to expect from an SQL client and more, but you know what? If something that you want is missing, you can contact Jacob. I can tell you from personal experience, he takes feedback

and is very responsive, which is important to me when I'm investing in software. But the best part about Postico is that it is native to Yosemite and it is designed well. It fits right into the operating system. Copy and paste just works. Undo just works. Keyword shortcuts, you bet. With Postico, gone are the days of using SQL GUIs that stick out like a sore thumb. There's a free trial, which has no time limit.

So check it out, Postico. The best way is to Google that word. That's P-O-S-T-I-C-O. You'll find it at the very first hit. That's the simplest way to get where you need to go. Check out Postico. I love it, and I think you will too. Thanks to Jacob for supporting us, and let's get back to the show.

All right, so we're back. Chris, let's talk about deploying. I think that's one of the things that tends to hold people up. Getting into production is one of the things. So what kind of environment do you have to deploy a Phoenix Framework app to? So it's actually funny because it's easier for me to deploy my Phoenix apps these days to Heroku than to deploy my Rails apps. And I don't know why.

Like I did some benchmarking recently and it took me like two hours to get this Rails app started up, even though I do Rails full time. But Elixir is actually pretty easy to deploy if we're not talking some of the more advanced features. It's pretty easy to build on any kind of Unix, Linux box. We ship with, usually a lot of people, if you're deploying it yourself, you'll run it behind like an Nginx proxy,

but it will happily serve directly over port 80 if you wanted to you know live on the dangerous side yeah but it's not it's not too hard to stand up um elixir i usually i tend to build from source and have any problems um erlang is available um for pretty much any distribution you can think of um and heroku has a build pack for it, so it's pretty easy to stand an app up on Heroku quickly. And then if you want to get into advanced deployments, we haven't mentioned this yet, but Erlang and Elixir has this idea of hot code uploading.

So I can upgrade my code in production from one state to the next for literally zero downtime deploys. So not like some people are doing where you have like Nginx, like serve all the requests and then wait and shove the requests on a new instance. It's actually like literally I can update a module from one piece of code to the next and have what it was doing pass that off to the new code, if that makes any sense. How does that work man magic sounds like it sounds like magic to me yeah so so i don't have experience in this

regard uh we have we do have a guide up but it's called uh they're called uh releases we do have a guide up on phoenixfirmic.org for performing these and it will work but you have to you have to think about a lot of things in your code to make sure they can work well with releases. So that's the only thing, like if you don't need that absolutely, you know, critical zero downtime deploy type setup, it's, I would say, not worth it. So you have to kind of weigh the odds of development cost of maintaining that. And then you also really have to test releases because you want those things to work perfectly. So if you're like a telecommunication company, for example, like the joke is you've never heard, like AT&T doesn't call you up and say, you know, sorry, you can't make a phone call

tonight from 6 to 10 PM because we're going down for scheduled maintenance. Like you never, that never happens. So I think for, for some, for some companies they can, they can do that and they have been doing that successfully. So you kind of have to just weigh the odds. But that does work. There's a tool called EXRM, which is like Elixir release tool for building releases and performing hot code swapping. But it definitely requires some more TLC, I'd say.

So just to be clear, we're not talking about a rolling restart. We're talking about live code swapping just like bam yeah exactly so that yeah you can do rolling restart but yeah this is this is like a whole nother ball game of if i have like you know if i have a counter keeping track of number of active users and that thing's in the middle of like running a piece of code that module i update that counter module running a piece of code, that module, if I update that counter module, the new piece of code will get the previous state

of what that counter was. And you actually write a callback and a function to say, there's a code change, here's the state that I had, now you take it and make it into some new state that you want to handle, if that makes any sense. So it's pretty amazing that these kind of things are built in. But like I said, it's going to take some more work. Is this at the language level or Phoenix level?

This is at the language level. The advantage of being on Erlang, because like you said, the telephone companies didn't have the luxury of downtime like we have with the web. Right. So I think what I recommend to people is rolling restarts are totally fine. And I think, you know, to some degree, you're going to have to write your application around,

you know, if someone trips over the server power cord, things are to go down anyway. So you still want to be able to react to going offline anyway. So I think unless you have the peculiar, you know, use case for releases, I think at least getting started, you don't have to really worry about it. But if you do have those high demand, I think there's a, it's not WhatsApp, there's another Erlang chat app that they're running on releases.

So they're like guaranteeing message delivery type stuff. So it's really cool if you have a, especially if you're running kind of some software as a service like Pusher or some of those companies where you can't really stand to have messages dropped. You have to guarantee that there's not going to be any kind of blip. It's a nice option.

Let's switch gears a little bit and talk about the community. One thing I've noticed so far is you've referred to it as we pretty much the entire conversation when when speaking about phoenix who's all involved in phoenix and then by extension the elixir community tells about that sure so uh we've had the great fortune of jose valim has joined the phoenix core team so he's been working on phoenix quite a bit for the last several months and he's contributed some of the biggest features as of late. So Jose is a big core contributor.

We have Jason Steeves, Sonny Scroggins, and I'm going to miss a few people here. But we have a set of, I think, five people on the core team right now. And the community in general, I think, is one of Elixir's biggest assets as far as we're trying to establish the meme in the community of, you know, we're very helpful, helpful and welcoming because a lot of these concepts are difficult to get started in, especially if you're coming into Phoenix, you're listening to this podcast and you're like, wow, this sounds great. Let me dive

in. So suddenly you're learning like a new web framework, you're learning a new language. Then you have this like OTP thing that you're trying to learn. So it's like a new programming paradigm. So like there's like seven different things that are like totally new to you. So we're trying to kind of build a community around being very supportive, asking for help, receiving help. And I think we've been pretty successful with that. Where you said somebody pinged you earlier, I think it was in the pre-call how you got pinged for coming on the show was in an rsc channel what was that rc channel yeah it's uh elixir laying

elixir hyphen laying on a free node that's where i direct anyone that's on twitter mentions anything about elixir i tell them to hop on if they have you know get stuck or have any questions is there one specific for phoenix uh so not yet so whenever jose gets tired of seeing all the phoenix stuff in the elixir channel that we'll make our own but for now it's um kind of one in the same right now yeah he's pretty savvy of jose as the language author and obviously highly invested in the success of elixir to participate in the development of Phoenix because adoption, especially of a language that suits itself so well to the web,

could be highly dependent upon a popular and very high-quality web framework. Do you think that was kind of the deciding factor of why you got involved, or was it just pure excitement for what you were up to? Yeah, I that that probably has something to do with i know from like from the beginning um jose wanted to you know he comes from a web background and he had started a prototype web framework called dynamo while he

was building elixir so from the beginning he was definitely thinking about um how elixir is well suited to web but i think it was think it was Bruce Tate had convinced him that he couldn't write a web framework and a new programming language at the same time. Just it was too much. So instead he built Plug, which was like a HTTP middleware and like web server abstraction,

kind of like Rack, if you're familiar from Ruby. So instead of, he kind of used that dynamo framework to prototype some ideas and why he was building elixir to see how they could coexist and then step back from that built that middleware library and then that that way i was able to come in and build on build on top of his middleware so i think it was just kind of like you know the timing all together you know why he was finishing elixir, I had found Plug and started building Phoenix on top of Plug. And then he was able to finish Elixir and then he hopped on board. So kind of timelines worked out really well. And I think, yeah, the Phoenix's co-bases is definitely, it's been hugely beneficial to have him on board. It's awesome.

So you'd say that Phoenix is still built on top of Plug and still has this middleware thing going on? Yeah. So, and that's the big thing for us is I didn't want to hide the plug layer. So like, if you're coming, you know, I've been talking about Rails a lot, but I come from a Rails background. Like you don't really, you know, you're running on top of a rack, but unless you're using rack middleware explicitly, you know, in day to day, you're not thinking about it. Whereas in Phoenix, we very, we coexist with plug at a much finer level. So you have to be kind of aware of the plug concepts and any kind of middleware or any kind of filtering you do on a request

is all happening with the plug API. Interesting. So it looks like you just released 0.10 with a whole bunch of goodies in there, including live reload support, which kind of amaz me just because we've streamlined the development experience. So it feels like I have a more enjoyable development experience today with Phoenix than I do with Rails, at least starting out. So with Live Reload, since we have the channel WebSocket layer built in, I basically thought last month, I was like, wait a second, why can't I just inject that little bit of JavaScript into the end of the body of your HTML page and then watch the file system for changes and just basically dog food our own real-time system.

So it ended up being like 20 lines of code to have live reload work. And it doesn't require Node.js, it doesn't require a browser plugin, it's all just kind of dog fooding our own real-time APIs. That is really cool. You also have some asset pipeline stuff. You've got some new form helpers. Looks like you're really adding the goodies now. Tell us about 1.0 and then give us just a brief overview of what you see for the future of Phoenix. Sure. Yeah, so 1.0 is basically, like we said, going to be a full stack framework. We are using Brunch, which is a node build tool for asset compilation.

So we didn't want to write our own asset pipeline because we didn't think, I mean, there are mature solutions out there. So we evaluated like half a dozen of the popular node options. I have like a huge amount of hours in that. But we ship with, you know, you just throw your CSS and your ES6 JavaScript, SAS into a specific folder and it just gets compiled. So you don't really have to think about Brunch or Node or anything.

It just works. You have Node pre-installed on your machine or something? Yeah. If you install Phoenix, it will detect that you have Node installed and automatically set it up. So if you have Node installed already, it will just work. Otherwise, you can forego the Brunch integration, but then you just have to build your own build tool. But we have a good asset story. Realtime events is in for 1.0. So I think, you know, for now, from here until

I think the end of April, which is ElixirConf EU, is what we're targeting for a 1.0 release. It's just going to be about stabilizing the APIs. There's some channel work that I want to get in place that is going to make channels a little nicer to deal with at like the concurrency level. But it's kind of a implementation detail. But the biggest feature remaining for 1.0, I haven't mentioned yet, is being able to replay channel messages. So if I've written a chat app in Phoenix and I drive under a bridge on my cell phone, right now you'd miss any of those messages that were broadcasted out through the server. So we want to be able to buffer those messages on the server. And then when the client reconnects after they get out of the tunnel, it just flushes the buffer.

So we're going to include that hopefully as a 1.0 release with mobile clients. And I think that would be a solid 1.0 release to compete with most of the frameworks out there, except we should be able to take on the world, so to speak, as far as scalability goes. And beyond 1.0, what you got? So I have some ambitious goals, I'd say. With my ElixirConf talk, I talked about distributed services. And this would be something that lived under the Phoenix Framework organization on GitHub,

but not part of Phoenix Core itself. But the idea is we have Elixir. I haven't mentioned this, but you write code to run on one machine, and you can run that on 50 machines connected together, and it's pretty much the same code. So the concurrency model is distributed at its heart, so you don't really have to think about receiving a message from a different server on your cluster.

It's all just baked into the concurrency model. So the idea there is I want to be able to write a service layer that I can spin up multiple nodes running kind of different services. So if I have a, I'm writing a search engine in Elixir and I'm using Phoenix, I want to be able to say, okay, I have a page indexer service that is pretty expensive. It has to make page requests, you know, parse the HTML. And I know that I can do a thousand of those on one box at a time. So I want to be able to spin up 10 nodes running that code and have them register themselves on the cluster saying, hey, I can perform the page indexing work, or hey, I can perform the page crawling work.

And then at my application level code, I just want to be able to say, hey, service page crawler, crawl this page, and it will find a node on the cluster that can do the work that's available, do the work for me and give me the result. So there's the gist of kind of the ideas I'm playing with. I think there's a lot of hard problems to solve there around like, you know,

cap theorem and distributed programming, but Elixir enables all that. And it's really exciting to me that that's all possible. You're getting a lot of benefits into Phoenix itself from Elixir enables all that it's really exciting to me that that's all possible so you're getting a lot of benefits into phoenix itself from elixir oh yeah you know choosing the right kind of language and then getting a lot of the benefits from the language itself yep like i mentioned in my uh in elixir conf talk too like if you're running channels you can i'm running channels on 10 different machines, I could have one machine dedicated to streaming Twitter results. And if I find something interesting on Twitter,

it can broadcast it out on a channel and that would show up in the browser. So as long as it's connected to the cluster, I could, you know, like I said, have one machine dedicated to doing these things and you just push out an event and it gets broadcasted out to any listeners on the cluster. And that's just built in. That's just the concurrency model is, if I send you a message, and it gets broadcasted out to any listeners on the cluster.

And that's just built in. The concurrency model is I send you a message, it's just going to go over the network, but the process could be located on any machine. But it's the same as if I was writing that for just my laptop. It's pretty cool. That does sound pretty cool. So let's talk about getting into the closing here for the call,

just for listeners' sake. I've been waiting to ask this because I've been biting my tongue over here on getting started because I feel like you've got so much stuff that we've talked about for those who could be coming from Ruby. So maybe a similar look to the syntax, but once you get deeper in it, as we said before, it's not the same. But still some of the fundamentals, some of the DNA of Rails is in Phoenix. And so you kind of have a home away from home. But how do you get started? I know that Elixir 1.0.2 or plus is a requirement. Is Elixir on most machines? How do you get started with Elixir and also Phoenix?

Sure. So Elixir, yeah, Elixir Ling, elixir-ling.org has getting started guides for pretty much all major platforms. So if you're on a Mac, you can do brew install Elixir. If you're on Linux, it's just, you know, apt. So it's easy to get running Elixir itself. And then for Phoenix, we have phoenixframework.org getting started guides as well. It just takes you step by step um you should have a um an app up and running um with you know live reload and assets and in under you know a couple

minutes i think you know in the in the latest 010 release video i showed that where you just run mix phoenix new it generates a new project and sets you up and you're ready to go well i'm just about a minute or two what's the the hello world, the perfect hello world for someone listening right now to jump into? To go towards? If they're going to build something with Phoenix, I'd say a little chat app. I put a little example out.

The chat app is like the real-time to-do list type thing. If you're coming from Node or Meteor or JS, you're like, oh, I can make a chat app so easily. But I think that's a good one because it just kind of shows you how easy it is to push events back and forth. So I'd say, yeah, check out a Phoenix chat app. Kind of fun to get your feet wet.

Awesome. I do want to take a second to mention this too. For those who are listening that are members, we've been working with Elixir Sips for quite a while.'ve never had a show obviously on elixir or phoenix for that matter but um for those who are members we do have a discount with elixir sips it's 77 off 77 off to be more clear um it's about six bucks for the first three months. So to get started on some of these things, I know that I do such a great job on just exposing a lot of this knowledge, so diving into getting deployment started, all sorts of stuff.

So remember, take advantage of that for sure. But we do ask some really awesome questions heading out of the show, and our favorite to ask is who's your programming hero? Programming hero. More than many, it doesn't matter i mean just share gotcha so i'd say uh matt's uh from ruby would probably be up there um i think just because it kind of embraced being um happy programmer and having a language that kind of put that at the forefront for me was like a breath of fresh air coming into ruby where um you know i don't think at least i had no experience where before you know the creator was like programming should be you should be happy we should um all be

nice to each other and it should be an enjoyable experience and that's kind of the way i feel about programming it's like a it's a creative process and brings me a lot of joy so i think that um has really shaped a lot of people's opinions about programming. So he, he'd probably be up there with that. Another one we like to ask is if you weren't doing what you're doing now, which is building out Phoenix on Elixir using Elixir, if you weren't doing that, what would you be doing? Probably something like aerospace industry.

I'm a huge space nerd. So space has always been a passion of mine. So I think something in the planetary science aerospace industry. But from a programming perspective, I always think that like the Mars rover, for example, like they update the code on that thing on Mars. So I always think like, you know, if there's a bug in my code, I get like a, something went wrong error page on the web browser, but I don't know that I don't know that I would have the stomach for that industry. Just like, you know, rake deploy and you know, it's running on Mars. So I think, um, yeah,

definitely space is a huge interest of mine. I don't know if I have the stomach. Two and a half years or something for your code to get out there, right? Yeah. Well, you have to – yeah, like best case. Like some people, you write code and then 10 years later, you're – yeah, you're hoping it works. So I think – well, I'm super passionate about that. So something along those lines. That's funny.

I guess another good one for closing out is a call to arms to your projects, Elixir, Phoenix. Where are some ways that the community listening to the show now could step in? Where is a good place to either help out with the language itself or help out with the framework and join the core team or help out? Where is a good place to start? Yeah, so phoenixframework.org is the best place to start. And also Elixir Lang IRC is, you know, I live on there. I'm probably on there too much, but I'm happy to help anyone out that wants to jump in. And I think if you already have some experience in Elixir, you can always contribute and give back, whether it's helping someone else out that has questions or now is kind of a great time to get in early and start putting together third

party packages so like you know the plug middleware that we talked about um that's kind of the open season for if you want to build you know a first class authentication system kind of all these different big uh checklist items that the community doesn't have yet you know start building something and might find a problem that's not solved and you can solve it and kind of give back awesome and uh what is your github what is your twitter how can people follow you to kind of keep up with you in general besides irc when you're here it's uh chris underscore mccord on twitter and then just chris mccord on github awesome is there anything else you want to mention as we close out uh like i said i just published uh metaprogramming Elixir on PragFrog. Oh, yes.

So check that out. Is that pre-order now or is it available now? No, it's out. It's been out for about a month and a half. Nice. Check it out. We'll put a link in the show notes for that. Maybe I'll ask you now.

Do you have any discount codes you can give our listeners? I don't at the moment, but I can see what I can do. Awesome. So if you're listening, check the show notes. We'll see if we can get one. If we can get one, cool. If not, we'll just flame Chris and IRC or something like that. No problem.

Also, check out ElixirConf EU. It's end of April in Krakow, Poland. And I'll be there talking about Phoenix. So it should be a lot of fun. We've got the Jose creator of Elixir be there and the creator of Erlang, Joe Armstrong is also giving a keynote. So it should be pretty cool stuff. All right.

Well, that's it for this show, everybody. Thanks for listening to this great conversation. I love the, you know, I was quite silent in this one just because some of the stuff is over my head when you said otp i was thinking something else but uh you know great conversation today so thanks for coming on the show and uh with that let's say goodbye to you do it Outro Music