The Changelog: Software Development, Open Source - Let's talk Elixir! (Interview)

Episode Date: October 9, 2019

Jerod is joined by Chris and Desmond (co-hosts of the ElixirTalk podcast) to catch up on what's moving and shaking in the Elixir and Phoenix communities. We discuss what's attractive about Elixir, what it means to have the language finalized, why folks are so excited by Phoenix LiveView, the ambitious new Lumen project that's bringing Elixir to WebAssembly, and more.

Bandwidth for ChangeLog is provided by Fastly. Learn more at Fastly.com. We move fast and fix things here at ChangeLog because of Rollbar. Check them out at Rollbar.com. And we're hosted on Linode cloud servers. Head to Linode.com slash ChangeLog. This episode is brought to you by DigitalOcean. Guess what?

DigitalOcean recently added MySQL and Redis to their list of managed databases. Their full managed databases lineup now includes the three most popular databases out there for developers, Postgres, MySQL, and Redis. It'll eliminate the complexity involved in managing, scaling, and securing your database infrastructure, and instead, get back to focusing on building value for your users. Learn more and get started for free with a $50 credit at do.co slash changelog. Again, do.co slash changelog. All right, welcome back, everyone. This is the ChangeLog, a podcast featuring the hackers, the leaders, and the innovators of software development.

I'm Adam Stachowiak, Editor-in-Chief here at Changelog. On today's show, Jared talks to Chris Bell and Desmond Bowie, the co-host of the podcast Elixir Talk. They're catching up on what's moving and shaking in the Elixir and Phoenix communities. They discuss what's attractive about Elixir, what it means to have the language finalized, why folks are so excited about Phoenix Live View,

and the ambitious new Lumen project that's bringing Elixir to WebAssembly. So this just in, according to InfoQ's latest programming language trends report, Elixir is on the list for the very first time, and they're calling it the innovator adoption phase. Today, I'm joined by two innovators, I suppose, the co-host of the Elixir Talk podcast to talk all about Elixir. Chris and Desmond, what's up, guys? Hey, how's it going? I consider myself more of an adopter than an innovator. Well, it's the innovator adopter, so you're both, I suppose. And I suppose I am as well, as I've been using Elixir for a few years now.

We've covered it in the past on the show. This is kind of a catch-up. What's new? What's going on in the Elixir community? But before we get into the news and your guys' thoughts on the news, I'd love to learn how each of you came to the programming language. What excited you about Elixir? Made you switch from whatever you're up to before.

Yeah. came to the programming language, what excited you about Elixir, made you switch from whatever you're up to before? Yeah, so I've been writing Elixir full-time for about four or five years at this point, actually. Adopted it previously at an agency we were working at. We were doing a lot of Ruby on Rails, and I think like so many people in the Elixir community kind of had an entry point like that. So writing Rails apps, finding a lot of issues there running those things in production scale issues just leaning on a lot of libraries a lot of external kind of systems to be able to build these complex applications on the web basically found elixir and never looked back so i have been writing probably on my fourth or fifth elixir production application in that time as well given some talks about it in the past as well that you can go back and check out. Yeah, like latest app, Elixir all the way.

And I can't imagine doing anything else now. So yeah, go on Desmond. Similar story. I got into Elixir four or five years ago. I've been doing Rails for a long time before that. I was consulting at the time and had a side project that I'd written in Rails that needed WebSockets for some real-time update. And it turns out that Rails cannot do real-time WebSockets.

And I thought, all right, let's figure this out in 2015. Like, I know that there's an answer for this and came across Elixir. So I bought the book. I spent a weekend digging into it, doing a sample project, and pretty quickly was like, this is the future. This is the way forward. And so everything after that has been kind of

along this path, started going to the meetups, which were I think, three people at the time in New York, and then put on the impacts conference several years ago, which is how I met Chris. And at this point, I've probably worked on a dozen Elixir applications. Yeah, probably a dozen Elixir applications. So what was it? What got you? What made you say, oh, this is the one, this is my future. I couldn't imagine doing anything else. I think for me, so much of that is to do with the language itself. I think, obviously, it comes a lot from the surrounding community and the ecosystem around it. But like, so much of it was about like the kind of explicitness of the language and just falling for functional programming in a really big way and

