The Changelog: Software Development, Open Source - Elm and Functional Programming (Interview)

Episode Date: September 2, 2016

Evan Czaplicki, creator of Elm, and Richard Feldman of NoRedInk joined the show to talk deeper about Elm, the pains of CSS it solves, scaling the Elm architecture, reusable components, and more.

I'm Evan Ciaplicki. And I'm Richard Feldman. You're listening to The Change Log. Welcome back, everyone. This is The Change Log, and I'm your host, Adam Stachowiak. This is episode 218. And today, Jared and I are talking to Evan Ciaplicki and Richard Feldman. Evan is the creator of Elm, the best functional programming language in your browser. We have three sponsors, Rollbar, TopTile,

and DataLayer, a conference put on by Compose. First sponsor of the show is our friends at Rollbar. Rollbar puts errors in their place. Head to rollbar.com slash changelog, get the bootstrap plan for free for 90 days. And today I'm sharing a conversation with you that I had with Paul Bigger, the founder of CircleCI. And he talked deeply about how they use Rollbar and how important that tool is to their developers.

Take a listen. One of the key parts about doing continuous delivery, you don't just have to test your software, but you have to constantly keep track of it. You're going to be doing deploys 10 times a day or 20 times a day. And you have to know that each deploy works. And the way to do that is to have really good monitoring. And Rollbar is literally the thing that you need to do that monitoring. You need to make sure that every time you deploy, you're going to get an alert if something goes wrong. And that's exactly what Rollbar does for CircleCI. So obviously CircleCI is important to your customers. You shouldn't have errors, you shouldn't have bugs. And the purpose of a CI is continuous delivery, obviously, but getting your customers code to production in a fast manner that's tested and all the necessary

things a CI provides. Tell me how important Rollbar is to your team and your organization. We operate at serious scale. And literally the first thing we do when we create a new service is we install Rollbar in it. We need to have that visibility. And without that visibility, it would be impossible to run at the scale we do. And certainly with the number of people that we have, we're a relatively small team operating a major service. And without the visibility that Rollbar gives us into our exceptions, it just wouldn't be possible. Oh, that's awesome.

Thanks, Paul. I appreciate your time. So listeners, we have a special offer for you. Go to rollbar.com slash changelog. Sign up. Get the bootstrap plan for free for 90 days. That's 300,000 errors tracked totally for free.

Give Rollbar a try today. Head over to rollbar.com slash changelog. Now we're back. We've got a fun show, Jared. This is a, I think Richard's got an alarm set or something like that. We've got Evan Ciaplicki and Richard Feldman. We're going to introduce you in just a second.

But this is a catch-up show. Six months ago, back in January, we had Richard on talking about Elm. Got really excited about it. And a lot of people love that show. We actually got asked recently, like, another Elm show so quickly. So what's going on here? Yeah, like you said, I think Richard just said a reminder. I remember at the end of that show, we said, oh, we got to get you back on six months from now, a year from now.

Come back, bring Evan or not, and let's talk about Elm again. And then maybe six months to the day, Richard, that email came in. You're like, hey, it's six months. Let's do this. And it was that easy. I wish I could take credit for having that good a memory but uh yeah i said a reminder well uh it was that easy adam i want to take a second and just talk about some of our upcoming shows because i don't know have you looked have you looked at our schedule lately it's looking spectacular oh man i'm so excited about the

schedule it's it's rocking yeah so you so everybody who's been listening knows just recently we had both Electron and Sourcegraph on the show. Upcoming after this show, of course, Elm, huge topic. We have Cory Doctorow coming on. Eli Bixby, both of them will be at OSCON London, which we'll be at as well. Hilary Hartley and Aiden Feldman from 18F. Gavin Wood with Ethereum.

Sandy Metz. Come on, Sandy Metz. Right. Bertrand Leroy talking about.NET Core and a whole bunch more. So if you're listening and maybe you just came for the Elm, stop right now and hit that subscribe button because we got some good stuff coming down the pipeline. That's true. We do.

But let's talk with Evan and Richard. Guys, thanks so much for joining us and taking time to talk about Elm today. Thanks for having us. Yeah. Richard, like we said, we had you on the show back in January. That's episode 191. So people can go back and listen to that one as well to get your backstory. Evan, this is the first time that we've had you on the changelog. So we do like to find out a little bit about people's background. We find it's both interesting and can be inspiring to hear where people who are doing cool stuff in open source have come from. And so could you give us a little bit on your background in terms of maybe an origin

story, how you first got into programming or open source, or what can you tell us about where you're coming from? Sure. So I think in my sort of age group, there's a lot of people who got started with TI 83 as their first programming experience. But, you know, trying to you you learn pythagorean theorem in class and you're like i can solve that forever um but i really got into it in high school and was really intrigued by game so as soon as we could do basic java things on the command line i was like all right command line game and as soon as we learned how to draw a rectangle, I was like, how do we move this rectangle around with the keyboard? So really it was this sort of push towards something,

some sort of game I could show friends or family or whatever. And one thing that's been interesting as I've been working on Elm is sort of coming back to the same thing, except many years later. And it's better than my Java code, partly because I'm like a bunch of years older and made more experiences, but also because I made a language. So,

so like, I'll come back and be like, Oh, I did it again, except this time. And it's so much nicer. All I had to do was make a programming language. No one ever says that.

That's been one of the fun, like one of the early examples with Elm was you walk around as a RPG type character, and I actually used art from a project I did in high school. And so it's the same look. It's just, you know know just write a compiler and then it's uh it's way shorter to write the program that's hilarious but yeah so my interest has always been in sort of uh not necessarily games per se but in the joy of sharing something fun. So when I got into

language stuff, it was sort of with an eye towards what cool thing can I make for people? And to tie this in a little bit more, I had this experience at a place I was interning. I was interning at Google and I was a back-end focus. So writing C++, writing callbacks in C++, wondering why you would write callbacks in C++. But that project finished a bit early. So I had a bunch of weeks and ended up helping out on a front-end project. And I had this feeling that I was working on. In theory, I was in the best environment to have a good experience. And the kind of things that were difficult were just sort of comically bad. So I remember we wanted to put the logo in the middle of a box, both vertically and horizontally

in the middle. And at some point, we just were like, nah, maybe we don't want to do that. Yeah. Or we had a sidebar and the sidebar was going to be reused on all the pages. And so we were like, oh, how do we like reuse this code? And the answer was like, oh, there's not really a good solution for that.

You can maybe make an iframe or like we have this custom templating language internally and then you can and it just was like this is a 20 year old technology that's running the whole internet and like this is the ideal i don't know there were just these kind of problems that seemed so silly and that really stuck with me so sort of having a background in languages this ended up being a big motivation for how this project came to be and the root there isn't like oh i want to make a thing it was i specifically want to vertically center this picture and that desire kind of got out of control so

so so how long was it between i vertically want to center this picture and then you you have you dove deep into this creation of a language and architecture uh give us the time span in months perhaps before you had your thing that you could vertically center your picture probably the the initial story of being an intern that was about a year or two before I actually started working on Elm. Okay. Yeah, but before doing anything. So it sort of was just percolating in my mind as like, man, that was a terrible experience. But at the same time, I want to make cool stuff in that realm.

Right. And in the meantime, I'm learning more about compilers, writing parsers, these kinds of things. Building these skills, not in a directed way, but just in a way where by the time it comes around for me to do my senior thesis, these things all aligned to make a project I was really passionate about. I can definitely relate. Being a longtime web developer, you learn to just work around the craziness and the hard stuff because that's how you get your job done or that's how you accomplish your goals. And I had been doing it for so long that I kind of forgot how insane a lot of the CSS hacks that we have to do are. And until I started teaching people who are fresh to web development, teaching the basics of HTML and CSS. And you know, HTML in terms of like a market language is pretty straightforward and people are like,

