EW S5E7 Transcript EPISODE S5E7 [EPISODE] [00:00:07] JE: Welcome to Elixir Wizards, a podcast brought to you by SmartLogic, a custom web and mobile development shop based in Baltimore. My name is Justus Eapen and I’ll be your host. I’m joined by my splendiferous co-host, Sundi Myint and my enchanting producer, Eric Oestrich. How are you all doing? [00:00:28] SM: Great. How are you? [00:00:29] EO: Good. [00:00:30] JE: Tops. Thanks for asking, Sundi. That's so sweet. This season's theme is adopting Elixir. Today, we're joined by a special guest, Jason Axelson. How are you, Jason? [00:00:41] JA: Oh, I’m great. Thanks for having me. [00:00:44] JE: We're super glad to have you. Thanks for coming on the show. We were going to make a joke about you being the son of Axel, or the son of Jay. [00:00:53] JA: Son of Axel is probably more accurate, but I’d have to ask my grandma to be sure. [00:00:57] JE: If we had a live studio audience right now, they'd just be laughing hysterically. Laugh track. We need a laugh track. We'll get one. We'll get one. Well, super glad to have you on the show, Jason. I mean, I’m just curious, where are you calling us from. I know that it's early morning from you. It's mid-afternoon, just noon for us. Where are you calling us from? [00:01:14] JA: I’m calling from Honolulu, Hawaii. Over here, it's right about 7:00. It's fairly early, but not bad. [00:01:23] JE: Yeah, but I bet the weather is much nicer than it is out here in the East Coast. [00:01:29] JA: Good chance. [00:01:31] JE: Well, now that we've got the audience and myself sufficiently jealous, let's just open up with some personal questions. We’re really curious about how you got into programming, if you were formally trained, if you came into the field from a classical path, or some other means? [00:01:50] JA: Yeah, I would say overall, it's a fairly classical path. Both my parents are programmers, so they were pushing various things from an earlier age. One of the first things was – I don't know if you’ve ever heard of a Lego Mindstorms, but it's basically like Lego bricks and there's one large brick that has some small CPU on it and then you have bricks with wires they can connect, so you have different sensors, like a light sensor, or sound and motors. You can program it with this block-based programming language, like a visual programming. My dad got that for me and my siblings and that was just a lot of fun to play around with. I liked the programming a lot more than I liked the actual building of the different things, unless they had – I remember, I made one – My favorite accomplishment with that was making a little robot that would just follow a black line that I could scribble on a piece of paper. [00:02:42] JE: How old were you when you were doing this? [00:02:45] JA: Probably about 12 or so. [00:02:47] JE: Do you feel that was a good age for – because I’ve got a bunch of nieces and nephews, Christmas shopping. [00:02:53] JA: Yeah. [00:02:56] EO: Might even have to get for this Christmas. [00:02:59] SM: I feel like this is something we've been hearing a lot of recently, is a lot of people got started by doing some robotics project as a kid. That's cool to hear. [00:03:09] JA: Yeah, and then after that, one thing that well, that didn't quite work was my parents got me some sort of software life cycle development book that started by like, “Okay. First, let's gather all the requirements for our Visual Basic application.” I got through the first two chapters and I hadn't built anything in that. I never really got anywhere with that. My first full introduction to programming was my AP computer science course. That was in Java. I was a junior in high school, I think. I remember, the first few days or so of that, I just really tore through the first couple chapters of the book, learning about – Actually, formalized loops and conditionals and everything and I just really – that really clicked with me and I really, really enjoyed that. [00:04:04] JE: Wait. How old were you when they gave you the book? [00:04:06] JA: Maybe 14? [00:04:10] JE: Amazing. Your parents sound like my parents. It's completely adult books for kids. That's funny. It wasn't Project Management Body of Knowledge, was it? [00:04:23] JA: No, I don't think so. [00:04:25] JE: Okay. That's the ridiculous project management book my parents got me when I was 15. [00:04:29] SM: I feel like you're scarred for life if you can remember the name of it right now. [00:04:34] JE: Oh, yeah, yeah. No, I can tell you. I’ve got lots of stories of books foisted on me by my parents. I see Amelia Bedelia written here. [00:04:42] JA: Oh, yeah. [00:04:43] JE: Who was that? [00:04:44] JA: Amelia Bedelia is a children's book, or children's book series. She's this maid for a wealthy family or something. She takes everything completely literally. If you were to ask her to draw the drapes, she would draw you a picture of the drapes and dusting the couch would be putting dust on the couch. If you wanted to dust off, you'd have to ask her like, dust off the couch, because her family was very literal. I feel at least to me, that applies to programming, because I think a lot of programmers tend to take things super extremely literal. [00:05:22] JE: We have to. Or else, people won't put together good specs. [00:05:25] JA: Well, computers are completely literal in that sense. [00:05:29] SM: Did you read that series and then say, “Oh, this is interesting. I want to be a programmer”? Or was it after you became a programmer that you were reminded of that series and how literal we are? [00:05:40] JA: Yeah. Definitely the second one. Then something in a similar vein was my – I guess, a couple times growing up, my parents, we would play a game where my dad – I guess, you could say he would act like Amelia Bedelia, but he would do – take everything completely literally, or opposite of how you might intend it. I would always do the best out of that for my siblings. [00:06:05] SM: That's awesome. You've mentioned books quite a few times now. Are there some resources that you find really helpful when getting started, if you were to recommend a book series, or a tutorial to follow for somebody who's getting started in the field? [00:06:22] JA: I don't remember too many of the books from when I was first getting started in programming, but I do know in college, one of the books that I enjoyed – I want to say is like, A Definitive Guide to JavaScript or something, but I just did that for a – one of my semi-Capstone projects, so we didn't learn JavaScript in one of our courses at that time. I just enjoy going through – It was one of those thick books, 500-plus pages or something. Yeah, I know it's good. I can't remember the title. I think it was a yellow cover, but that's not too helpful. [00:06:58] EO: There's an O'Reilly book called JavaScript: the Definitive Guide. I think I had that one as well. [00:07:03] SM: Is it yellow? [00:07:05] EO: It was green at the time. [00:07:08] JA: Yeah, most O’Reilly books are probably pretty decent. It's probably good. [00:07:14] EO: Were books the only resources that you drew on when you were learning, or were there other resources that you really found helpful? [00:07:21] JA: I mean, there was definitely – I would definitely look at blog posts and things online about how to do things. This was before Stack Overflow. Now Stack Overflow is obviously a very good resource. Yeah, nothing specific. [00:07:34] JE: Now to the meat of it. What about Elixir? [00:07:38] JA: Elixir. I started with Elixir back when I was at a company called Hobnob that makes a mobile app to get people together for events. [00:07:48] JE: Are they still around? How are they doing at this age? Sorry, I [inaudible 00:07:51]. [00:07:51] JA: Yeah, they're still around. Yes, it's definitely rough with coronavirus and that was actually when I switched companies. [00:07:59] JE: You think that Hawaii wouldn't have gotten it. You guys should just been like, “Don't come here. Stay home. Stay home mainlanders.” [00:08:07] JA: Yeah, we did try some of that. As a US state, you can't actually close your borders, not like New Zealand or something. Yeah. I was at Hobnob, which was written – the back-end for that is written in Ruby on Rails. We were developing a better messaging system for it, so we looked at a various different options. The very first version, we were actually using pusher, which just can create messages and you get them on other devices, but you're limited in that and it's an external service, so you can't define custom behavior as much. We implemented, yeah, our new chat service in Elixir. Then it was great. I know it’s a lot. [00:08:55] JE: You're working in Hobnob. You're writing in Ruby on Rails. They decide they're going to make a chat service for an events app? Can you give a little bit more detail there? [00:09:04] JA: Yeah. You can ask questions about the event or chat live during the events, send DMs to people. [00:09:10] JE: It's like a microservice, or it's acting like a microservice for the main – [00:09:14] JA: Yeah, it is. Because the Ruby on Rails side is all just a monolith. Then all the Elixir stuff was a separate service. I wouldn't really say it was microservice, because it's just the two services. Then eventually, we started moving some things over to Elixir. [00:09:29] SM: Were you a Ruby developer before you started working on that project? [00:09:33] JA: Yeah. Yes, I did Ruby at a few other places after college. [00:09:38] SM: Cool. You learned Elixir mostly on the job then, or did they do any external stuff to train you up? [00:09:45] JA: Yeah, it's completely on the job and then just on my own. One course that I did was on Dave Thomas’s course. I forget the name of it right now, but I really like his Elixir course. [00:09:58] JE: Oh, we love Dave. [00:10:00] SM: Yeah, that's awesome. Can you speak a little bit about what you're doing now, what your current projects look like with Elixir? [00:10:07] JA: Yes. Right now, I’m at a company called Animal Repair Shop, which is based on a character from Do Androids Dream of Electric Sheep, which is where Bladerunner is from. [00:10:19] JE: Wait. Animal Repair Shop is what it's called? [00:10:22] JA: Yeah. Our website is somewhat vague. It actually should be updated by the time this goes live, so that should be fun. We're a mixed reality studio. We do things with AR, VR, that type of thing, but we haven't actually launched anything as of yet, so I don't know. There's not much I can talk about there. I work on the back-end that's written in Elixir for that. [00:10:50] JE: Is it a pretty big company, or are you the only – how many back-end developers you work with, I guess, is the question? [00:10:56] JA: It was only a small handful. [00:10:58] JE: You really get to drive the arc. You're probably also doing devops and everything over there. [00:11:03] JA: Yeah. [00:11:04] JE: Very cool. [00:11:04] JA: Yeah, I got my hand in just about everything. [00:11:07] JE: I’m going to jump back to Hobnob. Like I said, we're going to jump all over the place. I’m curious, when you were at Hobnob and – Could you just maybe tell the story a little bit of how – I mean, did they ask you? Were you part of the design process, part of the decision-making process choosing to write it in Elixir? Can you just give us a little bit more of the narrative around that? [00:11:29] JA: Yeah. The CTO brought it up as something we need to consider about how to implement the chat service, whether just continue with our current approach and try to improve it, or actually switch to Elixir. [00:11:45] JE: There was already a chat service built on Rails. [00:11:47] JA: Kind of. I mean, you could create comments, basically. It wasn't really chat. It was just comments and it was just plain messages. There's no images. Nothing rich in that sense. [00:11:58] JE: Was it built on action cable? [00:12:00] JA: No. This is before that. [00:12:02] JE: It’s a long coupling and – [00:12:03] JA: It's just a database model and pusher messages. Just strings really. [00:12:09] JE: Then on your roadmap, you get this enhanced chat feature and the CTS – [00:12:13] JA: Yeah. We want to have presents and stuff also. Yeah. Initially, I had to be convinced a little bit, just because I was worried about how long it would take to spin up a whole new service. Given all the requirements we had, I think I felt like it made sense. [00:12:28] JE: When you were doing that exploration, or trying to get convinced, were you, I don't know, you have people build to do apps and every JavaScript framework? Was there some process there for you to explore the language and anything that sticks out in your mind as far as an aha moment, or a hurdle that made you more productive? [00:12:47] JA: The main thing that sticks out to me about that time was the reading a couple Phoenix blog posts. I think, one of them was the Road to 2 million WebSocket Connections. Mostly, just about the performance of Elixir, especially relative to Ruby on Rails and ActiveRecord. There's just a lot of performance benefits that you can get with Elixir. [00:13:07] JE: That's a super famous blog post, but maybe you could give the audience the too long, didn't read version of that blog post. [00:13:15] JA: Yeah. The Phoenix team took a machine in the cloud, fairly beefy and just pushed it to see how many connections they could get live connected to one single machine. I think initially, they started somewhat relatively low. It started a 100,000 connections. Then they looked into what was causing the performance problems and using observer, some similar tool and they saw one of the present processes had a large backlog in their message queue. They’re, “Okay, let's fix that.” The next day, they try it again. They get up to 300,000 or something and they find another bottleneck. Then without too much effort, they got up to 2 million simultaneous WebSocket connections and they're able to send messages over it. It's just really inspiring. [00:14:02] JE: This is ancient history now from 2015. [00:14:06] JA: Yeah. [00:14:08] JE: How long ago were you doing this work at Hobnob? [00:14:10] JA: I was doing it about three years ago. [00:14:14] JE: Okay. Yeah. You're pretty early to the Elixir world. [00:14:18] JA: Yeah. Yeah, not too long after 1.0, I think. [00:14:21] SM: Really, how early is early? What's the total number of years for Elixir in real life now? It's 9? [00:14:29] JE: Version 1 came out in 2014. [00:14:32] JA: Yeah, I think 2013-ish is when it became known. We're still pretty early days, regardless. [00:14:40] SM: Yeah. So early to the Elixir world. Yeah, halfway through its lifetime or something. [00:14:48] JE: Yeah. I want to go back to this question, because I’m always curious. When you're learning Elixir for the first time, were there any turning point moments for you in terms of language features clicking into place and just being like, “Oh, my gosh. That's amazing. I’m so glad that I get to use this now.” [00:15:06] JA: I felt it was just a constant stream of that for me. Everything just really, really clicked for me. One of the things that I really like about Elixir is just how explicit it is about everything. That's more a cultural thing. Then also, just definitely pattern matching and the immutability is great. You don't have to create classes for things that don't really fit classes. I remember the first resource that – the main resource I went through initially was just the getting started guide for Elixir on the official website. I feel that's just written very well. I don't know. Generally, feel that's not too common from a first-party resource. I just enjoy that a lot. [00:15:55] SM: Jumping to your current job, you mentioned it's a smaller team, it's a new thing, website should be updated soon. Can you talk a little bit about how you guys chose Elixir and what it's like spinning up a new team with Elixir and that whole experience? [00:16:11] JA: Yeah. We didn't have too much of a discussion of it, just because the team was already – everybody's already familiar with Elixir. To us, it just made sense as a back-end, because Elixir is just a great general back-end programming language. Even if you don't necessarily really need all the concurrency and presence and whatnot. [00:16:34] JE: I know what everybody's really going to be excited to hear about is Elixir LS. If you could just from the top, tell us what it is, why do we need it, what problem does it solve? [00:16:45] JA: Elixir LS is the Elixir Language Server, which is a server that implements the language server protocol, which is a protocol from, or written by Microsoft, maybe partially for VS Code. The general idea is that rather than every programming language editor pair having to write a full extension that supports each language, so we'd have to have a VS Code Elixir extension, a Emacs extension, a Vim extension, you can just have one server that talks this common protocol and you can use that same protocol in every different editor. Each editor just needs to implement the protocol. Then now, they can support any given language that has a language server. Elixir LS is the Elixir version of that. It's great, because it gives you all these IDE type features, so you can go to definition, you can find out where a function is used in your project. You can get some smart auto completions, even for things your ecto schemas when you're writing a query. Just lots of great stuff like that. I definitely recommend it for any Elixir developer. [00:17:56] JE: Yeah, I use Vim. I’ve never heard of Emacs or the other thing that you mentioned. We’ve got a low-key editor lore at SmartLogic that I perpetuate, without allowing my opposition to have the floor to defend themselves. [00:18:15] SM: I think she can hold her own against you though. [00:18:17] JE: But she's not here, so it doesn't matter. Sorry, Keena. How did you get involved with the language server project, Jason? [00:18:25] JA: Okay. I got involved, because I noticed that the language server and then Elixir sense that it depends on had both stalled. This was in, I think, 20 – maybe late 2018 or so. I was talking about it on the Elixir Slack with Travoke and Andrew Summers. Travoke was like, “Basically, we should do something about this.” He created a GitHub organization, which is so GitHub/ElixirLSP, so language server protocol. He forked the two repositories into there. We started working on maintaining and merging some of the pull requests. Because yeah, we just didn't want the tools to stall, partially because I think good developer tooling is pretty crucial for adoption now. [00:19:17] JE: Can you talk a little bit about maybe the architecture of the project? If I’m a new developer getting started looking at contributing to it, how would you give me an overview of the project? [00:19:30] JA: Yeah. Yes, the main library that Elixir LS is built on is Elixir Sense. Elixir sense does all the code analysis. It can parse Elixir files and it also has a error tolerant parser, because when you're doing programming, a lot of times you'll be editing a file, which means your file won't actually compile at the current state that it is in, but you still want to have things like auto completion and such work. Elixir Sense can do error tolerant parsing, recover from as smartly as it can from five different errors. It has a lot of the analysis of the Elixir AST they would get if you're doing coding some piece of code. Then Elixir LS builds on top of that and actually, implements all the various language server protocol response and the JSON format and all that. [00:20:22] JE: When you were getting started, do you remember what you initially jumped into working on on the language server? [00:20:31] JA: The first thing I remember working on was on the Elixir sense side and helping it support, I think, maybe Elixir 1.8 or so. Because Elixir Sense cares so much about the specifics of the language, it's actually rather – I guess, you could use – or it's rather sensitive to new Elixir versions. One of the maintenance tasks is to test it on new version and then make any updates as necessary. Yeah, also both projects actually use a pretty good amount of some of the private Elixir internals. Those have to be maintained. [00:21:03] SM: I know that some of our hardest code problems that we've solved can turn into our most fun stories to talk about. What was an interesting thing that you learned from working on this project? Was there a very difficult problem that you've solved up until this point? [00:21:18] JA: I think, one of the hardest things to solve in this for me is just the community aspects of it and just trying to help it stay a community project. Part of that is to being responsive on issues and pull requests and trying to get other people to come in and contribute to the project. That's what I see. I see it as a shared project for the Elixir ecosystems, so it's great to have lots of different contributors to it. [00:21:44] SM: Yeah. How do you actually go about finding contributors? Do you use the Slack or some other means? [00:21:49] JA: Yeah. Sometimes on Slack, we have language server channel on the Elixir stack that we use. I’m on the Discord as well and the forum, of course. Then we also have a issue that I had pinned on the Elixir LS repo for a little bit that was a call for contributors. Just asking people there. [00:22:08] JE: You gave a talk about Elixir LS. [00:22:10] JA: Yeah. Yeah, I did. That was for ElixirConf this year. The ElixirConf US. [00:22:16] JE: I guess, if you want to give the TLDR that talk for the audience, I’m sure they'll go listen to it afterwards. That would be a good place to start. I’m also curious, if you learned anything in preparing the talk and putting it together that stands out to you now? [00:22:33] JA: Yeah. I don't know if I learned anything too specific from it. The overall topic was Elixir LS and the shared governance of it, which is what I’ve been talking about just now. Yeah, I went into more detail about some of the implementation of it and the different – so the different processes and the async nature of it. [00:22:54] SM: ElixirConf was completely virtual this year. Was there anything different, or strange about giving this talk virtually? Was it your first virtual conference that you were speaking at? [00:23:05] JA: Yeah, that was my first. Yeah, so it was different than what you would expect from an in-person conference. I guess, one of the hardest parts for me as a speaker was just not being able to actually see the audience and get something real-time feedback from them. Yeah, but overall, I enjoyed it. Jim did a good job, I think, given all the constraints and craziness that we have right now. [00:23:28] SM: Yeah. I was jumping around so much during ElixirConf that I feel like I only got snippets of everyone's talk. When I get some downtime, I’m really just going to sit down and just play everyone's talk, so I’m looking forward to hearing yours again. Back to Elixir LS, is there anything new coming down the pipeline that's exciting, or do you need any more contributions? Can you shout out that you need some help? I’m sure our listeners would love to join in. [00:23:55] JA: Yeah. I mean, we always could use some more help and more contributors. There's a whole bunch of things that would be great to implement that we're not implementing right now. One of the things that's currently in the pipeline is some formatting speed improvements that Ben from absinthe has been working on. Hopefully, that'll get merged in soon. Another thing that's got merged recently is the ability to run tests, like [inaudible 00:24:23] tests from Elixir LS. Currently, that's only supported in VS code, because you need to have a little – some code on the editor side to do the integration of the specifics for that. There's an Emacs version that is hopefully, going to be merged soon for that. I’m also working hopefully, on a creating a configuration file for Elixir LS, so you can either enable some experimental features and just control it per project. [00:24:56] SM: You mentioned something a little earlier when you were talking about how you got into this project. Good developer tools are crucial to adoption. This whole season is about adopting Elixir and hopefully, making it easier for our listeners to grasp onto Elixir if they're learning, or bring their team up to speed with Elixir if that's what they're doing. Or even pitching to bring Elixir into their companies. I was wondering if you could expand on that thought a little bit. I don't think anyone so far this season has talked about developer tools. [00:25:24] JA: Yeah, there's a couple ways to think about it. Some is just the developer tooling helps people to understand the language better by being able to experiment with their code and they can write some code and they can use some of the editor stuff to either, to understand exactly what's happening, whether that's doing a go to definition and then obviously, things like syntax highlighting is a very basic thing, but that just helps you understand immediately as you're writing it, you can see like, “Okay. Okay, this is getting interpreted as a string now, or now this is a syntax error,” and you can see why it is without having to switch context and go to the terminal and try to actually compile your code. [00:26:03] SM: Yeah, I can say from personal experience while I was learning, I think one of the first things I set up when I set up VS code, sorry Justus, was – [00:26:11] JE: What’s that? I’ve never heard of that. What is it? [00:26:13] SM: Yeah. Anyways, I definitely, like I had somebody tell me, “Oh, install this, this and this, these package tools or whatever.” Elixir LS was one of them. I didn't really think about it. I’m a very color coordinated person, or color-oriented person. If I’m looking at the code and it's the wrong color, I think something's wrong. If I have one function that does something and another function that does something else and the second function has something that looks identical and they're the wrong colors, I’m just like, I’m reading the words and they look correct, but they're the wrong color. Obviously, I’ve done something wrong, or I just forgot to say or something. I will say, yeah, looking back onto my learning experience, I found that very helpful. Also, to being able to dig into function definitions and seeing where something was made and jump around the code that way definitely helped me unwrap what was going on. I’m not a fan of magic, as I say. Even though we're wizards here. [00:27:10] JA: Yeah, one of the things that the tooling can really help you with is understanding your dependencies better. You can do a good definition on a module from a dependency and you can actually see the implementation of that. With Elixir, I find that's really, really very helpful, because I feel the vast majority of dependencies that I look at in Elixir is actually rather understandable, once you actually dig into what's happening. There's a few that might use – make heavier use of macros. For the most part, it's pretty easy to understand and I think that can really help grow you as a Elixir developer also. Just seeing, reading some code. [00:27:46] JE: I want to ask a high-level question before we start to wrap this up. I’m curious, what you think needs to happen to the language and to the community in order for Elixir to become a more mainstream back-end option? [00:28:06] JA: I think there's a few different ways you could tackle that as a community. I think, one is just more libraries in Elixir. That'll definitely happen with time. I think if we try to make that a focus in the community, you can have it happen sooner. Just for any specific thing that you want to do, just having a library, being able to rely on there, most likely being a library that you can use for that, I think that's very great for adoption. Especially for startups, is you don't want to spend too much time that's not on your core business domain. Related to that, something I would love to see is people, because generally, a lot of these open source projects are developed by a single person, but they may eventually either get burnt out, or leave Elixir, or programming for any specific reason. That's actually what happened with Elixir LS. That was originally developed by Jake Becker, so we owe him a great big thanks for doing all the initial development and getting it to where it was at that point. He actually switched to – he doesn't even do programming anymore. He's been working on building his house somewhere out in the Midwest or something. Being able to switch some stewardship of open source projects and continuing them beyond the initial developers, I think, is great for the language. That recently happened with XAWS, so that's great for adoption. Then obviously, just more developer tooling, just improving Elixir LS and such, I think, would be – is great for adoption and getting some other niceties. It would be great if somebody would submit a PR that allows you to auto-import, or auto-alias a module based on auto-completion, or be able to rename your module, or a variable, or function. [00:29:58] SM: Now that you say that we don't have it, I need it now. [00:30:03] JA: Yes. You're going to submit that PR in a couple weeks, right Sundi? [00:30:09] SM: Let's see how the winter goes. Awesome. [00:30:14] JE: Well, I think before we let you go with any plugs or ask for the audience, we just want to give you one more chance to give any advice that you have for anyone that's trying to bring Elixir into a company, selling Elixir so to speak, to stakeholders or anything like that. If there's anything like that that you can maybe talk about before we close out. This might be a good way to wrap it up. [00:30:38] JA: I think, a good first step would be to read Adopting Elixir, if you're interested in books, because that's a really great intro about adopting Elixir at different companies. I think it has some specific tips on bringing Elixir into companies. I think a great way to start it is to do a brown bag lunch session, where you talk about Elixir and why you really like Elixir. Maybe show some maybe a little side project, or something you've built in it, or some other – maybe just even just a project from the community that's cool. When you're starting a new project, you could propose Elixir as one of the options, especially for internal tooling, just because it's a little bit lower risk there, because a lot of times, those products aren't as large. If they need to be rewritten, they could be. LiveView is a really great option there as well, just because you can get so much done in a short time with LiveView. A lot of times for these internal tools, you might need some interactivity, or it's just a great selling point to be able to see things update live, even though without having to put in hundreds of hours of effort into that. [00:31:46] JE: Cool. At the end of every episode, we'd love to give the time to the guest to make any plugs or asks for the audience, shamelessly self-promote, anything you want. The time is yours. Take it away. [00:31:59] JA: Yeah. Yeah, definitely one of my – something to promote would just be that everybody can get involved with Elixir LS and we welcome new contributors. I’d love to work with you. See, another thing, one of the other projects I have in Elixir is called priv check. Priv check allows you to see if your code is using any private functions or modules and you get a compiler warning there. It uses the compiler tracing hooks for that. It would be great if people would try that out. Yeah, those are my main plugs right now. [00:32:37] JE: That's cool. [00:32:37] JA: You can also check out devfiz, which I did Codebeam Brazil talk about, but that allows you to see all the dependencies of your various modules and especially the compile time dependencies, so you can better understand why changing one file will cause a 100 files to recompile and you have to wait for 3 seconds while they all recompile. It's a really visual tool, which is something I like also. [00:33:03] JE: Lit. That's awesome. Thank you, Jason. That's it for this episode of Elixir Wizards. Thank you again to our guest, Jason Axelson and to my co-host, Sundi Myint and my producer, Eric Oestrich. Once again, I am Justus Eapen. Elixir Wizards is a SmartLogic podcast. Here at SmartLogic, we're always looking to take on new projects building web apps in Elixir, Rails and React, infrastructure projects using Kubernetes and mobile apps using React Native. We'd love to hear from you if you have a project we could help you with. Don't forget to like and subscribe on your favorite podcast player. You can also find us on Instagram and Twitter and Facebook, so add us on all of those. You can find me personally @JustusEapen, Eric @EricOestrich and Sundi @Sundikhin. Join us again next week on Elixir Wizards for more on adopting Elixir. [END] © 2021 Elixir Wizards