[00:00:00] Erik: if Elm never got updated again, I don't think I would care. I think it just is in such a great place. It doesn't mean there aren't any little quirks or things, but for the most part I think the way it works just is really, really good.

[00:00:15] Jared: Hey, folks. Welcome back to Elm Town. I'm your host, Jared M. Smith. We'll be visiting with Erik Person today.

[00:00:22] Sponsored by Logistically

[00:00:22] Jared: But first, let's talk about our sponsor, Logistically. At Logistically, we make intuitive software to help logistics teams make better decisions and improve efficiency. Logistically pays me to record Elm Town episodes, as well as pays for our production and hosting costs.

[00:00:40] We build the front end for all new features in Elm. If you're interested in our mission and enjoy writing Elm, please drop us a line elmtown at logisticallyinc. com. I'll put a link in the show notes.

[00:00:52] Introducing Erik

[00:00:52] Jared: Now, let me introduce Erik. Erik previously made Elm Seeds, which taught little bits of Elm in each video.

[00:01:01] He is currently the VP of Engineering at Corvus Insurance, where he started as the first engineer. They use Elm on the front end. Corvus was recently acquired by Travelers. Erik, welcome to Elm Town.

[00:01:15] Erik: thanks so much for having me.

[00:01:16] Jared: Yeah, of course, uh, I really appreciate you coming on and

[00:01:20] Getting started

[00:01:20] Jared: I wanted to get started by just kind of going back and talking a little bit about how, what you were really interested in that brought you to computer science and programming.

[00:01:32] Erik: Yeah, for sure. So, um, my, uh, mom was a computer scientist. She studied at Iowa State and, um, always had some job in software. And, uh, so I was exposed to it pretty early on. And so, um, after we got the, the family computer at, I don't know, What I was, age 7, age 8, something like that. Uh, we started getting kind of small introductions, uh, to it through games and things like that.

[00:01:57] And, uh, then just started trying to do more, especially for school projects. Um, I remember learning HTML to, uh, to do a particular, uh, History Day project in, in 8th grade. And so, you just kind of got started and then, um, Took some classes in high school, and then I believe I got my first internship, um, right after high school.

[00:02:17] It was kind of a, a family friend. I think he was doing, uh, doing me a solid there, helping out. But it was my first professional time writing code, and so, uh, yeah, it was, uh, a lot of fun. So, just got into it, loved writing code in school and, and learning about software engineering practices. And so, yeah, was really into it ever since.

[00:02:34] Jared: These classes you took in high school, what were you learning in them?

[00:02:38] Erik: I think everything was Java at that time. Um, yeah, just, uh, plain old boring Java.

[00:02:45] Jared: Yeah. Okay. So you're learning Java, object oriented programming, and, and so were you coding just little algorithms and things? Were there games? What kind of projects did you have?

[00:03:03] Erik: Never got to the level of making a game, but did some graphics. Um, I'm trying to remember what it was called at the time. I think JavaFX came after what we were doing. Swing was the kind of UI framework. And, um, you know, definitely wasn't understanding it well enough to be able to go too deep into it. And was kind of just learning all the differences between, you know, what does static mean and those, and it took a while, you know, to learn all those real fundamental things about the language.

[00:03:30] So never, uh, never did anything too interesting with it.

[00:03:33] Jared: Sure. Okay. And then you get this internship. What was that like? What kind of work were you doing there?

[00:03:40] Erik: It was building software for, uh, architectural firms. So, uh, really designing out how the, the girders and the, you know, steel posts and everything are going to make a building. Um, this was a long time ago, so I'm trying to remember it exactly. Uh, the one thing that I definitely remember is we used TCL. Um, I believe they called it TCL, TCL TK.

[00:04:03] I think TK was the UI framework. Um, and anytime I look at TCL now, I just can't imagine trying to write in that professionally. That sounds, uh, pretty rough. But, uh, yeah, it was, it was definitely a, a fun experience. And, you know. Never gonna write TCL again, but it was a good time.

[00:04:19] Jared: What kind of challenges would you have had at that point, other than learning TCL?

[00:04:25] Erik: Yeah, just being a beginner was definitely the biggest challenge. I didn't know much about software development practices, you know, like working with a team and all of that. It was my first exposure to version control. The tool we were using was called RCS at the time, which is kind of the thing that predates Subversion, which predates Git.

[00:04:46] So, yeah, just getting exposed to a lot of that. What it means to be a professional software developer was a big change, because you're still just learning how to code in the first place.

[00:04:56] Jared: Right, right. Okay, so, you're learning on the job. Did you have any particular mentors, or were you just kind of asking questions as you went along to whoever would listen, or were you taking classes at the same time? How did that work?

[00:05:13] Erik: Yeah, still taking classes at the same time. And then as far as mentors go, uh, that company, uh, it was called Design Data, based in Lincoln, Nebraska. Um, everyone there was so incredibly nice and gracious with their time and willing to help this, you know, 18 year old kid try to figure out what he's doing.

[00:05:29] Um, so yeah, a bunch of people there. Did so much to help me, you know, navigate code and understand what I'm doing. You know, the first project I remember was to put in a checkbox in the print dialog to reverse the order of the print. Um, so if you're trying to print out 50 pages, you know, does it start with one or start with 50?

[00:05:47] And, um, so just trying to track that down and make it work properly, um, takes a lot. So I just always really appreciated all the help everyone gave.

[00:05:56] Jared: so You're starting out, you're learning. What happened next? Where did you go from there?