Oh, that makes sense. You know, I wrap stuff in tags and I can give it attributes and put my content into it. And then you get to the CSS part and things like, yeah, I just want this to be lined up vertically or dead center in the,

in, in the middle of the page. And you have to teach somebody how to do that. And that's when you're like, like with fresh eyes, it's so ridiculous. And the box model really, uh, for the longest time was obviously still yet as well is like the bane of the existence of front-end web you know it's it's like teach somebody the box model you think they get it but it's still even then you're like that's the box model that's how it works and

all the browser of course to go with it and all the things you have to do to hack around it. You're right, Jared. Teaching someone brand new CSS is like, good luck. You really have to want to learn it. That's something I've sort of been worrying about is as Elm gets really nice for writing HTML and CSS, I worry that I'm losing that outsider perspective on those things. Because the initial dream was, what if there was a better way?

And it turns out that's a very hard problem. But I still feel like that's something we should be thinking about. And it's really easy to think about other things instead. Or fix things around it. I think if we look at the stack, though, like the front end stack, the thing that is the most, and man, I hope I don't get beat up by the CSS people out there. Cause I'm one of them too, but like, you have to admit that CSS is probably the, the, one of the most corkiest pieces of the front end, right?

Like it's, it's the hardest part. I, in my opinion, like learning CSS is like a dark art and getting, getting to mastery is, is almost unattainable. It takes at least 10 years of CSS to become a master, I would say. So I think I would agree that, I mean, absolutely, CSS is one of the hardest parts about web development. Possibly the hardest, honestly. But I think that what's tricky about it coming from the perspective of

using Elm is that with JavaScript, it's a pretty reasonable proposition to say, I want to take this part of my web app and pull it out and replace it with some Elm code and just sort of introduce Elm that way. It's pretty hard to do that with styles like css very much encourages having these global style sheets that are sort of everywhere and um unless you're already on some sort of inline style type bandwagon um you're gonna have trouble with that and even if you are on the inline style bandwagon usually like deeply nested styles um result in sort of like the hierarchy mattering and it's pretty hard to pull something out and say i'm just going to drop in this this new elm thing that's styled in its own way you know basically what i'm saying is even if evan said

hey elm now has a great way to do styles um so that you don't have to learn the box model and so forth um that still would be difficult from a how to introduce it perspective. Because one of the things we've learned is that the critical thing for people to start using element production is introduce it gradually. And I don't know how somebody would do that with styles just because of the way that CSS is designed. Yeah, absolutely. Let's backtrack just a little bit here, Richard. do that with styles just because of the way that css is designed yeah yeah absolutely let's let's

uh let's backtrack just a little bit here richard um because we're talking about elm and i want to talk about that in depth with regard to sprinkling it in because that's a new revelation to me as somebody who's interested in them but not quite ready to like dive into the pool so to speak because i didn't realize you could do that i know that you guys had a popular uh post this just recently this summer about how you can do that. And I know that you guys had a popular post this just recently, the summer, about how you can do that and ways about getting started in that. But first, let's, for those who didn't listen to 191 or just catching up, Richard, can you give us like the high level synopsis of what Elm is, Elm architecture, you know, the problems

that it solves? I know we're talking around them, but can you like lay it all out there for us? Sure. At least from my perspective as a web developer, I guess Evan's probably the best at talking about what Elm is since he made the whole thing. But at least from my perspective, I see Elm as, well, so first of all, literally what it is, it's a programming language that compiles to JavaScript. So you can use it alongside your JavaScript, which is how we use it at work, how I've used it on my side projects. And basically the problems that it's solving are maintainability, reliability, and sort of ease of use. So I feel like I have a better UX, like I have a nicer time with Elm than I did with JavaScript.

My error messages come to me earlier. So, like, the compiler finds errors before they can reach my end users, which I really appreciate, because I'm somebody who cares about user experience. And I don't want errors getting to my end users. I also really appreciate sort of the way that it's designed in terms of, like, how it feels to maintain an Elm code base. It feels really nice. It's very reliable, very easy to maintain. And I've just had a really pleasant sort of delightful experience around it. Statistics wise, at work, we're using it now. And we did introduce it gradually. We can talk about that in a bit, but basically,

so right now we're at 36,000 lines of production Elm code. We're hiring, by the way, that's no red ink. So if you want to use Elm, like we'll teach you, you don't have to know it coming in. And basically we use it for pretty much all of our new web development.

So at this point, JavaScript is pretty much just legacy. And like, if we want to use a third party library, you know, for pretty much all of our new web development. So at this point, JavaScript is pretty much just legacy. And if we want to use a third-party library, NPM is obviously a lot bigger than Elm package system. But other than that, we don't really reach for JavaScript at all anymore. It's just legacy code.

And quite frankly, when we have legacy code that's still in JavaScript, we rewrite it in Elm as soon as we get the excuse. Also, another statistic is that we've been running it in production for a little over a year, and the total number of runtime exceptions we've gotten from our Elm code is zero still.

That's crazy. Yeah, so that might be the short version of what Elm is. Yeah. It's a short version, but it's kind of like, I've definitely used systems in the past where it's like the way that they achieved reliability was by pushing it all to the programmer. But I think it's important to note that Elm achieves reliability by making it really nice.

And sort of by telling you about problems early on, and telling you about them in a friendly way. Evan, anything to add? I think, you know, Richard mentioned, it's a language. It's also the Elm architecture. So it's very opinionated about how you should be building your web applications. Yeah. On the other side of the break, we'll talk about how it's recently gone through a big change with regards to functional reactive programming so maybe not that deep yet but just like what's the elm architecture and and give us a round out what you had to say right so when you're writing a program in elm you're gonna be using the elm architecture and it's it's sort of easy to think

of that as being opinionated but i think think in Elm, it's really about, that's just the way things come out. This is something we discovered as we observed people writing programs over the last couple of years. So there's only one way to do it, is that what you're saying? There's no like, this is the right way, but you could do it the wrong way.

There's only one way to do it. Yeah, so like if you think of alternatives, they all fall within the scope of the Elm architecture, which is sort of broadly defined to cover things that work in Elm. So alternatives often are like, well, what if we had mutable state in this component? And it's like, well, this language doesn't have mutable state. So that's not an option, right? Go somewhere else.

Yeah. Yeah. So a lot of the alternate architectures or differing opinions on architecture are really about, I want to have mutation or I want to use mutation or side effects in my architecture in various ways to sort of make my code look a certain way. And because of the nature of Elm, it sort of makes a lot of these choices for you. And the end result is really nice. A lot of the sneaky of Elm, it sort of makes a lot of these choices for you and the end result is really nice. A lot of the sneaky problems you'd have are often,

I have this thing over here, it touches this variable, that variable is touched by four other things. Now, is that up to date in all the other places? Now you have a bug. And so there are tons of strategies you can use to, okay, we'll make that reference reactive things so everyone will get notified. This ends up with issues around, okay, so who, which direction to the messages go in the end.

So you end up with some quite complicated stuff along these lines. And so in Elm, by sort of starting with the foundation of all values are immutable, the architecture falls out of that. So I think it might be interesting to see sort of what the discovery process looked like. So I noticed that my programs always were written a certain way. So one of the first bigger programs I wrote was actually a presentation about Elm in Elm. And I was hacking it together very close to the time I was going to be showing it. And I finally got it working and I went through to clean it up. And I was like, actually, this is like decently architected. That's weird.