then just realizing like i don't know if you both had this experience of like doing the thing with ruby where something is mutated somewhere and you're like oh my god what's actually happening here and then you discover like a different way to do it and you realize that mutation is can be really harmful in certain cases and i think elixir felt like a really great antidote to that at the time so that was my hook it was really like grokking this concept of functional programming and just thinking like wow this thing is great and i can be so explicit with pattern matching and doing all these things in multiple function heads and it just just felt like such a nice way to write programs. And honestly, to this day, I still jump in, write some Elixir code, and I'm like, huh, that felt good, you know, still. And it kind of hasn't lost its magic for me. So

obviously very biased. Yeah. I was annoyed at first at the verbosity of having to pass all these arguments into all the functions. And particularly when I was first working with Phoenix controllers, it seemed awkward to always have to give it a connection object instead of like in Rails, you just write your instance variables and this thing is somewhere in the background. But I pretty quickly fell in love with case statements and pattern matching. It took me a minute to figure out quite how it worked. But then once I really got that down, it was like, I remembered suddenly with fear and anxiety, all of the nested if statements that I would see in other programming languages and trying to untangle, how do I get to this code path? How do I set up the conditions to see this, this tree of execution, all of that has now disappeared. And the solutions to my problems are always very simple, which is pretty helpful when you're working in a complicated business domain.

So that was the hit. And then the thing that's kept it going has been digging into the technology and realizing this is a 30-year-old platform that a lot of people put a lot of time into making very robust and having great tooling. So that's just been a joy to continue to work with. That's interesting. I'm very similar with you on pattern matching. and having great tooling. So that's just been a joy to continue to work with. That's interesting. I'm very similar with you on pattern matching.

When that clicked for me, I was like, oh, I don't want to write code any other way. And so when I do go back to Ruby or when I write JavaScript, that's really the thing where I was like, I like the pipelining, but I could live without it. I could just chain. But the pattern matching and the multiple function definitions that just call the one that matches the input coming in makes you write so much more confident code

that I really, really appreciate that. That being said, unlike you Desmond, I've never dug into the underlying technology. I think it's a testament to the abstractions that I haven't had to. That being said, I've been writing Elixir for I think three or four years now and we've been running it in production for Change.com for years. And I was recently on Full Stack Radio with Adam Wathen talking about that. And he asked me about OTP.

It's not even a brain fart moment. I was kind of like, wow, I can't even really describe this. I know what it is, but I don't know it well enough to even tell Adam what it is. And so how do you guys describe OTP to the uninitiated? It's harder than it sounds, isn't it? Yes. It is harder than it sounds. I mean, I guess it's technically a separate collection of libraries and abstractions for

building systems on top of very primitive building blocks. I don't really think of it as a separate thing outside of the language because I don't think it's useful to think of it that way. But it's sort of the difference between saying I have a very low-level abstraction of a process that I can send messages to because the whole Erlang VM is built around the actor model. That is fundamentally baked into how it's constructed. Okay, I can send a message to a process.

Interesting. What's cool is OTP has a slightly higher level of abstraction where you're not just dealing with a process. The process knows about other processes. You can build what's called a supervision tree, such that when two processes are linked together and one crashes for some reason, the other knows about this and can restart it.

Or it will know about that crash and take some other kind of action that you as the programmer specify. So it gives you these tools for building very clear failure modes and very clear success modes. And so you can understand how your system can and should break down. And it's a very different way of thinking about your application in terms of, well, what if this goes wrong? How do we gracefully recover from that? Chris, anything to add or maybe subtract from what Desmond said there? No, I think that's a pretty good definition. I really like to think about OTP

as almost like Erlang standard library, but it just happens to have all of this kind of weird extra stuff in it. And a lot of that stuff is very, very useful for building highly concurrent, very like failure tolerant and fault tolerant systems, right? And that's really what we