[00:06:04] Erik: So there it was, yeah, time to go to school, go to college. I went to the University of Nebraska and, uh, Started with a computer engineering degree, um, and I think by my sophomore year switched to computer science, I realized really quickly I loved the software aspect and the hardware aspect was a lot less interesting, so I really went into the, uh, the software development world and, yeah, tried to learn everything I could there from building operating systems to the actual development practices to, yeah, just building web applications and everything like that.

[00:06:36] Jared: You're kind of building, getting into web development at this point. Had you had any experience up to then?

[00:06:40] Erik: Nothing up until then, and I think all of the web development experience at that point was just on the side. So school projects and those things were writing Java or writing C. And, um, the, the curriculum was just a little outdated at that point, and so, uh, anything on the side, um, was kind of how you found the web, so, uh, I got an intro to Ruby on Rails in, back in, this is probably 2006 or so, um, so fairly early in those days, and you were just reading, uh, things like Slashdot and, uh, learning that this seemed to be the future, and so, uh, yeah, wanted to learn that and, yeah, stuck with it ever since.

[00:07:18] Or not Rails specifically, but web development.

[00:07:20] Jared: Right, okay. Yeah, so you're, you stuck with web development for sure.

[00:07:27] The flight to Elm

[00:07:27] Jared: So after this point, did, did you discover Elm while you were working there, or was this later on?

[00:07:36] Erik: It was a bit later on, um, I was really interested in Lisp, just learning Lisp. Um. Partly because it was functional, partly because it was just totally different and nobody seemed to really know a lot about it in my circles. Um, so I, I do lots of research and I discover Clojure and ClojureScript and I, I start working with those and eventually I get to a point where It's just not quite clicking, everything.

[00:08:02] Not just the functional world, but ClojureScript and how it, I think, integrated with React, and just wasn't quite, quite clicking, and then I started reading that ClojureScript, um, was using a lot of elements from Elm. And so I said, okay, well that's interesting, I should go learn a bit about Elm. And then Elm just clicked instantly.

[00:08:20] I just understood it, I loved how simple the language was, I loved the Elm architecture, um, the way data flowed through that, and it just, it really clicked, and so I just kind of stuck with it ever since.

[00:08:33] Jared: Okay, and so you're learning Lisp, before you get to Elm, as, oh, because it's functional, right, you

[00:08:42] Erik: Right.

[00:08:43] Jared: and because people didn't really know a lot about it in your, uh, world, so then, why Lisp and why not Haskell or, you know, whatever else may have been around, F sharp, I think might have been around,

[00:08:59] Erik: I don't think I knew any of those others, I think I just read about Lisp, um, I believe that's probably a A slash dot thing that that was a very popular thing to talk about there. And so I'm sure I just kept hearing about it and I knew that the functional orientation was just very different, or at least was always described as very different.

[00:09:18] And so, yeah, once I got into it, you know, I knew I was getting close to something. And then, yeah, it really took learning Elm to fully grok what I was doing.

[00:09:28] Jared: right, and so that's when it clicked. But you were searching for something up to that point. What did you feel like functional programming was just different and so it was new? Was it that people were talking about it a lot? Or was there something that you felt was missing from what you were doing with Java or Ruby or whatever the language is that you were using previously?

[00:09:56] Erik: In hindsight, I think I can say I was searching for something, um, at the time, I'm pretty sure I just wanted to do it because it was different and esoteric and just seemed like kind of a way to fight the man, uh, in some sense of just, yeah, my job is making me write C sharp and dot NET, or if I go look for another job, it's going to be Java or something, and so yeah, what's just the thing that's different, so that's really what I was looking for.

[00:10:24] Jared: Interesting. So then, yeah, you do discover Elm. What, how did you discover Elm?

[00:10:30] Erik: Think it was just reading more and more about ClojureScript, and I believe his name is David Nolan, who wrote a framework on top of ClojureScript, which is now escaping me, or I think he wrote ClojureScript in the first place, and then some frameworks on top of that, but, um, I kept seeing him say he was inspired by Elm and took lots of ideas from Elm.

[00:10:49] And so I finally decided, well, I'm just going to go straight to the source here and check that out. And yeah, so once you, you see that, and because it's so focused on. Web development anyways, that just, again, really helped make it so easy to, to get into and, and understand.

[00:11:05] Jared: Yeah, that's right. Okay. Yeah. You said that, that ClojureScript was inspired by Elm. You saw that you like, okay, let's go to the source. Let's check what this is about. It clicked. And so you liked it. But I'm guessing you didn't immediately go find a job writing Elm in production. What happened next?

[00:11:30] Erik: Yeah. I quit my job, um, at the time because I was just like, I wanna do something in functional languages. This is just really great. I think this is better. I would love this. Um, I, I actually attempted to, uh, start my own company for a little while, um, that was gonna use Elixir on the backend and Elm on the front end, and I, I eventually burned myself out on that.

[00:11:50] I was trying to do it solo, and, um, I was really enjoying the programming, but, uh, trying to do the sales and those things, enjoying those a lot less, so, um, yeah, after a year of that, I finally decided to go look for a job again, and, uh, was looking for something that was a completely brand new company, something where there wasn't already any code, and the languages weren't chosen, and those things, and so if I could find that, I could come in and, uh, Set those as the languages, as the first engineer, so that's what ended up happening.

[00:12:22] I found Corvus, they were really looking for the first engineer to join the team. Yeah, nothing was written, didn't have a product, didn't have anything, so it was the perfect opportunity to get it going in a new place.

[00:12:33] Jared: Oh, cool. Yeah, so you were very intentional about that, about looking for a place where you could introduce the technology that you thought would be best.

[00:12:43] Elm seeds

[00:12:43] Jared: Had you already started at Corvus when you were making Elm Seeds, or did Elm Seeds come first?