And I had this experience a couple of times where I made a little Mario game for myself. And I was like, oh, this is fine. I wouldn't expect it to have come out that way. But then I was also like, well, but I made it so maybe I just have an intuition for it or something. So I went to what was at the time called Hacker School. And someone there, just in the course of a week, they made a little side-scrolling type game and asked me for a code review.

And I was like, this is good. Like, not in a... I don't think you would write good code, but just, like, after a week coming from no experience with functional programming or Elm or anything like that to write something that was well-architected, I was like, this is a little weird. And so that's sort of when I started noticing this pattern that we ended up calling the Elm architecture, this idea of you get messages in, you have an update function that updates the state of your application,

and then you have a view function that says, here's how I show that on screen. And that's just sort of how Elm programs come out if you use the language. Very interesting. Well, we are hitting up against our first break. On the other side, we're going to talk more about kind of this discovery process because it seems like you're still in it to a certain degree.

Just in May, I believe, Elm 0.17 came out with a big change to the way that Elm works. And so it seems like a dramatic simplification. So we'll ask you about that on the other side of this break. This message is for all those team leaders out there that are looking to easily add new developers and new designers to their team, easily scale up when you need to. You got a big push coming. You got a new area of the product you've got to go into. You've got more need than you thought you could. You've got to go through all this hassle of putting a job out there and hiring people to find the right people. Well, that's a bunch of hard stuff that you don't need to even deal with. Call upon my friends at TopTal.

That's T-O-P-T-A-L.com. The cool thing about TopTal is that you can hire the top 3% of freelance software developers and designers. And what that means is they've got a rigorous screening process to identify the best. So when you call upon them to help you place the right

kind of people into your team, then you know you're calling upon the best people out there. Once again, go to toptal.com. That's T-O-P-T-A-L.com. Or if you'd like a personal introduction, email me, adam at changelove.com. And now back to the show. All right, we are back with Evan and Richard catching up with Elm and what's happened since January. We like to say around here that open source moves fast and in the Elm language and community, that's more true than you would know because things are moving fast.

And, uh, back in May, you guys released Elm 0.17 in which Elm said goodbye to functional reactive programming, which is a term that's near and dear to a few hearts, but also a big and confusing perhaps to other hearts. So let's start with maybe a description of what FRP or functional reactive programming is,

why Elm was using it, and then why Elm is no longer using it. So that's a big question. So if you sort of trace the roots of the term to the academic literature, it means a very particular thing. And there's sort of disagreement within the academic literature about what the scope of that term should be so in the original conception it was about a continuous model of what's going on so it would have been really nice for animations or sort of 3d things where you could describe all your uh like the

physics of your situation with just the closed form physics solution or equation so you basically write down betonian physics and it like does the right thing that was the initial vision um so i came to this sort of independently i didn't know about this literature i came to this sort of independently. I didn't know about this literature. I came to it from the perspective of I have this library basically for making visuals, 2D layout. So I can put things in the middle of a box. Actually, the middle is very easy. You put it in the middle of a container. It works.

And at some point I was like, this is cool, but I'd like for it to move and interact and so I was coming from a functional background and I didn't want to just introduce all the kinds of mutation and side effects that are not in these languages that make them so nice so my question was how can I get interactivity without signing up for these kinds of ideas. So I had this idea, what if we had values that change over time? So what if, instead of saying, what's the mouse position right now, when you say mouse position, it is always the current mouse position. And anything that depends on that mouse position

is updated as appropriate. So that's kind of where the root idea came from and for a couple days i thought i invented this and i was like oh my gosh the whole world's gonna be different and my i told my mom about this and she was like you should see if there's any like related work or anything or yeah and it turns out i was i think like 13 or 14 years late on this one and if you really trace it back it's much a lot it's much older than that but um so it comes from this idea of how do we do things in a functional way without introducing all these imperative techniques that are typically used um that's the academic side of things the term came to mean we have interactivity and we have a map function.

So basically it's functional and it's reactive. So we're going to use this terminology. And so it means dramatically different things to different people. Now, in our case, it just meant updates come in and we handle them in a certain way. So what we noticed is people were sort of setting up the same programs, right? So I take these inputs, I merge them all together, I update my model, I send it out to my view. And so no matter what your program was, people were setting up the same network of signals is what we called them. Other people call them observables whatever um everyone was setting up that same system and so at some point i think richard did a lunch talk somewhere and everything was good but we sort of

yeah we see everything was good but we stumbled on the signals part just explaining it. So on the walk back to the office, we just were chatting. And I was like, I bet I can hide all of that with the library before you can get back to work. So I walked upstairs and did it. And he walked back to his office and I had it out there. So essentially, we found a way to create that signal graph, that basic setup that worked for, I want to say, 100% of programs. We didn't know that at the time. But we were like, 99% of the time,

this is going to be enough. That was called Startup. And everyone started using that. It was a much easier way to get people started. They just didn't have to think about a lot of concept. So at some point we realized this actually can cover everything that people need just flat out. It is generating this signal graph underneath,

but messing with that isn't actually a central complexity. So when 17 happened, we did take out a... Essentially, we took out an API that no longer was in use, and it felt very essential. But in reality, the underlying ideas behind Elm stayed the same, and the code that people were writing stayed the same. There just was this layer that sort of fell out of use that we just took out. So we have a simpler story and a simpler way of thinking about all these kinds of things.

Does that make sense? I hope that makes sense. Oh, it does. I mean, you have this new simpler thing that people use in Elm now called subscriptions, which I love that you, you think it, you know, would cover 99%,

but it turned out being a hundred percent. Well, we just had a gut feeling, you know? Yeah. Yeah. Yeah. Why not just,

you know, bat a thousand, I guess. Um, so this has actually been very dramatic for me because I've been teaching these workshops, um, in preparation for,

uh, I'm doing a two day front end master's course in September. And I've been doing these weekend workshops to prepare for it. And so I've been doing them both before and after this change. And the difference in how the workshops go has been extremely dramatic. Like the percentage of people who walk out just feeling like, Oh, this is awesome. And I get it,

um, has been very different. Like when I don't have to explain any signal stuff, it's like they're building the same programs. Fundamentally, they're organized the same way. They, I talk about them in the same kind of language.

Um, the difference is just that people get it more easily so it actually seems like um not only is it a simplification but it's also just uh presents a much nicer learning curve yeah and so part of the change is before and after this you really didn't have to know about signals but before it you felt like you did have to know about them and i think that's the important thing that it's easy to forget about is that the fact that something exists will inherently make you feel like you should know about it and so i've used many languages that are this way where there are concepts and terms that exist. And the fact that I don't get them yet makes me doubt what I already know. And so I also want to push back against the idea of Elm changing quickly.

I think it's true that we aren't afraid to make improvements. But I don't think they've been crazy if you think about the actual code that people are writing. So when 17 came out, I don't know if this is a, maybe Richard can give a better estimate, but I'd say the actual code that would have been invalidated or not work anymore is like 5% of code. It's not really a huge change. And I think I'm pretty deliberate about how can I improve things and make an important change without disrupting everyone's stuff.

Yeah, I mean, for us, the change from 16 to 17 is like largely a mechanical process. It's just kind of like this thing has a different name now. This thing needs to take one fewer argument because we don't need to pass as much stuff around. But actually, honestly, like the like the big thing that we had a lot of conversations about was like, how do we deal with merge conflicts?

Like just, you know, baseline programmer stuff like, you know, upgrade a large code base. And of course, as pretty much always turns out to be the answer, the answer turned out to be do it incrementally. Spoiler alert. Yeah. Conceptually, like, not a big change