get to leverage day to day in elixir and i think a lot of people talk about the fact that as a language elixir is kind of like standing on the shoulders of erlang right in a lot of ways in the sense that we get this great runtime and then we can borrow and use all of the standard lib in there including a lot of this otp stuff as well and like that just means that we get to use that abstraction layer that desmond's talking about to build these very very nice to work with actor model driven systems where to your point a lot of the time that abstraction is kind of hidden away from you right like i'm sure the changelog runs phoenix right and you know phoenix is written on top of all of these concurrency primitives and leveraging OTP.

You just don't even need to worry about that as a user, right? And in fact, you get this highly concurrent, very scalable system out of the box because of that. And I think that's really the advantage in the ecosystem here. I still don't think it's useful thinking about OTP as a separate thing, even though technically it is. Chris has a great way of describing the different rungs of the ladder of learning about Elixir. And the first

rung is syntax. And the second rung is probably function composition. And then the third rung is when you get into OTP and concurrency constructs. So I think you can very successfully use the language without really digging into any of that. I mean, you're a great example, Jared. I mean, you've been using this for years. I'm proof positive of that being the case. And as I said, I think it's a testament to the abstractions more so than it is to me being a noob, because I know the language very well. I don't consider myself a noob, but I guess you'd consider it pedestrian needs. You know, I'm running a website. Phoenix is built on top of these things.

I get the advantages, but I haven't. I put things in my worker list. I can't remember the exact terminology there. I know I've interacted a little bit through configs, but that's as far as I've had to go. I'm happily hanging out on rung two, I guess, is my point. Yeah, you know what? I think that's good. That's really good, right? You've got

this like kind of boring technology that you've used and leveraged to build a very, like very good platform. And honestly, like so much of the work that I find myself doing in Elixir is kind of like that as well sometimes. Right. But then the best thing is, is that when you need those other things, you've got that in your toolkit, right? Like let's say you need to run something concurrently. Let's say you need to kick off a task and just run it in the background or something right you don't have to reach for sidekick or a message bus or something like that you can just spin up a task and literally just like process that thing concurrently at the same time so like all of that is part of the language and i think the fact that we have those abstractions and those great primitives

and the fact that you don't always need it, these are both really good things, right? So it means you can start somewhere and then layer on complexity and build very complex systems over time, which I'm sure like most of us are trying to build systems like that, not starting out with like, oh, my God, I'm going to try and architect this like this crazy, really interactive system where you've got all of these different pieces communicating with each other at once. You're trying to start simple and build on top. This episode is brought to you by KubeCon CloudNativeCon, and you are invited to attend this flagship conference from the Cloud Native Computing Foundation, KubeCon CloudNativeCon. And you are invited to attend this flagship conference from the Cloud Native Computing Foundation. KubeCon CloudNativeCon North America 2019. That is a mouthful and an awesome conference to attend. It's happening November 18th through the 21st in San Diego, California. This conference gathers adopters and technologists from leading open source and cloud native communities.

Use the code KCNA changelog19 once again kcna changelog19 to get 10% off registration or check the show notes for a special link to register and also a link to the convince your boss letter again check the show notes for links to learn more and register so you two and the elixir community are fresh off of elixir conf lots moving lots shaking lots of excitement around live view we're gonna talk about But first, let's talk about the finalization of Elixir and what that means for people who are either new to the language or been using it for a while. Yeah, so you're referring definitely to Jose Valim's keynote. So Jose is the creator of Elixir, if you didn't know, he gave a keynote where he talked about the fact that the language has got to this point where they're not necessarily adding a ton of new features it's very stable it's mature at this point and there's been this really great focus on stability and extensibility around the language which has meant that like we're not

reaching for a 2.0 where we're going to make loads of breaking changes and in fact jose said in his keynote that if there will be a 2.0 there's one breaking change that was in there from like elixir 1.0 that i think they messed up some of the implementation and in hindsight obviously you want to fix those kinds of things but i think it's a really really good example of the fact that elixir is very stable and is mature now and we've got all of these parts and we've baked them into the language like when we started out we didn't have date times in the language. We didn't have any of this. We didn't have any calendar types. We didn't have any time zones.

That's all in there now. No time zones. Is that a feature? Don't you wish. We've eliminated them from reality. You know, it's like one of those cases where it's like they looked at the community, found a library,