[00:12:49] Erik: I believe the Elm seeds predate Corvus. Yeah, definitely they did. Uh, I think I had started those at the previous job and continued to work on them, uh, on my kind of year off, and then, uh, eventually I, I trailed off after a while, just got, you know, you get busy with other things, and, um, I kind of look back and wish I would have kept doing more, but I was, I was proud.

[00:13:09] I, I made it through 50 some episodes, so I felt pretty good about that.

[00:13:12] Jared: Yeah, I believe 55. So yeah, I think that's really great what you did provide, you know, the, the opportunities for others to learn. And actually, there's a question that I've paraphrased from Andrew here. What did you learn from doing Elm Seeds? And did you learn anything that you wanted to incorporate into your language, Erie?

[00:13:34] Erik: What I learned from doing those is definitely a, uh, A sense of, I just gotta publish this, um, It's very easy to want to do retakes, and to want to, uh, Yeah, try to just really make it perfect, And then you realize you're spending multiple hours on this ten minute video, And eventually, you get to a point where you decide the trade off isn't worth it, Um, and then I'd say the second thing is really about the storytelling, So I, the first few of those I probably barely thought about at all, and just, I just started recording and just kind of wanted to see how it went and by the end there you're definitely not writing a script exactly for like what I want to say, but definitely here's the story I want to tell with this.

[00:14:19] I want to make sure that the problem I'm about to describe is something that can resonate with people and as we solve it that that makes sense and that, you know, I'm not expecting people to remember this code, but I hope that the story is just enough that they remember. Oh, I saw that on Elm Seeds once.

[00:14:33] Let me go back and find that episode. See if that can help me solve my current problem, so. I'd say that's kind of how all that started. As far as influence on Erie, this is a project I'd love to get back to at some point, but it is a version of Lisp, but built on the BEAM, and BEAM is the framework underlying Elixir and Erlang.

[00:14:56] And so, I don't know how much of that inspired it, other than I just still really like the idea of Lisp, and would like to make a language. I love the BEAM. I think it's just a super powerful platform, and so I know there are LISPs out there for the BEAM But I was really interested in making my own typed LISP so I would say yeah, the the biggest influence is definitely the the Elm types just in general and being able to leverage those in other environments.

[00:15:22] Jared: Okay, cool. Yeah. So you learned some about storytelling, right? And about just getting things published. At This point as you were kind of learning and you took this year off and you were building out this, this product, what I guess at first, what was this product that you were trying to build?

[00:15:43] Erik: Yeah, it was end to end encrypted communication and collaboration software. I still like the idea of it, but the way I think about it is when you use something like a Confluence or a Notion or any other sort of wiki documentation software, Google Docs, your company is storing its most valuable information on somebody else's servers.

[00:16:09] Not to say, you know, Google doesn't take that incredibly seriously, and, you know, it's certainly encrypted at rest, and encrypted in transit, and all these other things, um, But, if some nefarious actor at Google, or Notion, or Confluence, or wherever, still wanted to see your data, they could get to it, right?

[00:16:25] There's access controls, again, they take it seriously, they try to protect it, but they still theoretically can read it. And so, I really like the idea of more of an end to end encrypted solution, where I, as the content hoster, could not read it, no matter how much I wanted to. And so, um, one, I think there's a lot of companies out there, um, who would really benefit from this effectively, uh, against government spying.

[00:16:49] Um, but then also just to, to feel extra secure, uh, about their data. So, um, yeah, I, I still like the idea. Um, I don't think as many people see that kind of end to end encrypted solution as a necessity. And, um, I think they all trust Google just fine to, to host it and not worry about it. But, um, I'm sure there's a niche set of companies out there who would actually appreciate having that extra layer of safety.

[00:17:14] Why Elm at Corvus?

[00:17:14] Jared: So I have a, another question from Luke Heafield via Andrew Lenards. It is, quote, Why did you decide to use Elm at Corvus?

[00:17:26] What other options were you comparing at the time? End quote. And I know you mentioned that, you know, you had learned Elm as a functional language and it really clicked for you, but were there any specific qualities that you thought really made Elm the choice for you?

[00:17:42] Erik: For sure. I, I still continue to think that the, the type safety is just a, an incredible benefit and it's not the, the type safety in and of itself, it's also what the types allow. And I think a lot of people, um, uh, Luke as the person asking the question probably understands this pretty well, uh, is the, the way to model your problem and your domain and, and write the, I know there's a common phrase out there is to, to make impossible states impossible.

[00:18:12] And once you kind of learn the value of that and get to see it in action, you just really start to think like, hey, this is a better way to do things. Um. And so, to me, that, again, that's just part of the, like, oh, this just clicks, this just makes more sense, I think it's better, I think we can have more people work on this together.

[00:18:30] Um, and then the other side is that I know when you pick a, a more esoteric language like that, you have a lot of people in the world who really want to work on that professionally, and they will go out and they will seek those roles, and uh, I, I know Paul Graham wrote an essay about this, I think it was called the, the Python Paradox or something like that.

[00:18:52] But this is back in the, the 90s when Python was new, um, but same idea. The people who wanted to work in Python tended to be, um, really great developers, and they were seeking out those Python jobs, and so it was a great place to be. Um, so I, I saw Elm as the, the same opportunity that we could offer this, and we would get certain people who are gonna apply because they really want to work in Elm.

[00:19:13] And so, um, I think that's, that's worked out really well for us. Um, a significant number of the engineers on our team, uh, either had Elixir or Elm experience coming in the door, and so that is a great leg up for them, and I think it helped us tremendously.

[00:19:28] Jared: obviously the type safety you mentioned is important. Um, the Other thing that you mentioned was the, um, the ability to work as a team. Could you elaborate on that a little bit more?