if you're already using StartApp, which we were. So the, you know, on the practical side, if you were using signals you know that gets changed over to subscriptions and signals just is gone from the you don't have to worry about it anymore signals are gone and you don't have to worry about them anymore but actually subscriptions are also basically so when evan said and i'm this is my take on it but uh um basically there were certain things where before you needed to use signals and now you just don't need to use anything they're just they're just a

first class thing so for example um like an on click handler it used to be that uh you had to pass an extra argument to on click in order to make the wiring happen and now you don't you just on click just takes one fewer argument it's just one less thing to learn and it still works the same way yeah yeah that's i i generally characterize 17 is we learned how what it would look like to write good code um and then we just made elm accommodate that better. So it's not like anything was fundamentally changing in Elm architecture or we were just sort of taking the next step based on what we'd observed to what people wanted to do. So subscriptions are basically just almost all of the changes

were just taking stuff away. But the one case where they weren't was like, how do you respond to like a global event that's not scoped to a particular dom element so for example like a full screen change like if i change my browser full screen mode to not full screen mode it's like how do you listen to a global thing like that you know you can't put like an on click handler on that you don't have access to document directly so how do you do that subscriptions were like, oh, if we just introduce one new thing to cover that one particular set of cases, then you don't need signals for absolutely anything at all.

Well, and my alternate phrasing of that is that before you would use signals for that, and signals in some ways were sort of tough to weave into the basic Elm architecture that everyone wanted to write. And so it's not the fundamental mechanism changed. It's that the API around that sort of shifted to make it a lot easier to get those messages. Well, easier is always better, right? I think as a user of Elm or as a casual observer of Elm who's thinking about using Elm, anytime that you can simplify mental models or even the code that I have to write, I'm all for that.

Do you guys see any other, I don't want to call them big changes with regard to the way things work, but low-hanging fruit or aspects of Elm that are perhaps confusing now that you could find similar wins like you did with Signals? I don't see anything like that. I think Signals was the last real stumbling block. So one of the things Richard and I think a lot about is how can the learning curve for this

basically be as smooth as possible? And it's at a point now where I'm pretty happy with how it looks. I don't think there's any point where there's a huge jump where we're losing tons and tons of people. There might be blocks, but there's nothing that's close to what signals were like in terms of learning curve. I do think, honestly, I think the biggest changes that we have left are not language design changes, but rather communication changes. Like we're still figuring out the right way to present things such that people end up proceeding like with their exploration of the language and getting into it

in a way that leads them to a good outcome so this is a big a big thing that i've been seeing recently is so we use elm a lot at no reading we love it i mean we've been extremely happy with it and um we we've sort of ended up with i think think, honestly, by accident, sort of like doing what turns out to be the right thing in terms of how to scale an Elm application. And I think that I've talked to a lot of people, especially beginners who seem to not be as lucky as we are and seem to be starting off going down the wrong road. And I've really struggled to communicate how they should basically learn from our experience and end up in a happy place. But I can't claim to be really good at that yet. I'm still learning how to communicate that

effectively. Yeah. And we've had things like this in the past where we needed to introduce a particular concept that is just generally useful. And the language that was paired with it sort of by social accident or sort of historical for historical reasons was really confusing for people. And so there are examples where we spent just like a year or more thinking about what's the right terminology to pair with this idea such that the idea becomes easy, not change the idea in any way. And I think that's what the kind of thing we're working on now. Richard specifically is mentioning components. So a lot of people come to Elm from JavaScript

where components are really common concept. And thinking in that mindset often leads you to do odd things. The reason why is that one way to look at a component is as an object, right? So you have your local state, you have these publicly exposed methods. And if you came to Elm and said, I want to structure my whole application around object, everyone would say, oh, Elm doesn't do things in an object oriented way, you should reconsider. But if someone says oh i

want to structure everything in terms of components because it's a different term the the fundamental similarity between those two things doesn't trigger in anyone's mind so they're like oh okay let's see how we can make that happen um and i think that's led a lot of people to try to do object oriented patterns in a functional language which is just inherently like if you use the right terminology it's easy to see when you're making that mistake right yeah so so basically when i tell people about like certain characteristics of our code base, they're just very surprised and kind of disbelieving. So like I say, we have no runtime exceptions, and people are disbelieving because that sounds like too awesome to be true. But then I tell somebody like, we have a page, this is our assignment form. It's incredibly complicated. It's like every time we add a new feature for

our teachers, like a new type of quiz they can do, we have to modify that thing. So this is our most heavily maintained page. Before we started using Elm, it was in React. And it was really difficult to maintain. Like tons of nested components, like React components, like following best practices to the best of our ability. Today, we wrote in Elm, and we've had to maintain it a lot

since then. Now it's not scary. We're just not afraid of it anymore. And people are like, okay, cool. So how is that organized? I'm like, really, really flat. We have a model that's just a record with 55 fields in it. I counted yesterday. That's what it is right now and then we have a message and that message has 40 different possibilities in it and you say numbers like that and someone's like obviously you need to split that up like you're doing something wrong right no no no like distributing state makes stuff harder to maintain it just does like distributed systems are not legendary for having good ux actually they have the exact opposite reputation right so the like but the thing is like react is designed to do that like

that's that's how you're supposed to do things in react if you look at like react's home page they don't say your first render they say your first component right the word component i actually i did this search too if you you search like command F for component in the React docs, you get 10 hits just in the sidebar, right? If you command F for component, like you bring up the Elm guide and do that same thing, you get zero hits because it just doesn't make sense in Elm.

It's just the wrong way to go about doing things. And so like I can know from personal experience that um you know we've had incredibly great success making things maintainable and scaling things like even the hardest parts of our app by just not doing that but yet people just have this this reflex um that that they feel like they need to do it like if they don't do it they're doing something wrong because in object-oriented programming that's what you they need to do it. Like if they don't do it, they're doing something wrong because in object-oriented programming, that's what you're supposed to do. But it's not true in Elm.

I actually had a personal experience where I did this to myself. So DreamWriter is this application that I built. It was my first intro to Elm. And if you look at my contribution graph over time, it's like really, really high i was just just going nuts with it and just having an amazing time building it um for a very long time until i got the idea into my head that i needed to reorganize it in terms of quote-unquote components where each like the sidebar had its own state and the notes had its own state and like basically

introduced distributed state and if you look at my contribution graph, and I did look at it recently because I was curious about this, basically it just takes a nosedive after I did this because I just made my own code base no longer joyful to maintain. I just made it a lot worse by componentizing everything. Well, so, and I want to emphasize something here, which is not that modularity is a bad idea. It's just that modularity looks very different in an object-oriented language that doesn't have types versus a functional language that has a module system and a type system that provides certain affordances to you that let you write code in different ways.

So Richard is not at all saying, like, don't care about code quality. It's just that doing something nice looks quite different in these languages. Yes, that's it exactly. Well, so what does modularity, I mean, because it does, like, it sounds, like, the end results sound amazing but what

you just described there sounds like a in certain ways a big ball of mud it's like i got 40 fields and you know 55 uh i can't remember what the 55 was on but lots of stuff in one place um what does modularity look like then in elm and in a functional type language? So to me, the metaphor that makes more sense is databases. So let's say you have like one database, right? And it's got a bunch of tables inside, it's got a bunch of rows. And then you're like, okay, I have this one database. And that's cool. But what I really want is I really want like 20 databases, and I'm going to have them all talk to each other. Like if you've worked with databases before, you know, that's not going to be better. That's actually going to be much, much worse.