and then baked it in and took some of the best parts of that abstraction and that library and then baked it into the language itself to remove a developer pain point. And you've kind of seen that time and time again, right? There was these really good building blocks. Elixir as a language itself is basically a language made from macros. So most of the things in the language were there that you could write easily new parts of it without breaking something else already. And we've just been able to keep building on top of that with this really, really good

focus on stability and extensibility. And I think it's proved to be very successful for the language as well. And for us as developers and ecosystem. Yeah, it's kind of weird to think like, oh, the language is done. I'm not going to get any cool new features. But that's sort of the yeah, this year's model syndrome. Like when I'm using the language, there's nothing that I wish I had that I don't have. I don't look at any other languages and think, oh, this, you know, we really want that that would make my Elixir experience much better. It's just kind of frightening to have someone say, well, really, the onus is on you

to build something interesting with this, the onus is on you to build something interesting with this. The challenge is on us to build interesting applications or on us to develop frameworks outside of the core language that, again, the language maintainers don't have to maintain because it's not part of core. And they're driven by actual industry needs, actual use cases. And I think it's a much better way of approaching problems. It's just kind of frightening at first to have that kind of personal responsibility.

Yeah, I just want to add as well, like, I think there's this narrative around Elixir where people are like, the deployment story is really hard, right? And I'm sure you might have experienced this deploying the changelog as well. And I think like, actually, now you've seen releases become part of elixir in 1.9 as well as an example of that idea of like let's find the pain points let's not break anything let's just give you a better developer experience and like fix one of those pain points and do it in the actual like core language itself yeah i think it shows also just the transition to a larger audience or maybe an opportunity for the mass adoption at this point.

Because when we go back to the InfoQ article, it's just now being considered innovator adopters. The other sections in that graph, they have early adopters, they have early majority and late majority, and these are like the big waves of tons of people. The crash, the early majority, they have things like Swift, Python, TypeScript, late majority, PHP, Ruby, JavaScript. Now we could probably spend some time talking about what we think about those categorizations. But the fact is that stability at the language level provides opportunity for

people who are not the innovator types. They don't want to be dealing with like massive breaking API changes all the time to say, hey, this is ready for you now. And it doesn't mean there's not going to be any new things. It's not like a lack of innovation is going to happen, but there's just a certain level of stability which you can rely upon. Definitely. And we've seen that now in the adoption by a lot of bigger companies as well. There is PagerDuty now using Elixir at scale to replace some of their Rails components. You've to replace some of the rails components you've got pepsico e-commerce you've got brex you've got all of these like very large well-funded companies who are now adopting the language and building sophisticated applications on top of it and like

i think it's a great sign of the fact that you know we're not in this like niche community anymore elixir is actually out there in the mainstream, powering big applications at scale, and it's better than ever. And I think if there's people in 2019 looking around for what to adopt, you should look long and hard at Elixir. As we said previously, it's based on this 30-year-old piece of technology. So you're getting this battle-tested, hardened, and also mature and scalable language out of the box. And I think, can you do much better than that today? Well, I think another question is, all right, cool technology, bro. What do I do with it? How can I get a job? Is what it often comes down to,

is how do I get a job? And two years ago, I would say even two years ago, there were just a handful of companies that you would have heard of that were hiring. Something's changed recently. I don't know what it is. I don't know if it's something in the water or just like we've hit some inflection point. I was at a ElixirConf a couple weeks ago. And this guy came up to me because I've been trying to help some people find Elixir jobs. And he says, All right, I'm in a stealth mode startup. And we're trying to hire people. I said, cool, like, how big is a team? How many people are you trying to hire? He said, I want 20 people by the end of this year. And I said, oh, it's come to this, has it? Companies are

springing up. I mean, even so I'm based in LA, I run the meetup here. I'm pretty tied into what's going on. Like companies are often popping up on the radar. I'd say in the last six months, three or four companies have emerged from seemingly nothing with teams of four and five Elixir developers. And when that starts happening, when companies are showing up that, you know, under your nose in your backyard that you've never heard of with, you know, teams, it's not just one or two people, then something's happening. And, you know and the jobs are there. So it's cool. I think that's the piece because everyone says, well, how do I find people? How do I hire people? And how do I get a job? Let's turn our focus now to, I think, probably what's the most intriguing