[00:19:40] Erik: Yeah, I think it kind of comes down to that domain modeling, um, it's just to help represent this, it's easier to make it really correct, um, which then helps provide the documentation for other people coming in, and there's fewer questions, right? If you've eliminated some Impossible states, no one has to wonder, Hey, what do we do in these situations?

[00:20:03] Um, I also really like that it kind of forced you to handle every case, Kind of literally in a case, um, where, yeah, just like, What happens if there's an error, right? Especially when you're doing web development. The server might disappear for a second, um, and we need to handle that. And so I, I love that Elm really forced everyone to, to think through that and operate so, uh, our software probably does a lot better job than, than most of just showing error states because you end up having to think about it. So, I always really liked that too.

[00:20:33] Jared: Okay. Yeah. So with the data modeling, then you are able to be exact in what the. So, data represents, right? Instead of using a boolean, you can use a custom type and it can be oddly shaped. So maybe, you know, there are two states where something's on or off, but maybe there's an ambiguous state where modeling it in a different language, you might have to use multiple fields and then you'd have to read through the logic to understand how those things relate together.

[00:21:05] But with Elm, you can model that in such a way that, yeah, it makes impossible states impossible and you can combine those things and read it, and like you mentioned, it's self documenting in that regard, right?

[00:21:19] Erik: Yeah, exactly.

[00:21:20] Jared: What other options were you considering at that time? Or were you, pretty much by the time you got there, knew that Elm was the option, or did you have something else in mind?

[00:21:31] Erik: Pretty much knew Elm was the option. Yeah, as I said, I was looking for a place where I could bring Elm to it. Um, if it, for some reason, wasn't going to be Elm, then, yeah, you just fall back to JavaScript. I'm pretty sure React was plenty popular at that point. Um, I probably would have, I didn't know it. I haven't used it.

[00:21:49] So, but I probably would have looked into it because people kept saying it was very similar to Elm, so I would have gone for the closest thing I could find.

[00:21:57] Hiring & onboarding practices

[00:21:57] Jared: To elaborate a little bit more on this discussion of the ability to bring in folks who are already interested in Elm, this, uh, I believe the, the article from Paul Graham, you mentioned, and kind of getting that expertise coming in, you know, I have heard a few folks mention that, but I've also heard this other argument that it's, it's difficult to find people to hire.

[00:22:26] What, have you had any of that where it was like, oh, there's not enough people and we need to hire more. And maybe you could elaborate a little bit too in this as well about how many engineers there are at Corvus and that whole process.

[00:22:41] Erik: We have about, I think it's 54 engineers on the team, uh, many of them did come in with zero experience in Elm or Elixir or any functional language, uh, and we knew that was going to happen, so we, we built a very intentional training and onboarding program, uh, for folks like that who need to get that exposure and they need to get it really rapidly, uh, we do Especially in your first few weeks here, lots and lots of pairing.

[00:23:07] I think we have a really great code review culture to try to help people understand when they could do things a little bit differently. Kind of going back to that, how do you model something? I know that's a question people ask in code reviews and that kind of thing, to like to think through that. So yeah, we just try very hard to teach people.

[00:23:25] We make it very clear up front. If you don't have experience in either of those languages, that's totally fine. We will definitely still accept you if we think you're a great engineer. But yeah, we'll just take the time to teach you. So yeah, you do both. It's certainly a double edged sword if you only hire people with that experience.

[00:23:44] So we made sure to keep it open.

[00:23:47] Jared: Right. So you had the flexibility knowing that you could hire someone if they did have experience and know that they're really going to be invested. Or you could hire someone who is willing to learn and know that you have a system set up that will be able to train them and onboard them in a nice way.

[00:24:07] Okay, cool.

[00:24:09] Scaling

[00:24:09] Jared: And this actually brings me to another question from Andrew Lenards, quote, Are there any things that surprise you about Elm when you scale it from a small team to a large team?

[00:24:21] Erik: I am very impressed with how well it has scaled. Now, I know 54 engineers is not a big team compared to the rest of the world, but I think it's done a pretty good job. Elm, or at least the The way we have architected it, and I think this is a common pattern of the way you make each page, effectively each page model is its own type, and you have a lot of separation between the pages.

[00:24:48] And when you have multiple teams working on it, they're usually working in different areas of that code and different pages and things like that. And so, I think there's very little overlap and conflicts in those ways. So, definitely been impressed with how well it's scaled. The one thing I would like to be a little bit different, if I could just wave a magic wand, is the compiler speed, just to be a lot faster.

[00:25:12] Um, and, I think that's the area where I would say there's the least amount of scale right now. Whereas, when you're doing development and you have the incremental compilation, that's plenty fast, that does a good job, but when people are, you know, building and trying to push to staging on a regular basis and that's doing clean builds and each one of those takes a long time, we've I don't actually know what our number of lines of code is, but it's certainly a lot and it slows down those things, so if we could figure out a way to make that a lot faster, that'd be pretty exciting though.

[00:25:42] And help us continue to scale for quite a while.

[00:25:45] Jared: Right. Okay. So it's that cold compile time that, that is really the thing. Okay. Yeah. I'd be curious if, if you, um, could get that, the number of lines of code to see how that, um, you know, how that ties into it. Obviously, I'm sure it's a lot with that many engineers. That, that team size, so you know, how many did you say again?

[00:26:09] Erik: I think 54 is the correct count.

[00:26:11] Jared: So yeah, over 50 engineers. Are they all writing Elm? Are they full stack?