Like it's actually going to be a way better experience maintaining that system. If you just have one database or worse, you know, two is worse than one, but like whatever, even though that means that one database is going to have more stuff in it, right? So it's kind of a question of like, if all you're dealing with is data, like that's a database's job. It's just to hold a bunch of data.

Like it's not, it's not a big ball of mud because what we're talking about here is just data. Right. So what I said, you asked, what were the things that we have? We have a record with 55 models. And if you have an object with 55 methods in it, that's a ton of logic. But if you just have a record, a record is an immutable value. It's just a big bunch of data, like a large database. And so maintaining that is actually easier than splitting it up into a bunch of smaller databases that all

have to communicate between one another now. That's what it feels like to me. And I'm not sure if I have the same perspective as Richard on this. So I, like, knowing how their code turned out, it makes sense to me that it turned out well. But I think of modularity in a functional language in terms used in many places or things that are sort of related concepts. So I might create a type of data, a data structure that's used in a bunch of places. And maybe there are a couple helper functions around that data structure.

So I'll move that out to a module. And that's sort of the whole process of modularizing a code base. So I want to make this concrete. I'm not sure if I have a good example. Someone recently asked, I want to have a user that's logged in or not. Uh, and if they're logged in, they're definitely, they definitely have a username. It's not an empty string. Um, how do I represent that kind of thing?

And to me, the way you do that is you create a module that represents the data in a particular way and presents only a small number of functions that let you manipulate it. And so you check that those functions are correct and any use of any combination of those functions will work out. And now to any user outside, they can use it however they want and never mess things up. Essentially, you can never sneak into that module and mess with things. And this is what's sort of a big difference

between object-oriented and functional programming. is what's sort of a big difference between object-oriented and functional programming. And that's sort of unfair. It's a big difference between having mutation and not. So if I give you a value, let's say it's a very complicated record, like Richard's talking about, and I have this transformation that I know from A to B, the result is correct. Now, add to that, I do some mutation. Suddenly, I'm having these effects that are very hard to track down. And so that makes things a lot more complicated. So to go, I don't, I wouldn't frame it exactly like Richard's database thing. But I would say when you have 20 components with their own individual state, you end up in a situation where you're synchronizing state between all these different things. Now, the right way to bundle things up is to create these strong abstractions around particular pieces of information.

So I know all these transitions are valid. None of these other ones are valid. around particular pieces of information, right? So I know all these transitions are valid. None of these other ones are valid. So I can write a module that has that and it can be used by everyone. That's the kind of modularity that you're looking for. And there may be, I think there's often a pressure to try to draw those lines when they don't necessarily exist. So that's

that Richard might be observing in the production setting is these fields actually are related to each other. There's no way for them to sort of be draw a clean line where none of the stuff is dependent on any of the other stuff. I don't know enough about particulars, but hopefully that helps give an idea, right? So in the end, I would argue that the ability to write modular code is just fundamentally better because of the lack of mutation. In a sense, I can have two independent components and they can have no shared anything. But if I hand them a function, both of them, that

mutates the same state, suddenly they're clashing with each other. Even though they're written separately, they have no overlapping code. And you just can't do that kind of thing with Elm in the first place. And I'd say that's probably the biggest source of what you

have a system that seems modular, that actually you have these weird action at a distance problems. So one of the important things to note about this is that although we have, you know, on that page, like one large model with 55 record, or a large record with 55 fields in it, that's just because that page is complicated.

Those are 55 individual data points that we need. And so the question then becomes, how do you organize that? And like Evan said, the idea in Elm is that the cheapest way to make things modular is with functions. So yeah, we have one record with 55 fields in it. Guess how many functions we have?

I don't know, I haven't counted, but it's a lot. I mean, we have tons and tons of functions working on that thing. And they're not all just taking the entire model, right? They're all saying like, oh, this is a function that deals with just this, this and this particular piece of data. So we just make them function arguments. And because the way that Elm encourages you to write your code is, you know, with lots of small functions that do sort of the simplest thing that they can do, it ends up that the business logic of that page ends up being really simple. And in large part, it's really simple because we don't have to do all this synchronization. We're just like, okay, we have this one central source of truth.

And when we want to work on it, we call a particular function that just does one particular thing and we just give it whichever you know pieces of data off of that big database that it needs and that's it and we could instead you know like say okay only these functions get to work on this subset of that data and we're going to carve that off and make it its own small self-contained system you know we could make things a lot worse on ourselves. Well, so it may also be that you have an odd scenario, or maybe a common scenario, but for the kinds of things I write in Elm, it's different.

So I've recently been working on a little expando. So if you know the console in your JavaScript developer tools, how you can open up arrays and see all the things. I'm working on a version of that for Elm values. That's something where the expando logic is in a module.

When I want to show an expando, I grab it from there and there's a certain interface that I use to mess with that kind of thing. That's a case where there's a pretty obvious line and there are invariants about an expander that I want to maintain. So by putting that in a module, I can make all that happen. So the ability to do this kind of modularity is totally there. And I think what I would take from Richard's scenario is when you have a language that's really easy to test and

catches errors for you with the compiler as aggressively, you can have really big chunks of data and it works pretty well. Let me make an observation. And I think this will tee up the next part of our conversation around adoption, because I'm just looking at, you know, I'm looking at Elm from an outsider's perspective and Adam can attest to that, uh, very interested in it. In fact, uh, this happens quite often on the change log, but I think I hung up that call with Richard. I told Adam, Oh, I got to build something with this. And then I never did. So, unfortunately, that happened as well. But just looking at the interest around them,

because you guys have a lot of interest, I think the features are super compelling, like zero runtime exceptions, the error messaging, you know, that are friendly, that's kind of famous for that. The semantic versioning that's enforced on libraries. So many cool things about it. And so much interest in the community.

I mean, I can't think of another project, save I guess Elixir and Phoenix, like it's two changelog episodes in the same calendar year, for instance. And just people are like really excited about it. And then we look at adoption. It's like, there's a lot of different hurdles that you guys have to overcome

to move people from like interested and it's mysterious and I would like to try it, but I'm not really sure how. And you know, like full in like Richard's full in, no red ink is full in on Elm, 37,000 lines of production code, like going from interest to there, like what are the things in the way? And I'm seeing a few different aspects of that. And one of this is just the preconceived notions that a lot of us bring to Elm from object oriented programming or this idea of components, which many web developers, especially in the front end, have either been thinking about or using for years.

Unfamiliarity with functional programming in general, immutability, the general messaging and some of the complicated things, which you guys have been making less complicated. Like I did look into signals for a moment because the part that confused me a lot, like how do I now interact with the outside world? How do I talk to APIs? How do I deal with these different third party things? And that's where I believe signals and now subscriptions, you know, play in that realm. And that was an area where I was kind of confused about Elm. And then you have this other thing, which is, which is just a misconception. It seems like an all in proposition, probably

because it's a language. It probably has its own tooling and everything. And people think I have to, I have to have a greenfield project that like makes a lot of sense in order to like give them a real shot. I actually thought that even after our initial show, because I was like waiting for an opportunity to try Elm, but I was thinking like I had to have more of a situation with Ember where it's like, you have to have basically an ambitious web app that you haven't written yet and now you can try Ember right that's what I thought was Elm and you guys have like completely changed that or not changed it but changed the misconception in my mind with your recent post about sprinkling it in about kind of just like you don't have to go all in you can you can incrementally sprinkle Elm into your web applications.

And that's a revelation for me, at least, in terms of like, oh, I can actually give this a try in small ways and see if I like it or if it makes sense. I don't have to necessarily dive all the way into the pool. So I want you guys to speak to that. We are up against our next break. So we'll talk about what that means, how you can actually get started with that. And then we have kind of a roundtable Q&A, just a bunch of random questions for you all that we'll ask to close out the show. So let's take a break and we'll be right back. If you're focused on the data layer, there's an awesome conference being