thing going on, at least in Phoenix world, Phoenix being the most popular web tool in the Elixir ecosystem. Chris McCord and the team have been working on a thing called Live View, which from my vantage point has people interested and intrigued and watching, even who are not into Elixir, like, okay, what are they doing over there? How's this going to work? And talked about much at ElixirConf. Now, I have not heard your latest episode, 154 of Elixir Talk podcast, but I did read the synopsis and it sounds like y'all disagree on Live View. So there was an active debate on that episode, 154 of Elixir Talk podcast, but I did read the synopsis and it sounds like y'all disagree on LiveView. So there was an active debate on that episode,

which I'm looking forward to hearing. Maybe we can get a little taste of that and what you two think about LiveView. But first, somebody tee it up with what is Phoenix LiveView and why is everybody so excited or at least interested in what's going on there? Sure, so LiveView is a way to write dynamic templates

with real-time interaction on the server. So instead of having a client-side framework that manages interactive DOM updates and pinging your server to make changes, you do that all in your Phoenix app on the server with the familiar EEX templating language. And it's a slightly different EEX templating language because they do some magic under the hood to track changes in your data. But behind the scenes, it transparently pushes that data out to the client in a very efficient way. So what does this mean? Well, it means it's really easy to write templates. You don't have to drag in a large framework.

You don't have to spend a lot of time writing dozens of lines of JavaScript. You can instead write, and there are a bunch of great examples out there of implementations of things like search ahead, autocomplete, paging, people have written games in 10 lines of code. I mean, they don't write games in 10 lines of code. Yeah, demo games. The pitch is it's a very concise way to solve these very common problems. And it's really attractive to people who need a little bit of interactivity, a little bit of dynamic presentation on the front end, and want an easy way to do that. And there's still room for frameworks like React or Vue,

if you're writing a very heavy tool with a lot of interactivity rules like that, that's still out there. What LiveView does is it expands the circle of what you can do with just server side, quote, server side technologies. Yeah, I'll just add to that. So you've basically got this like persistent web socket open from the client to the server where the user's session on the server is always guaranteed to be there effectively. And then you can run updates to that user and push them down the WebSocket. So you're basically like writing a client-side app, seemingly magically using server-side technologies, right?

So remember like Turbolinks and those kinds of ideas where you're pushing whole templates and replacing whole bits. We use Turbolinks, by the way. You do? Oh, awesome. Yeah, so kind of a similar concept, except for the fact that you're using WebSockets as a transport layer, and then you're relying on a lot of the kind of

concurrency primitives that Elixir gives you in order to model basically every user's session as a process. Yeah, so the open question that we have here around changelog, which Nick Janotakis in our Slack has been prodding me to try out is like, can we completely replace our Turbolinks with LiveView and just cut completely over and have a lot of the benefits without any of the some of the drawbacks of that? Are you using it for like pagination and things like that? Yep, we use it for all navigation basically yeah i mean then that's a great place to basically do it you can effectively say that now the state of the page is managed by a live view process and you can

basically say every navigation or let's say you've got like a on your feed of podcasts you want to load the next 20 or 30 whatever that can all be managed in live view you just write some server side templates exactly like what you're used to writing if you're rendering Phoenix anyway. You just use live EEX instead of regular EEX, and boom, everything can kind of just work. And what's cool about that is it's more than just replacing JavaScript with Elixir, which I think is a win and Chris and I will disagree about for quite a while. Okay. There's a preview of the debate right there. When you let LiveView deal with this stuff, you automatically eliminate entire host of questions around things like, well, what should the route be? What's the data format that I'm sending over the wire? What

does this JSON payload look like? All that is just swept away and managed for you in live view. And it's really nice not to have to think about these questions that are really incidental to the problem of, I just want fresh data on the screen. I don't really care what endpoint I'm hitting. So now you don't have to. And they've done a lot of great work to be very efficient about what does get sent over the wire. They don't send over a whole template when something changes. They really just send over the tiny piece of data that has changed. And it's really interesting to look at the inspector and see what's coming over the wire and how they segregate dynamic versus static parts of the template. But the bottom line is it's, I think, more efficient than a lot of JavaScript