[00:26:16] Erik: Uh, yeah, that's a good caveat. Um, not everyone is writing Elm, certainly not every day. Um, that does include our machine learning engineers and our DevOps engineers who, uh, have probably written maybe three lines of Elm between all of them, but, uh, yeah. So, total Elm, I suppose, is a bit lower, but yeah, still a, still a good number and I think it's worked pretty well.

[00:26:39] Jared: One thing you mentioned was, you know, obviously if you have multiple pages, you can have separate models and no conflicts there. Another thing that I find is the attention to detail in the formatting of Elm code.

[00:26:52] So Elm format will automatically do that for you, but it's very vertically oriented. So, you know, you add something on a new line, it'll bring all those arguments onto separate lines. Um, and so you can get a go a long way with that too. If you're making a small change in one file, even if someone else is making a change in that file, doesn't, there's less likely for there to be a conflict in that regard as well.

[00:27:20] Erik: Yeah, absolutely. And yeah, as you mentioned, even just Elm format is a tool to help scale. You just eliminate questions and comments in PR reviews about how these things should look, and I think that is a big part of scaling, and you can just move faster because this thing just answers it for you, and people don't need to argue.

[00:27:39] Jared: Yeah, yeah, that's a good point, as opposed to other configuration tools or formatting tools that have a lot of configuration, right? Yeah. Okay.

[00:27:49] Static Elm + dynamic Elixir

[00:27:49] Jared: So, you use Elixir on the backend at Corvus, correct?

[00:27:54] Erik: Yes.

[00:27:55] Jared: So, one question I have is, how does the static nature of Elm plus the dynamic nature of Elixir work together at Corvus?

[00:28:05] Erik: With, uh, HTTP boundary, um, I, I think it works, it works really well, uh, I am in the camp of I would love to have types in Elixir, you know, if you see my language Erie, uh, it's effectively what I'm trying to do, um, I know there's a lot of excitement on our team about types in Elixir actually coming from the Elixir team, uh, I think there are plenty of people who like not being restricted by it, um, Elixir is very dynamic the way it uses maps and things like that, it's, it's It's used to being dynamic and you can, you can tell, uh, but I, I do think we're very much looking forward to having some types on the Elixir side and what that will enable, again, just those, those same scaling things that it helps with on Elm, um, modeling things properly, just eliminating impossible states, uh, I think would, would go a really long ways, um, we do currently use the, the spec, uh, not sure what the right thing to call that is, but using specs in Elixir, which is type checking to a degree, certainly not quite like Elm does, but it does it in a helpful way still and can help you spot some errors ahead of time.

[00:29:12] So, yeah, if we can make that a little more official, like real types, we're looking forward to that.

[00:29:17] Jared: Okay. Yeah. I have heard a little bit of the talk of gradual typing there and providing that from the creator of Elixir, José Valim. Um, yeah, so you would prefer to have that, but you still picked Elixir for some reason. You mentioned the BEAM. Is that tie into it? Do you want to kind of talk a little bit about how that part of the The process affects your work at Corvus.

[00:29:48] Erik: Yeah, the, uh, the BEAM, also known as OTP, also known as Erlang, um, is, is just, uh, amazing, uh, the, what that allows you to do with Elixir really, really quickly, uh, this is a, a conference talk that I've always dreamed of giving, but I've never actually put the effort into, uh, but how quickly you can write some tools that you might otherwise go fetch a package for, or buy another tool for, but just things like, how would you run a cron job, right, or a nightly job, um, in a lot of other technologies, and, um, it, I think it's a lot more complicated than it is on the BEAM, the way the processes work, and how easy it is to do that, uh, uh, excuse me, across a cluster, um, a global cluster, you know, anything like that, it's, it's actually pretty simple to put together, so, I think BEAM just enables that, the process architecture, all of that, so. Anyways, yeah, I'm very excited by it, and yeah, this again kind of comes back to why getting types on Elixir would be so exciting, it just combines the best of the Elm world with the best of the BEAM world for us.

[00:30:57] Jared: Okay, so yeah, this kind of makes me think of this whole batteries included idea and how Elm solves that in a way because of the cohesiveness of everything, right? There's the one Elm architecture, there's the tooling, there's the type system and the package manager and it's all one thing. Right. Like you, you get it all.

[00:31:20] You don't have to make decisions, you know, kind of going back to what we were talking about with Elm format, you get all of those things. You just do it that way. Right. Um, and, and it seems like that's kind of what you have with Elixir as well. And in fact, you mentioned, you know, something you might go out and build a package or find a package for instead of building yourself.

[00:31:42] Also reminds me of what we do often in Elm is instead of pulling in You know, some extra package, maybe extra. Oftentimes people will write that function themselves because you get a lot of benefits where, another example is the HTTP Helper, I'm trying to think of the name of it, by Luke Westby. There's also this idea of, you know, building your own API, which we've done.

[00:32:09] So I think, you know, there's this idea that, you know, it's really not that difficult when you have these certain restrictions, these certain limits that you've imposed on yourself. They provide you with a nice set of tools for building things yourself without having to go rely on something external.

[00:32:28] Erik: Yeah, exactly, and I really think a lot of that is just the functional nature of the languages, in that, If you are in the object oriented world, when people are building those packages, you just have to, you know, really subscribe to their API and working with that, and, you know, it hides so much of the state and everything, rather than just being a I give you an input, you give me an output, and I work with that.

[00:32:54] Um, so, yeah, when you start thinking about how to manipulate a string, or, you know, these other kind of simple utility functions, you just look at it and say, well, that's easy for me to just write myself. I don't need to go pull in this bigger thing that makes it all way more complex than it needs to be.

[00:33:09] Jared: You mentioned one of the things that, about Elm that you might wish to change, but kind of expanding on that, there's a couple questions here, one from Andrew Lenards and another from Justin Holzmann, but they all kind of lie around this idea of if there was something that you could change about the tooling or about Elm itself.