put on by our friends at Compose. Modelethic databases are so 20th century. Today, teams are using a JSON document store for scale, a graphing database to create connections, a message queue to handle messaging, a caching system to accelerate responses, a time series database for streaming data, and a relational database for metrics and more, it can be hard to stay on top of all your options, and that's why you should attend. While much talk in developer circles these days focuses on the app layer, not enough attention is placed on the data layer, and data is the secret ingredient to ensuring applications are optimized for speed, security, and user experience. Hear talks from GitHub, Artsy, LinkedIn, Meteor, Capital One, and several startups, including

Elemento and DynamiteDB. Talks range from the Polyglot Enterprise to using GraphQL to expose data backed by MySQL, Elasticsearch, and more. The conference is in Seattle on September 28th. Tickets are just $99 and ChangeLog listeners get 20% off. Head to datalayer.com and use the code ChangeLog when you register. All right, we are talking about Elm and one way that they are making it easier to adopt, or maybe it's always been easy to adopt, but we just didn't realize this before.

Evan recently wrote a post back in July called How to Use Elm at Work. And the key of that post, tons of details, we'll link it up in the show notes, but you can gradually introduce Elm into your production applications at work. Guys, tell us the details about this. So I'd say this is similar to how we learn a lot of things in Elm into your production applications at work. Guys, tell us the details. So I'd say this is similar to how we learn a lot of things in Elm is we just sort of observed over time, oh, this is how it works. And then just share that as we learn. So this was definitely a case where whenever I talked to people who had a success story about Elm. It was, we tried this little corner of our project, and that was nice. And then we started to grow that and grow that and grow that.

Or we had this little page over here, and we said, oh, let's give it a try. And so I don't know of any full rewrite or greenfield. I guess there are some consultants who are able to do that. But typically, when people are doing that, they already have built the expertise through this gradual process on other hobby projects or smaller projects and other that already exist. So I think there's this idea that I'm not sure where it comes from. Maybe Richard will know better. But that it's all Elm or no Elm. And so it's always been true that the way of interacting with JavaScript has let you drop it in in this way. And so a big goal of how to use Elm at work was really just to tell people, hey, I know this used to come like really late in our documentation, but check it out. This

is how you embed it and how you use it gradually. So we had kind of made an almost necessary presentation error, right? So talking to JavaScript happens through this idea of ports. So essentially you can send messages into Elm and send messages out to JavaScript and all the communication happens through that. And pre 0.17, that needed signals. So essentially you needed a big conceptual framework to be able to use that. With 17, it became way, way easier to do that all within your Elm code. And so it just was was it still was at the end of the documentation though and we really wanted to have a way for people to know that approach and also have it be possible to present it very very early on in the learning learning process very cool anything to add to that richard yeah i think um i'm just trying to ponder why it feels like what you're, quote unquote, supposed to do is wait for big rewrite.

And I think the answer is just that it's a different language. Yeah. Right. So, I mean, you have a different compiler and conceptually when you're, you know, when you're starting a project, you pick a language and then that's the language that the whole project uses. But the thing is like elm interoperates with javascript and it's totally fine and in fact it's totally great to have elm side by side with javascript if you think about it um like when you're writing your own code you end up talking to javascript anyway because as previously noted there's an enormous

ecosystem of javascript out there and like you don't want to just ignore all that. You want to use it. Well, but I'll add, though, to counter this theory that a lot of the languages we have that did become big became big through use with the language they were sort of edging out, right? So when you have C++ becoming popular it's totally backwards compatible and so you'll you'll have these large code bases that are part one part the other and like a lot of languages take this route um and i guess you have the um micro architecture theories of how to introduce

languages gradually in the back end but i just don't know of a story of just totally replacing with a language like i don't know of any success stories along those lines of we just do it different now and our business also still exists after this process yeah i mean that that's a good point to frame it that way, because that's kind of what led us to do it this way. Like the incremental approach is just it's a question of risk. It's like, you know, if you do it all or nothing, then you're taking an enormous risk. Like, what if what if you don't like it? I mean, what if what if you try it and then your team's like, no, actually, we preferred it the other way.

Why would you ever do that? Yeah, that's something that from my perspective, if folks try out Elm and they're like, it's not for me. You know, my response is one, I want to find out what they ran into and see if I can make it better. And two, I'm not going to like push it on them if it's not the right tool for the job. I think it's great, but there might be some scenario. So a big thing for me is like, Elm isn't interesting unless it's the best tool for the job. And it's my goal to do that, right? So if it's not right for your case, or you and there are a lot of things to consider here. So it's easy to think it's just a technical problem. We have this code,

and we want that code. But what I've noticed is that it's almost entirely social. All the challenges are social, right? So you have a team. They all have different backgrounds. They all have different perspectives on what it means to write good code, what is fun, what their role is in that team, what their expertise means for everyone else. And a lot of what it means to start using a new language or new technology is to bring

the whole team along. So one thing that's been great for Elm is to have the JavaScript ecosystem start to edge towards ideas that show up in Elm. So as React goes more towards components without side effects or immutability or projects like Flow and TypeScript or introducing people to type systems, you're working on the social problem that we face in a very direct way, right?

So suddenly the distance between a team and using Elm conceptually is much less. And I'd say that's where a lot of the tough problem is when you're thinking of using a new technology. That actually leads into one of my random questions, and it kind of answers it to a certain degree, but I'll state it back anyway. So you mentioned how React community is moving more towards some of Elm's ideas. Dan Abramov, the fellow who created Redux,

we've had him on the show, and he shamelessly, he credits you, but he shamelessly said that he basically just took Elm's Dataflow style and architecture and he almost considers it a port over to his Redux library, which is now... Yeah. There's also the library Chew, which is just an overt port. It's like, hey, we're taking Elm architecture and bringing it to JavaScript.

Yeah, and in addition to that, we're also, people imitate Elm's famously good error message and saying, man, you know, we can do some of that stuff over here. We can write great error messages. And so, um, the question was going to be, how do you feel about all these people stealing your awesome ideas? But it sounds like you like it. Well, it's been a emotional journey. Uh, so there are times when I, I, I would get frustrated about this kind of thing and it wasn't, it never bothers me when it's properly cited, right? If someone says, Hey, I saw this thing in Elm and it was inspiring and I, I did this. That's awesome.

I love that. Um, but there are cases where something just comes out and you're like, I did that. And I presented it like that. And I talked about it like that. And you don't get a good citation on that. That really bothered me. Now, I've gotten over it just because it's silly to be upset about it because it's still really positive for Elm.

Even if no one knows that there's any direct inspiration even if there's not right so when react comes out they're coming with this what if your views work in this particular way and it looks quite similar but it's a case of co-invention as far as i can tell we just came to a similar conclusion working from similar premises. And no matter what, that helps us out. Right. So the fundamental wager is like, I'm going to try to do a really great job. And if it's great, then we're going to come out good from all of this exploration and effort to figure out how to do this well. Yeah.

Ultimately, I think the cross pollination of ideas is just better for everybody overall. So a follow-up question to that, who are you watching and learning from? Whose ideas might you steal and bring back to Elm? So I'll keep an eye on other typed functional languages. Often things are a little bit too crazily abstract there to really be super useful. So a lot of the stuff I'm working on these days are tooling stuff, right? So one of the things that people, a preconception they have about functional programming is those people don't care about tools. They don't care about testing.