frameworks. And I mean, unless you're doing like protobuf stuff, it's a very clean way to send things over the wire. Absolutely. And like, I think, honestly, this is my biggest complaint is that I don't know if you can compare these things one for one, right? I think that live view is a great thing to reach for if you've got like a sprinkling of JavaScript on an app, like what you're talking about here in the changelog. Yes, that's exactly what we have. Yeah, exactly. And like, you know, I'm sure we've all written server rendered apps where you layer in that bit of JavaScript, and it feels like the JavaScript is the weak link. And sometimes you have you have to say like well now I need even more interactive JavaScript and I need to reach for React but now I've got this weird like rendering boundary between React and like and your server rendered thing right and

LiveView feels like a great replacement for that where you're actually saying no I'm going to keep things in the technology that I'm using for the rest of it I'm going to write everything in this kind of server rendered mentality and just keep a web socket open that's great that's a really good pitch for live view in my mind but I will say I cannot see everyone replacing like entire applications like let's say like a google docs or something like that entirely in live view because because like inherently you need like very stateful client applications sometimes. And sometimes like the communication costs of going back to the server and doing a round

trip even over a web socket is going to be too high, right? And there are cases where LiveView is just not a good fit. Like if you have extremely highly interactive, very stateful apps, let's say like you're doing like drag and drop uploads and very complex kind of moving things around. And it's a very like UI complex kind of moving things around and it's a very like ui heavy kind of web application right like i think what we're all trying to aspire to build on the clients these days i i just don't think live view is going to replace this plethora of javascript that now exists and it's very well and mature like ecosystem and all of these tools

you're basically forgoing all of that. Tooling, yeah. Yeah, you want to use some React UI library. Sorry, you're out of luck. You're basically going to be rewriting that. And that's my biggest issue here is that I would like us to see as a community, instead of pushing up and saying, don't write JavaScript, what would it look like to do more integration

and make it easier to build these applications, maybe leveraging some more Elixir pieces to it? But I think there is a fundamental weight to writing this stuff in Elixir with a lot of things taken care of for you. I mean, am I going to write Google Docs in LiveView? Probably not, but someone already wrote Google Docs, so I don't have to worry about that. And there's a great competition that just closed called Phoenix Frenzy, where it's like, what can you do? Show us the craziest LiveView stuff that's out there. And people have written Kanban boards with LiveView, with drag and drop swim lanes, with

different cards and everything. I think file uploading is like next on their roadmap. That's a big thing to figure out. You know, when they first released this a year ago, they said it's probably not a good fit for chat and it's probably not a good fit for games. And here we are a year later, and people have written a ton of chat clients, and a ton of games in this. And so I look at it as one of these things, these tools that has a ton of potential. And in the landscape of right now, maybe it doesn't make sense to use this technology versus that. But when you see

where it's going, people are just going to keep pushing what this can do. Because the benefits of being able to express problems in Elixir that are closely tied to the rest of your server, it's easy to broadcast updates to these processes, it's easy to reason about them. I think that will begin to overpower the benefit of a quote, stable JavaScript ecosystem, which I think is a mouthful and an awesome conference to attend. It's happening November 18th through the 21st in San Diego, California. This conference gathers adopters and technologists from leading open source and cloud native communities. Use the code KCNACHANGELOG19, once again kcna changelog19 to get 10 off registration or check the channels for a special link to register and also a link to the convince your boss letter again

check the channels for links to learn more and register and by cross browser testing from smart bear the innovator behind the tools that make it easier for you to create better software faster if you're building a website and don't know how it's going to render across different browsers or even mobile devices you'll want to give this tool a shot it's the only all-in-one testing platform to let you run automated visual and manual UI tests across thousands of real desktop and mobile browsers make sure every experience is perfect for everyone who uses your site and it's easy and completely free to try. Check it out at crossbrowsertesting.com slash changelog