[00:33:33] What would that be and why?

[00:33:35] Erik: I have long said, so a question people always ask is, why did you choose Elm? And I often talk to them about, you know, if Elm never got updated again, I don't think I would care. I think it just is in such a great place. It doesn't mean there aren't any little quirks or things, um, but for the most part I think the way it works just is really, really good.

[00:33:59] Um, the compiler speed is the only thing that I wish, uh, was better. And I, you know, whenever the next update comes out I hope that is a focus. Um, for now we are getting by. Fine with it. Um, I wouldn't say getting by great, um, but also certainly not poorly by any means. Um, so, yeah, I really look at it just, I think it works really well as is.

[00:34:24] Um, so, I'm, I'm not too, it's maybe an unsatisfying answer that I don't have anything else. I just want it to compile faster.

[00:34:32] Jared:

[00:34:32] Programming the plane

[00:34:32] Jared: We've talked a lot about your kind of history and kind of getting up to, um, to introducing Elm at Corvus here and some of the scaling things that you've encountered and kind of I guess to throw a random wrench into the mix here, I hear you have a pilot's license, so how often do you fly?

[00:34:55] Erik: I try to fly at least a couple of times a month. Um, My wife and I like to take it for, uh, I'll call it family, it's just the two of us and our dogs, but family trips, uh, to, to see our own families, or to, uh, just go someplace interesting, and, uh, yeah, it's pretty great. It makes the world just a, a little bit smaller.

[00:35:15] Jared: Wow, yeah. So, you fly a small plane then?

[00:35:21] Erik: Exactly, it's a, a moony for, uh, any other pilots out there, um, but yeah, just a little four place, uh, propeller driven, uh, plane.

[00:35:31] Jared: Okay. Cool, yeah, well, I only have experience in that by, through my former employer who had planes and so when we would go on trips we were in healthcare and we'd fly out to different hospitals and so I'd get on the plane with him and it was a little, yeah, dual engine prop plane there but, um, yeah, I imagine that that would be fun, you're mainly doing it for pleasure, right, not for work.

[00:36:01] Yeah. Okay.

[00:36:03] Erik: I think a lot of engineers, uh, would like flying if, if anyone out there wants to, to go do their discovery ride and, and try it out. Uh, especially as you, you advance in it, you're kind of programming the plane at a certain point. Um, as you, uh, I just got my instrument rating, um, after. Uh, I've had my license for probably 15 years, and it took me a while to work my way towards this.

[00:36:25] Uh, but at a certain point, yeah, you're, you're following some rules, and you're programming in the plane, and you're trying to make all these things work together, and, uh, it's, it's really a lot of fun. It's very challenging, but, uh, a lot of fun and rewarding.

[00:36:37] Jared: Cool. Yeah. I like that kind of programming the plane. That's interesting way of looking at it. And maybe if you don't mind to explain what the instrument flight is, how that works.

[00:36:47] Erik: Right, when you first get your license, you are allowed to fly day and night, but not in bad weather. Or, basically, you're not allowed to fly in clouds. Uh, when you are in a cloud, you cannot tell which direction you are pointed, um, you can very quickly get yourself in a, a lot of trouble. So, the instrument rating is teaching you how to trust the instruments in the plane.

[00:37:08] And so those are the ones that are telling you which direction are you pointing and how fast are you going. And basically, are you being safe right now? Um, so, yeah, it's a, it's many, many hours of training to, to get to that point. Uh, but yeah, like I said, very rewarding and, and it also expands your ability to, to go places.

[00:37:24] If there's clouds there, a lot of people can't fly in. So, now I can.

[00:37:27] Jared: I mentioned at the beginning that Corvus is going through this acquisition by Travelers.

[00:37:33] I have a question from Kanishka Azimi via Andrew Lenards. You've gone from seed funding to publicly announced acquisition. Would you recommend Elm to a team? What if the team didn't have an active champion for it? End quote.

[00:37:50] Erik: I would recommend Elm pretty strongly. If you asked me a couple of years ago, I think I would have said absolutely 100%. Um, there are some interesting things coming out and, um, uh, definitely like Elixir LiveView, which is, uh, fairly close to, I would say, like a direct competitor for Elm. Um, they're, they're very different.

[00:38:10] Um, but it's just another way to do user interfaces anyway. Um, And so for Kanishka's question, um, I guess, yeah, I would still recommend Elm. I'm still very happy with us using Elm at Corvus. Um, if there is not an internal champion, Then I think things won't go as well. Uh, I think it, it helped at Corvus that the, that I was at least the internal champion for a little while.

[00:38:36] And now many other people have picked that up and, and ran with it. Um, and so yeah, I, I think that continues to mean Elm will have success at Corvus. So yeah, if you, if you don't have that person, I think it's going to be difficult because it is something new. It's the, it's not the status quo. So, uh, a lot of people take a lot of pushing to, to get through those things.

[00:38:58] Corvus engineering culture

[00:38:58] Jared: Sure. Yeah, maybe you could elaborate a little bit on your role as the champion. What some of the things that you, did, some of the processes you put in place or things that you overcame, how you went about making sure that Elm could grow at Corvus.

[00:39:17] Erik: We did a couple of things. So I mentioned the training and onboarding and how important that is and, and that's really just from looking around and hiring people and saying, well, we, we messed up. I'll say I messed up. Um, I didn't help you succeed here in your first few months and you eventually picked it up and got used to it.

[00:39:35] That was great for you, but I should have done more to help you get there. So trying to make a more systematic solution to that as we were growing really rapidly. Um. What can we do? So let's put this training in place, and what does that mean, and how often should we do this? And, um, so, spending a lot of time on that, just helping get people onboarded.