They just, oh, well, if it compiles, you don't you need it's just like i find those sort of excuses not actual good arguments so a lot of the things i'm focusing on are given that elm has this design that's very structured and lets you do interesting analyses um and given that the tooling can be written however i want like how can we make tools that are delightful in ways that have never been seen before? So you mentioned earlier our package ecosystem. Every package that's published, we have a semantic versioning automatically enforced based on API. So we know if there's a breaking change or a minor change in your API. And so there just aren't any libraries in the ecosystem to break that rule. So I'm really focused on how can I find opportunities in debugging, Richard's thinking

about testing, where we can bring these ideas in a way that's never really been seen in a typed functional language before, just because they've been thinking about other things. We actually just came out with a new version of ElmTest, which is Elm's unit testing library. And basically what we've done is we made, I don't know if you're familiar with it, it goes by a lot of names, but there's property-based test or generative testing

or fuzz testing, which we like because it's fun. But it's the idea of you write your test once, and then the test runner just runs it for you like 100 times with different randomly generated inputs. So you get sort of a much wider coverage of corner cases, sort of without having to write all of those corner cases yourself. And I guess to answer your question more directly, when working on a particular problem like this, I'm not, you know, picky about what I look into, right? So a long time ago, I remember I had to pick the format of the documentation comment. And it'd be easy to

look at similar languages, but those languages haven't really been used in big enterprise code bases. So I really focus on what a Python document comments look like and what a Java document comments look like. And just like those languages, whatever you think about them, good or bad, do that really well. And so what can we learn from that so i i think it there's definitely a just a focus on a particular problem and then asking what's ever been done on this and what can we learn from uh what people have done before another another answer to your question uh earlier about um like what are we looking at uh erlang and elixir comes immediately to mind wow adam that tees you up well yeah that's actually i've been quiet most of the time here listen to you guys kind of dig deep into quite a

bit of stuff here but you know we're obviously building the next version of the changelog on elixir and phoenix and you know when chris was on the most recent show 208 he talked about this kind of harmony between uhixir and obviously Phoenix, well, specifically Phoenix, but this kind of harmony between Elm and Phoenix. What do you guys have to say about that? Well, so one thing that's been, I've been slowly working on is Elm has a, in the core library,

it has a module called process that lets you spawn these processes that will run independently. And if one of them blocks, we can swap over to another one and do work over there. It's still quite a immature API, but it's the building blocks of sort of what every Elm program is built on behind the scenes. And I think over the next, I don't know, couple years,

we'll be fleshing that out more and more. And that is sort of, my original thesis work was focused on concurrency in particular. So this has always been a interest of mine. And over time, I've become really enamored with how they did the fundamental API in Erlang. So I'm trying to see how we can work nicely with that to have a concurrency model that's really excellent.

And it's unclear where that will go, but I have some thoughts. Yeah. Some other questions we have, I i guess towards the end here is uh it's not really an faq it's kind of like just more like disbelief you've covered it a little bit earlier in the show but uh just no production errors i'm just wondering how like one of the goals that is stated in a recent blog post from you evan it says one of elm's goals is to change our relationship with compilers um compilers should be assistants not adversaries jared mentioned earlier you're

famous for your polite and helpful error message or compile messages uh compiler messages but you also say a compiler should not just detect bugs but it should also help you understand why there is a bug can you you talk about why this is such an important piece to Elm? Yeah, I mean, that kind of came about by accident, that we have these really nice error messages. But it's always been a big weakness of typed functional languages. You have this, the story used to be, you know, yeah, the error messages don't make any sense.

But, you know, after a couple of't make any sense but you know after a couple years you like you get it and it's really nice and it's just that's not good enough right like if we want to be competitive with these other languages and frameworks and stuff we can't have a three-year learning curve um and for no writing to say that they have zero what was it again Richard zero errors in production or what was the executive say earlier yeah zero runtime exceptions so basically I mean so the way that we know that is because so we use

rollbar to track runtime exceptions in general and because our javascript code still throws them all the time but specifically I mean to be very explicit about this every single rollbar error we've seen in the past, like ever since we introduced Elm, the fix has always been in 100% of cases, not changing any Elm code.

It's always changing, you know, JavaScript, even sometimes server side code. But it's just, it's never like the answer is never like Elm did something that we, you know, didn't expect the degree where it crashed it's just it's just that good at finding stuff and so i it's a mistake to credit me with this that the the ability to find this kind of this class of errors in this way and rule them out entirely goes back to uh the 70s. And there have been languages that have these kinds of properties for decades. But you get a communication problem around it, right?

So often when people are trying to present this, they'll say things like, you know, if you can have a type safe program and it's a sound type system, then you get these properties and these properties are really nice and like essentially what we realized is you can just say but these programs don't get runtime errors that's that's this that's the summary of all the theory that people have been working on for decades um and so we took that core idea um and that's just a part of Elm.

So the thing that I think is that I've done differently than other languages in this realm is really focus on the reporting quality. And the big realization wasn't we have to do it a totally different way. Or it was just if you put in engineering time, you can make really big improvements and get very specific error messages. And I think it's just part of my writing style that I like it to be kind of fun and friendly. So like if you mess up sometimes, you know, I'll give you a little trouble about it like i had this idea of uh oh man i forget the exact scenario where i wanted to have and i told you so if you'd ignored compiler advice from other times that's so funny but then if you hadn't seen the advice the first time because of so i didn't end up making it but having this kind of fun relationship with the compiler i, is it's just fun for me to work on. So one of the,

I recently did some improvements of the error messages for this upcoming release. And it's just really delightful. So we have a thing called error message catalog, where if you ever see an error message from Elm that you think could be clearer, you report it there. And periodically, we'll go through and sort of try to group them all and see how we can fix a big swap. So I just went through took a couple days, and you can make these really nice improvements. And you see the person learning Elm, who's just not going to have these problems anymore. And I don't know, I get it. That's really, really fun to me. I think that think that's you know like i i totally hear what you're saying about like not wanting to take credit for you know the work that so many other

people have done um but i think i think that you like legitimately can take credit for is just your relentless focus on user experience like i think that uh i really can't think the very few other languages take that as seriously as I think that you do. And I think that's, for me, that's made all the difference. Like, those other languages have all been around, and I've gotten kind of interested in them over the years. I mean, I've been programming since I was nine, and I have never latched on to anything like I've latched on to Elm and just had this much fun with it. And I think the reason for that is exactly that. It's delightful.

It's not just that it's reliable. I know that there are tools out there that can make my code more reliable, but reliable and delightful, that's a very different thing. And I think that that's commendable. Yeah, there were actually, before we had nice error messages so there was a yeah there was a time when it was it was way like bad not even okay um but at that time the i was thinking of like what should the motto of lmb and i want to put the bar like make web development uh pleasant because i felt like it would it'd be too far to say like delightful but just like

you know you know how you're like riding a train and it's it's just fine like i that would be amazing if we could get to that level um but yeah so that definitely has been a sort of how can we make this you know fun like something you want to something you're proud to have i like the idea of having a smart compiler though like you you know you know kind of think of your compiler as real time kind of directing you knowing what to do basically you know and to have this sort of learning aspect to it to educate you over time like hey you've hit this error or this compile bug several times you keep making this mistake or like hey I told you so it's just an interesting way to kind of turn

that into that non-adversary and more assistant role like you'd mentioned you know yeah yeah I was joking about this with with my mom at some point I was like if we get the same error like 10 times maybe the compiler could just be like

don't you get it? I was going to submit the Jurassic Park error message for you guys to add to your list. You know, uh-uh-uh. You didn't say the magic word. Oh, yes. But I've actually been thinking about how to make these error messages more interactive.