Again, crossbrowsertesting.com slash changelog Another interesting thing happening in the Elixir world is called Lumen, which is a web assembly target. Guys, tell us what's going on with WASM. Yeah, so this is the big surprise at ElixirConf, I would say. The big thing. Yeah, huge announcement for the ElixirConf I would say. A big thing. Yeah, huge announcement for the Elixir community. Basically making Elixir have a WASM compile time target. So what does that mean, right? Like why Elixir and why WASM? So basically Lumen is

all about getting Elixir code to work in the browser, right? Compiling down to Web Assembly and that Web Assembly then executing in the browser, right? Compiling down to WebAssembly and that WebAssembly then executing in the browser environment. I mean, there is so much to talk about here and it's kind of crazy what they've been doing. They've basically foregoed the existing runtime, which we've talked about on the show already, which is the Beam, in order to basically make a new compiler for Elixir that then generates this WebAssembly code, basically rewriting a lot of the internals of the beam in Rust and then leveraging a lot of Rust existing WASM kind of crates in order to produce this target where you can compile it

and run it. And basically you're able to do a lot of the process model in this WebAssembly environment through them rewriting effectively the scheduler. Yeah, it's really out there, by the way. So and this is super early days for this technology. But I just want to add a few things, which is, first of all, it's really, really awesome to see Elixir pushing to new places, right? Whether that means it's going to be there, I don't know. But basically, every other language at this point has their like skin in the game in this wasm space so i think the fact that elixir can be there or might be there could be a really good thing for us as a community second as a technical achievement this isn't like it's incredible right they're they're basically written elixir to run the

elixir code that you know and you have written everywhere basically the the objective is just to get that running in your browser via wasm and that's like mind-blowing honestly so i think as a technical achievement this thing is huge and then i think like this could be the beginning of introducing some really really interesting actor model kind of processes to your like to components effectively so by that what i what I mean is like, right now, there's an example of this in this other library called scenic, which is basically using the actor model to model things like buttons and UI components. So we could effectively start to model like imagine your react component with all these fault tolerance guarantees, like what we're talking about that

exists in the BeamVM effectively now via processes and OTP. So we could start to think about having lots of message passing between components and it could be a very, very different way to write web applications. And that to me is like, that's kind of crazy as well. So I'm excited. Just to break that down a bit. I mean, imagine you have your UI that's broken up into several components and one component breaks because your data is funky or whatever. The rest of it keeps working and you have a very localized like, oh, we can't show this piece over here.

But the rest of the app looks fine. I mean, that's a very interesting failure case that we don't see that often. Or it restarts, right? If we've got supervisors, we've got restart strategies. So we can say like that bit of the UI will boot back up into its previous state or some known good state, right? And that like, I can't think of anyone else

thinking about writing web applications like that. I could be wrong. I haven't done that much research into that, but I'm assuming that there are many, that many people thinking about it. So, you know, that could be really cool, I think. Most of us are still at the phase where we put semi-colon in the wrong place and our entire web page

no longer runs JavaScript. So I think this is a step beyond. So what's the bear case? Maybe this never comes together and can ship real code or what? Yeah, I mean, they've got a monumental task in front of them, basically. They've got to rewrite a lot of the low-level implementation for the Beam, effectively. Every call that you have that then goes down and executes Erlang code, they've now got to rewrite in Rust.

Basically, on the GitHub issues page, there's a ton of issues for Lumen where it's just like, implement every function in the map module to work with Rust, right? And that's really the task in front of them. I think they've proved out the technical feasibility of this thing, which is a huge milestone just on its own. And now you've got to see this thing mature. You've got to get people to adopt it. Someone's got to write some like component web framework for this thing as well. So it's a long road, but yeah, I don't know. Let's, let's keep seeing where it goes. And beyond just a use in the web, it's interesting because now you have a compiler that will deliver

a single executable and something that people have complained about in the past with Elixir releases is that it deployment is a headache. And as we mentioned earlier, that story has gotten much better, but it's still not the go story or the Java story of give me the executable, drop it on the server, call it a day. And this will do that. And there are some trade offs it makes around things like you no longer have hot code reloading, which I'm personally a fan of. But it turns out a lot of people don't use this feature. So they're saying if we get rid of that, then we can do this. And I think there's a lot of potential there. If you're saying, all right, if you compile to this target, then you get your executable and you too can call it a day. And then I would say as well, like it allows us to think about running Elixir on places where we