[00:39:55] But then also knowing that people are going to forget 90 percent of what you tell them during onboarding. What is this kind of continuing education thing we could do? So, at Corvus we do something called the Corvus Developers Conference. It's a Probably about every two weeks, um, one of the engineers on the team just hosts a, a talk, uh, and can talk really about anything.

[00:40:14] It doesn't need to be Elm specifically, but I think early on we, we did lots of that on, here's how I did this neat thing in Elm, in our current code base, or here's this neat thing that Elm does that we don't use, but maybe we should think about, and just trying to expand everybody's knowledge on what's possible and what we do and, and share those.

[00:40:32] And really just finding anything we can share, right? If somebody puts up a pull request that does something interesting, trying to share that around to more people and get them to go look at it and understand it and know why we're doing that. I think by just continuing to show it off all the time. You, you do a pretty good job being the champion and getting people excited about it and willing to continue to invest in it.

[00:40:56] Jared: Yeah, that makes a lot of sense. This reminds me, this Corvus Developer Conference, of something we do at Logistically called Technical Topics where yeah, we kind of go on a, a round robin of developers presenting on whatever thing they're interested in and of course, mine ultimately end up being somehow related to Elm.

[00:41:18] So, yeah, that, that I think, of course, you can champion a technology in that way, but I think it also does so much for the team culture because you're creating consistent learning, right? Like you said, folks come on and they have some set of knowledge and then you're trying to give them more knowledge, but that you can't feed all of that in at one time, right?

[00:41:43] A lot of things get missed simply because of information overload. So I think by creating that culture, you're, you're saying we're all trying to improve here. We're all trying to get better and it happens forever, right? It doesn't just stop after six weeks or whatever the, you know, the process of onboarding is and learning.

[00:42:05] So, yeah,

[00:42:07] Erik: yeah, exactly. Yeah. Just trying to always just even sharing an article you read on Hacker News or something, I think it's great to just keep that going.

[00:42:15]

[00:42:15] Jared: Corvus was listed as number two in Forbes America's Best Startup Employers. In your mind, why do you think that's so?

[00:42:25] Erik: I'll speak for the engineering team specifically, and I think it's, it's so many of the things we've, we've talked about in the, the culture of learning, I just absolutely love, uh, I love our, our code review culture, and, and people are, are very intentional to, uh, we all know how writing text on the internet is and how it's, uh, nuanced, but the text loses all of that, and I think our, our team does a really fantastic job of taking that into account and trying really hard to write constructive criticism but doing it in a way that is, is very acceptable and palatable to people, um, and, and we know when it's time to jump on a call and to, to talk through these and I think there's, there's a lot of trust, um, on the engineering team, especially I think across the whole company, but definitely on the engineering team, uh, that, that really makes a big difference there and helps us all get better together and so I think we just we're all really happy to to be on that journey together And I think when I get to talk on podcasts and try to brag about it. I think other people Hopefully hear that and yeah, I'm always excited to talk Corvus engineering because I'm I'm I'm super proud of it, to be totally candid.

[00:43:36] I like to think I've had a big influence on it, and it's a major achievement in my career to have so many people who have been there for such a long time and who have really seemed to enjoy it and know that I'm open to the feedback on things that aren't going well and I want to change those and try to make sure that the engineering team is the best it can be.

[00:43:56] Jared: Excellent. Yeah. And I agree.

[00:43:59] Acquisition

[00:43:59] Jared: I think you do have a lot to be proud of because you were the first engineer. You introduced the technologies. You've grown now. You're going through this acquisition. Do you want to kind of talk about the numbers there? Because I think that's a pretty substantial thing.

[00:44:17] Erik: Yeah, and so I will, I will clarify, uh, we, there has been an agreement to do an acquisition, it hasn't closed yet, um, that should be coming here, uh, in the next couple of months, so, that's when it will be totally, totally official, um, but in the meantime, yeah, uh, Travelers, uh, is the acquiring company, they published the number on their website during it, it's a 435 million dollar acquisition, and yeah, I think everyone here is, is super proud of it, um, the, The cyber insurance landscape is a very dynamic place and we think we've done a lot and are really proud of what we've done as a company and we think somebody like Travelers can really just help us scale and grow significantly more quickly than we were able to independently.

[00:45:00] Jared: I have a, just a couple more questions here. One from Mike Thiems via Andrew Lenards . You've mentioned some of the things that you would like to change or the, the one thing, I guess, that you would like to improve about Elm. But this question is, quote, What are your thoughts on the future of Elm? End quote.

[00:45:23] Erik: I hope it keeps going. Um, I know a lot of folks can express some nervousness around it. This is where I always try to back it up of if nothing else changes, I'm totally happy. I love Elm. It can just stay like this. Um, Evan tends to be pretty quiet, um, I'm also not out there looking as much as I know a lot of other people are, so, um, from my perspective is the only way I can see this, but he tends to be pretty quiet, and then kind of comes out with a big bang release, um, I, I hope that keeps happening.

[00:45:52] It has been very quiet for the last couple of years, so I hope he and anyone else contributing, um, are also very invested in the future of Elm and would like to see its continued use through companies and its, its growth, so, um, I'm, uh, I'm cautiously optimistic, um, but again, just for anyone on my team who's listening or anyone out there who's thinking about Elm, there doesn't need to be any more updates.

[00:46:16] It is, it's really great. I, I would continue to use it. I would start new projects with it. I think it's fantastic.