So we have a certain class of error messages more interactive. So we have a certain class of error messages that we don't know where this term is. Maybe you meant one of these other ones. So maybe there was a misspelling. So in theory, we can just do the suggestions and let you pick one really easily. So you click a button or something. So I'm very interested to see

how far we can go in that direction. And also once you start getting editors with sort of more, essentially when the compiler exposes sort of more ability to know information about the program, your editor can start doing interesting things, right? So instead of just suggesting names that we know exist, we actually can know the type of the argument that you need. And then we can know that all the values that have that type.

So can we start giving suggestions based on that? So I think there's a lot of cool stuff we can do there, but you know, in time, in time. It's gotta be tough to imagine like what you can do and what you should do is two different things, right? Like what you can do is make the compiler more of an assistant and make it more fun, but what should you do? Like you talked earlier

about the roadblocks to adoption and the various things you have to deal with. We've covered that in the show, but is that the perfect place to sit? And that might actually tee up the next mention for you guys is Elmcloth. So that might actually tee up the next kind of mention for you guys is Elmclough. So you might actually be able to learn

about some future things happening, not just on this show, but to cover things that we've covered here. But at this conference, what's happening at Elmclough? When is this conference? September 15th. It's right before Strange Loop in St. Louis, which is

one of my absolute all-time favorite conferences, quite possibly my favorite all-time conference. I bet. And I'm super excited that Elm Conf is co-hosted with Strange Loop. It was very generous of them to take it under its wing, as it were. Is there a particular affinity from the folks behind Strange Loop to Elm Cough? Or is it just... Oh, yeah.

Yeah? How did that happen? Well, basically, the guys who decided they were going to organize it, Brian Hicks and Joseph Hager, they live in St. Louis with Alex Miller, who runs Strange Loop. Right. And so I guess at some point they... I haven't talked to them about what the exact story was, but my guess would be that they they were asking Alex for conference advice.

And he probably just offered to be like, why don't you do it with Strangeloop? Let's just make it happen. Because from what I understand, he's been just like sort of a behind the scenes, incredibly helpful in so many different ways to making the conference happen um just basically because he wants it to exist um and i could not be more grateful because alex is an awesome guy and uh he does a great job with strange loop and uh i i'm not a closure person so i haven't been to his closure uh conferences but i just assume based on the quality of the other stuff that he's done that they're awesome too. And there's actually a kind of funny connection, which is the first talk I ever did, I believe, was at Emerging Languages Camp, which was the

day before Strange Loop a couple years ago. And I think that's the first time I talked about Elm in public, giving a talk. And so the Emerging Languages Camp, ElmConf is sort of in the same spot as that one. And kind of interestingly, I believe José Valim of Elixir was at that Emerging Languages Camp as well. So there's been a lot of support for languages in sort of Elm's age group. And Strangeloop's a conference that's really open to new approaches or sort of different perspectives and has been, I i think really supportive of these communities so share the details on elm conf is it is there a cfp are there tickets available what's the details there tickets are on sale and you're running out of time to get them because uh it's september 15th

they got uh the url for that is elm hyphen conf dot us yep yeah so ius I'm pretty excited to meet everyone. We got some speakers from all over who have different angles on how they're using Elm. Maybe that's for production cases, maybe that's for hobby projects or art projects. I think it's going to be a really fun set of talks um you know i'm i'm working on having something cool to show of course um but um but yeah and the thing i'm most excited about though is just to get to meet everybody who

who comes out uh and sort of hear what they're working on what things they're are working for them what things can be better and just get to meet everyone in the in the community um that's been one of the things that the most valuable kind of feedback but also just really fun to to i love it when someone surprises you with a thing you didn't know elm could do right so i had someone show me this like 3d concentration game with particle simulations and i was like i'm pretty sure elm can't do that and somehow this person had figured it out so it's just really cool to start to see what people are up to and how I can help out. It's also exciting.

I mean, something I've already experienced on the Slack and I'm looking forward to experiencing more in person is just how many people are using Elm in production at work and just we have no idea. Like I was like posting on Slack. I was like, we have 36,000 lines of production Elm code. And some other guy was like, well, yeah, we have 15,000. I was like, who are you? I've never heard of you. Yeah, I've heard of this happening in, there's a phase of growth of languages where at first

everyone's talking about it. And they're like, oh, this is amazing. And then there's a phase where everyone thinks of it as their competitive advantage and no one's talking about it. And all of a sudden you're like, holy crap, there's like tons of companies using this language. So I've heard this story for other languages where all of a sudden they're just like, oh, what? This is this is the first ElmConf, right? So this is the first time for you to basically meet face to face aside from meetups and Richard, you doing courses and stuff like that, doing some teaching and whatnot. This is the first time to kind of get some real face-to-face with some larger known people that are using it, like Jessica Kerr and others in that list of speakers to kind of share some interesting things about it. But also get to meet just general users that you didn't know had 15,000 lines of code.

Right. That's kind of interesting. I'm a little worried we're going to find out that we're not the biggest anymore. Uh-oh. Like someday we're going to talk to somebody, they're going to be like, we have more than you do. We'll be like, oh man, we can't. That is a silly point.

Still have Evan. If you come work at no riddick you get to work with heaven so we still got that there you go yeah of course that's that's always good lines of code isn't a good

judge anyways but yeah that's probably a good place to to close things down for this show i know that we have had uh you know our eyes set on the next uh wave of changes from from elman to have

uh you guys back to kind of talk through some different things. So I think we've covered quite a bit in today's show. Is there anything any last rock unturned that you want to mention besides obviously UMConf and to go? I want to make a shameless plug for my book

Elman Action. Chapter 3 just came out. It's available for early access manning publications check it out nice we'll make sure we get a link in the show notes for that to uh to manning site and is that uh set up for me because that what it is it's where you can actually read it in line with you writing it exactly nice that's good yeah and i've been doing reviewing and it's i like it a lot often i like, oh, that's such a good way to present this. That's cool.

And I guess if I have any advice, it's just, you know, if you're curious about what's going on with Elm, I'd say just give it a try. You know, worst case scenario, you're like, I don't like it. But I think a lot of times folks end up learning stuff, even if they don't end up using it ultimately, that is helpful in whatever they go back to. So sort of immersing yourself in this set of tools that help you think in a different way is going to help you grow as a programmer. So I wouldn't say, you know, do it because it's the bomb, but just do it because it's fun. Yeah. Well, on the note of trying to, if you go to elm lang.org which is actually elm hyphen lang.org so for those all those listeners going there right now there's

actually a try or install kind of uh in marketing terms a cta you know call to action so um you can try or install it so if you click on try it actually takes you to um hyphen lang.org slash try where you can actually go through hello world, buttons, clock, drag and drop, and tons of other examples. I was kind of bummed not to see the centering example, since that was the impetus of the first place. I think that should be one of the examples there of centering something, at least to prove that you can actually do it in an easy way.

But this is a great place to go. So if you're listening, go there. Actually, Slash Examples has a ton of examples there as well. Everything from effects to union types, recursion, a bunch of stuff that's available to kind of dig through it and kind of see how it actually lays out and play with it early. So let's leave it there, fellas. Thank you so much for taking the time to come back

and share so much of this journey with our listeners and what you're doing with Elm and obviously the conference and the book coming out and all that you guys do at Red Ink or at No Red Ink. I said that last time, I think, in that little short. It's No Red Ink. My bad. Happens all the time.

Yeah, I'm sure it does. I'm sorry about that but let's leave it there and again thank you for coming on and listeners thank you so much for tuning in

and let's say goodbye thanks guys bye bye thanks for having us We'll see you next time. you