haven't been able to run it, right? Like, so Cloudflare is a huge place where they're adopting Wasm like left, right, and center and running Wasm at the edge, right? And Wasm now is a highly optimized runtime. It's having so much time poured into it. So if we can leverage that and we can then get the Elixir running places like on the edge and doing some really interesting things with processes there,

this could be a whole other place where the language can be rolled out and could be a whole new adoption story for people getting into it. Exciting times indeed in the Elixir community. Let's talk a little bit as we close up here about the community itself, where it happens, where people get together. We have conferences. I know you guys are running a couple of conferences called MPEX. Tell us about what the Elixir community looks like in terms of like places to go, people to talk about. I know Elixir Forum

is a thing. So help people understand where community happens. Honestly, I think the first place is at your local meetup. I mean, there's a great Slack channel. There's, as you say, an Elixir Forum where people get together. Very surprisingly friendly community. I don't know why it's surprising,

but it's a very friendly community. I guess surprising in the context of programming communities. Yes, I will vouch for that. I've been on Elixir Forum quite a bit and I'm always impressed by the quality of answers and really the niceness of people on there. Yeah, but I think, you know, community happens in person and you get cool projects when you meet up with someone, you get jobs when you like talk to people in your hometown. So I would encourage people listening to see if there's one near you, there probably is. I am one of the organizers of the Elixir LA meetup,

and it's a great place to get involved and to get started. Outside of that, there's, as Jared mentioned, there's a bunch of regional conferences, in particular, the ones that Chris and I work on, which are called MPEX. And I will quickly plug the upcoming MPEX LA, which is happening in Los Angeles on Saturday, February 8, 2020. I believe when this episode airs, there will still be another week of the CFP open. So if you've been listening to the show, you happen to have a talk, please jump on our website, which is MPEX CO. I believe that'll be in the notes. And submit a talk and check that out. And then podcasts. Can we talk about our podcast now?

Is that an appropriate time? Yes, we were just talking about before the show that there's a bevy of Elixir-focused podcasts, which I think is a sign of strength in any programming community. You have Elixir Talk, you have Elixir Outlaws, Elixir Mix, Elixir Fountain, lots of Elixir going on. And I suppose the best one of the bunch is, is elixir talk guys what do you think uh i don't want to say that

so desmond and i are co-hosts on elixir talk and we've been running that for about the last year and a half two years two years two years yeah okay there we go time flies i would say if you are looking for some more Elixir content, we do, we have a lot of guests on the show. We focus sometimes on beginners. We talk about some of the libraries a bit more in depth. Yeah, check us out. We'd love to have more listeners, obviously.

And we'd love to hear from more people. So yeah, get involved. Friendly Neighborhood Technical Elixir Podcast. There you go. Well, Desmond, Chris, thanks so much for joining us today, catching us up on all things Elixir. I'm excited about LiveView. I'm excited about Lumen, which I didn't even know I was excited about until just now.

As always, listeners, thanks for joining us. All links, as Desmond referenced, are in the show notes for you to get access to quickly. We appreciate you listening, and we'll see you next time. Keep Elixirin'. All right. Thank you for tuning in into this episode of the changelog hey guess what we have discussions on every single episode now so head to changelog.com and discuss this episode and if you want to help us grow this show reach more listeners and influence more developers do us a favor and give us a rating or review in iTunes or Apple Podcasts.

If you use Overcast, give us a star. If you tweet, tweet a link. If you make lists of your favorite podcasts, include us in it. Also, thanks to Fastly, our bandwidth partner. Rollbar, our monitoring service. And Linode, our cloud server of choice. This episode is hosted by myself, Adam Stachowiak, and Jared Santo. And our music is done by Breakmaster Cylinder.

If you want to hear more episodes like this, subscribe to our master feed at changelog.com slash master or go into your podcast app and search for Changelog Master. You'll find it. Thank you for tuning in this week. We'll see you again soon.