[00:46:23] Jared: Yeah, I see what you're saying. The core Elm compiler and the language itself is done enough that the community and the ecosystem around it, I think, can continue indefinitely without any major changes. I mean, really, to me, I haven't found anything that, even a minor thing, that I've needed to work around in years. Uh, so, and, and we write, you know, code every day. At least I write Elm code at, at work every day, pretty much. So, yeah, I think, uh, I think you're right, you know, that, um, it would be great. I think that those releases create excitement, But as far as just getting things done, doing what you need to do

[00:47:16] using Elm for building web applications, to me, I can't think of a better tool. And so, yeah, I think that the, from that perspective, you know, the future is bright. Um, and then I guess before we get to picks, the last question I have is, what are you excited about?

[00:47:36] Erik: As of right now, this, uh, upcoming acquisition for Corvus is, uh, just the most exciting thing we're, we're going through right now. We know, uh, In so many ways, it's going to mean zero change, and in so many ways, it's going to mean everything has changed. So, we'll just kind of get to see what that really means after it closes, and after we kind of get into it for a while.

[00:47:57] So, that's what's top of mind, and I think Elm's got a great future at Corvus. I think Elixir's got a great future at Corvus. I think the stack that we use is really good for us, and yeah, just excited to keep building and expanding what we've done so far.

[00:48:14] Jared: It's obviously been very good so far to you. You know, obviously you've been able to grow and expand. With Elm and the team size, and now looking at this agreement to acquire. Yeah, it sounds like it's been a good experience.

[00:48:34] Picks

[00:48:34] Jared: What picks do you have for us today, Erik?

[00:48:37] Erik: The first one is an article called Interesting Bugs Caught by No Constant Binary Expression. Um, it's a, a feature in ESLint, um, which I don't use, um, because we use Elm, uh, but I just found it super fascinating to see the different kinds of bugs that this, uh, review feature can find, and One, it's interesting because we don't have these issues in Elm, so it's not an issue for us, we don't have to worry about it.

[00:49:04] Uh, but I do think it really just shows off the power of what effectively kind of static checking can do, whether it's static type checking or other types of checking. But, um, this person writes an article about the bugs they're finding, I think, in like Facebook's code base, or React code base, or these things.

[00:49:20] Um, and just how You know, what Elm saves us from, so I just think that's, uh, pretty great, and I, I like to see it in other languages and other people catch on to what, uh, Static Analysis can do for you. The, uh, the next one is a, a YouTube video called Training AI to Play Pokemon with Reinforcement Learning.

[00:49:39] Um, I just, I find anything like that fascinating. One just Pokemon is super nostalgic. I still have that, uh, that in the Game Boy somewhere in my closet, like that cartridge, uh, in there somewhere, and, um, yeah, just spent so many hours on it, so, uh, one, it's just that, but then two, actually seeing somebody do a really great job describing what reinforcement learning is and how to use it, and you can see the impact of it right away, of how it kind of learns to play this, um, not very simple game. It's kind of simple in the terms of there's only a few inputs, but it's, it's a long game and complicated. And so just getting to see how you manage rewards and what that does for it. So, um, really enjoyed that. Super easy to understand video. Highly recommend. And then the last thing is just something that's been on my mind for a while.

[00:50:26] It's called, it's a book called The Data Warehouse Toolkit. Um, if you've ever wondered when people say a data lake, or a data warehouse, or a data lake house, or these kinds of things, um, what are they actually talking about in real practical terms? Um, even just the first chapter of this book does such a fantastic job describing Data architecture and what it's useful for.

[00:50:49] And then there's a bunch of chapters after that that really go into different use cases. Um, so, I just have really enjoyed learning that, reading through it, and really trying to understand what does an enterprise level data warehouse look like, and, uh, yeah, what can that be used for, so. Yeah, those are mine.

[00:51:07] Like I said, uh, all over the map, um, but all things on my mind right now. And, uh, yeah, just, I think, very cool, fun to learn things.

[00:51:15] Jared: Yeah, those are cool. And I don't have any picks myself, but just to kind of comment on a couple of yours, the first one about the ESLint rule. I think that, yeah, of course, it goes one to, like you said, the, the problems that we don't have to think about in Elm. But then it also makes me think about a lot of the work that Jeroen Engels has done with elm-review and with championing the idea of that static analysis tool, having a higher standard, I guess if you will, in the types of rules that are made and what the expectations of what those rules and what the tools should allow or not allow and how it goes about handling exceptions and things like that. So I guess if, if we're to turn this.

[00:52:03] My blabbering about your recommendation or your pick into a pick, it would be Elm Review because Elm Review, I think, for Elm, does a great job of static analysis and, you know, it's kind of like a superpower for the Elm compiler, which is already amazing, so I think that they go really well together. And then, to comment on the one about the Pokémon training, I watched part of that, I didn't get to finish it yet, but I'm excited to, because what I watched, it really got into human nature, not just the nature of AI, and you know, it's talking about this, how watching the animation of a lake is more rewarding than going out and exploring the rest of the world.

[00:52:52] And it kind of links this to Twitter and Instagram and Facebook. And, yeah, I thought it was just pretty deep for such a, you know, such a narrow scope. But it seems like it wouldn't be related to that. So, yeah, really good pick there. Um, and Yeah, thanks to all the folks who are listening out there. Please rate and share if you're enjoying the show, and thanks, Erik, for coming to Elm Town.

[00:53:19] Erik: Thanks, Jared, and thank you to Andy, Luke, Kanishka, Justin, Mike, anyone else who asked a question. I appreciate it.

[00:53:27] Jared: Yeah, I'm going to put Andrew Lenards as a producer on this episode as well, and thanks to all the folks who brought questions through and yeah, it made it a really fun interview.

[00:53:38] Thanks, Erik.

[00:53:39] Erik: Okay, thank you.

[00:53:39]