Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
Elm & The Future of Open Source (with Evan Czaplicki)
3.2k Plays1 month ago
Evan Czaplicki—the creator of the Elm programming language —joins me to discuss the state and future of Elm, the friendly, type-safe functional programming language. On many fronts Elm has been a huge success: it’s been popular with new and seasoned programmers alike; it’s helped push several language ideas into the mainstream; it’s been a key part of several successful software businesses and he even found himself employed as a kind of Language Designer in Residence. And yet, the material rewards of a successful open-source project were…lacking. Was he naive? Can an open-source developer stay true to open-source principles and still make a decent living? Is open source being exploited by commercial software businesses? These topics and more tumble out of what has to be the first question in the podcast: What’s happening with Elm?
--
Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices
Support Developer Voices on YouTube: https://www.youtube.com/@developervoices/join
ElmLang: https://elm-lang.org/
The Economics Of Programming Languages: https://www.youtube.com/watch?v=XZ3w_jec1v8
Kris on Bluesky: https://bsky.app/profile/krisajenkins.bsky.social
Kris on Mastodon: http://mastodon.social/@krisajenkins
Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/
Recommended
Transcript
The Core Challenges of Language Design
00:00:00
Speaker
There are three hard parts to writing a programming language and none of them are writing a programming language because there are plenty of good books and courses online that will teach you how to do it. heck I can teach you how to write a programming language of some quality in a couple of hours now what makes it hard are one.
00:00:22
Speaker
What programming language do you actually want to write? What are your design ideas? What good things are you planning to make easy? What bad things are you planning to make hard? Job one is to graduate from language implementer to language designer.
00:00:38
Speaker
And then the second thing is a programming language on its own isn't actually that useful. You need libraries. You need the core library. You need a file system API, maybe a web library, whatever, database APIs, whatever people are actually going to need in order to ship some code, which in turn means you need a package manager and a package registry. People are going to want editor support, LSP, a debugger. You need a community where people can go and ask for help.
00:01:09
Speaker
You end up having to build something really quite big before it even counts as a small language. And then there's the third one. The third one is somehow you have to make it all sustainable. You've got to be able to pay the bills if you want to keep doing it. You've got to put food on the table and GitHub stars are not food.
00:01:31
Speaker
Well, my guest this week is Evan Chuplitzky. He's the creator of Elm, which is a language I absolutely love. And I hope you'd accept that he did a brilliant job of the first two, the design, the ecosystem, and he kind of got bitten on the third. Being a successful language designer, it's not going to buy you a mansion in the Hollywood Hills, but it should end up paying you more than a junior developer who's 12 months out of boot camp.
00:01:59
Speaker
And it probably doesn't, probably doesn't even pay that much.
Interview with Evan Czaplicki: Elm's Journey
00:02:02
Speaker
So I knew when I got the chance to interview Evan, I'd have to start with the question, what's going on with Elm? What's next? But to answer that, we had to get into the topic. What's happening with Elm's funding? What's happening with open source funding? Has the open source developer dream died? Or was it always wrong footed? And if so, is there a way to get it back on track?
00:02:27
Speaker
What's Evan working on right now? Has he figured out how to make it sustainable? And is he going to go for the hat trick? Let's find out. This episode was recorded live at GoTo Copenhagen, and it was an absolute joy to do live. So thank you to them for being my host. And I'm your host, Chris Jenkins. This is Developer Voices, and today's voice is Evan Czaplicki.
00:03:02
Speaker
Please welcome Evan and Chris. Thank you. So, Evan Chablitzky. Who are you, right? I'm going to give a quick summary. You can tell me if I'm completely wrong. Evan Chablitzky. He's the guy who created Elm. That's true. That really lovely, friendly-typed functional programming language, right? Thank you. You're also, which I think not so many people have realized, you're a really good thinker about how functional programming should impact people, right? You are you are ah you are surprisingly good at thinking, hey, this isn't just a maths idea. This is a talking to people idea.
00:03:38
Speaker
And, as part of that, I think when the big book of computing history gets written, and I hope there's a chapter that says, did you notice around the 2010s, programming languages started to get much better error messages? Like, new ones worried about it, and old ones started to improve them. That's all down to you.
00:03:59
Speaker
Well, I think you would expand. I really appreciate you saying that. That's definitely been one of the things I've been most proud of in my work. And it's been cool to talk to other language compiler authors and hear them, what they're working on with their error messages and sharing.
00:04:15
Speaker
techniques and stuff. Yeah. yeah yeah so ah So this is a big topic we need to get into, like beyond the language talking, about but I know the internet will explode with comments if I don't start with this question, right? You've just done a talk about success stories with Elm.
00:04:31
Speaker
Elm hasn't had a release in like five years. That's true. What's the state of Elm? Yeah, so ah essentially what happened was Elm, I was developing it as an open source engineer, um employed by a company using Elm a lot.
00:04:46
Speaker
And eventually I realized that as Elm was growing, my ability to handle that growth wasn't keeping up. right So like if I made a contribution that a lot of people liked and was really valuable, that would bring in a new wave of people. But how I was assessed in my professional relationship that had no relation on whether there would be A colleague who could help me with that new amount of workload that's coming in and so essentially around 2019 2020 I realized that like
00:05:18
Speaker
I'm and i permanently hitting this wall where like my assessment is my value to this organization, and that isn't proportional to the amount of work and difficulties I'm going to run into as the language itself is more successful. yeah So I made the explicit decision of like I personally, I can't invest more in growing the language until investing in that growth also is correlated with an ability to support that growth.
00:05:45
Speaker
Does that make sense? It does make perfect sense, and it seems like a classic trap of open source. For sure. It i don't doesn't sound like you found the greatest secret to getting venture capitalists to fund your own language, but did you look into like, okay, so let's make it a community thing,
Psychological and Financial Struggles in Open Source
00:06:02
Speaker
or let's start the Elm Foundation? I don't think you do that. i Yeah, I did make a foundation. um one of the There are a lot of different things you can try.
00:06:11
Speaker
And I went and looked at them and talked to different language creators to see like how they feel about it. And so for me personally, going on a donation model, I felt, for me so personally, psychologically, I wouldn't be able to deal with that. Because the real issue that I was having when I had these corporate sponsors was um that my value wasn't My value to them wasn't the value of my technical work. It was how they perceive me. um And in a donation structure, like I can do technical work that's like definitely valuable to a lot of businesses. But if it's not perceived in the right way, if it doesn't flow through Hacker News and Twitter in the right way, like that affects my ability to run a stable organization where people are like happy and secure and feel like they have a career.
00:07:05
Speaker
so Essentially, I kind of always thought of Elm if with like a farmer mindset, which is to say, like in some years, you have good years. You have good crop. And what you do when that happens is you don't go buy a nice car. is You save that away because one year it's going to be rainy, one year it's not going to be sunny. So effectively I saved up such that when the if there are bad times, I'll be able to work through them on my own terms so that I'm not putting myself in a language in a situation that I don't feel is sustainable long term.
00:07:42
Speaker
But that, like, working through on your own terms, from what I know of you as, like, the guy who makes great error messages, who wants to talk to people who just gave a talk about, like, why functional programming matters to non-programmers, I would have expected to work on your own terms to be much more public, right? i would I would think working on your own terms means communicating to lots of people. Normally, normally. Okay. And so we did have a pandemic, so maybe that's a fact. Yeah. um Essentially what I ran into in 2020 was I had been working on Elm for 10 years and there were all these companies using it successfully. And when I went to them and I said, what are you struggling with? Where should I focus my energy?
00:08:25
Speaker
the answer was always like, well, it's going pretty good. We're actually struggling a lot with our backend. Like again and again, I got that response. yeah And at some point I kind of, you know, it's not so motivating to say this project is going to take a year and like everybody doesn't care. And so like, and also I've been working on it for 10 years, like, um,
00:08:48
Speaker
I was ready to try something outside of you know optimizing my compiler to be better and better, but like can I gain more skills? like Can I have technical career growth as well? and so That's when I started focusing on like what would these kinds of things look like on the backend.
00:09:06
Speaker
But in doing that, if you say, hey, I'm going to do that publicly, you then create this whole world of expectations of like, it should look like this. I think it's going to be like that. And so I kind of thought of it as like, it's like um if a company was going to release a new car and and then so they announced five years in the advance all the features of the car and how fast it was going to be and how cool it was going to be.
00:09:32
Speaker
And then ultimately, it wouldn't be exactly like that. and and And the excitement that happened then is wasted in that like that excitement could have been people going directly to try it out. yeah And that doesn't happen. So I think just on a practical level, because working on a language or a back-end language is such a long-term investment, and because you kind of you don't want to promise something that you can't make, like I was in a sort of difficult situation to work on that kind of work.
00:10:02
Speaker
and meet the needs or the demands of everybody else going on and what they are looking for in the world. Does that make sense? It does make sense. It makes it one of the two things.
00:10:17
Speaker
like You sort of disappeared, I thought, which is entirely your right to do. But did you ever feel like you should have handed it out, like passed the bat on on Elm while you did this other thing? um I mean, I kind of looked at it as I have personal relationships with the companies that use Elm that I know about. And if they have anything that they're looking for, we we will talk about it. So like the idea that ah what a language is, is like what it's perceived to be online, I think is a little bit of a silly understanding of it. And it's like having those direct relationships with people who are like legitimately invested in it, like I think works as well. And so that was kind of the attitude I took. Fair enough. So through the past few years, like I've kept in contact with these different companies and show them updates on what's going on. So I want them to know like what's happening, even though
00:11:18
Speaker
it's ah It's not certain, like, okay, this back-ending is going to be exactly this or whatever. Yeah. Okay. So that takes me to the other thread I was thinking of going to. The fact that you're and you're talking about it openly now suggests you are closer to the end of that development period than the start. Yeah, for sure. What's on your mind right now? What but what are you working on? To the degree that you're comfortable announcing it on record.
Backend Development: Evan's New Frontier
00:11:45
Speaker
Basically, the core things I'm working on, I feel confident that what I wanted to do I can achieve. And it's more now saying, OK, how do I get interested where I can present it to people well? um So we're kind of at the start. like I've been doing little private talks where I'll do a demo and talk to people and say, hey, are you interested in this, and try to start to,
00:12:12
Speaker
work with people privately to prove that it works and get the kinks worked out. Because again, like releasing something like this, if I go back in time to when I was 22, doing all this work in the open is different because nobody knows who I am and it's all just you know some weird guy posting online. yeah yeah and so In this case, like i didn't want to i don't want I don't want the level of scrutiny that will come to me until I'm ready. and I feel confident that I can sustain that. Yeah, that's fair enough. yeah An example of that is like... um
00:12:48
Speaker
I think when Dart came out, I think they really got slammed because it was connected to Google. right like If it had just been Dart, the language by the guy who worked on a JavaScript VM, and it had somehow been organizationally separate from Google, I think its reception would have been really different. And so these are kinds of factors that I look at what's happened, and I say, I don't want to get slammed like that. Yeah, that's cool.
00:13:15
Speaker
saying it comes from Google is a really lovely thought. And they got, from a compiler author's perspective, like people were saying really silly critiques. So they were like, oh, the code size is really large what in the initial release. And it's like, yeah, you don't like when you're first making a language, you say, well, there are problems that are hard that I need to know if I can solve, and there are problems that are known and easy, and anyone can do any time.
00:13:41
Speaker
And like you end up getting criticized on these silly ones that from a person knowledgeable in the field would be like, You can't assess it on that. yay um ah yeah i mean right I think we've faced that work. Even though some of us aren't compiler authors, we have shown a feature in its prototypical state to a manager, and they don't get the idea of a prototypical state. It's very particular to the particular technology. like word There is a time to show people stuff. so there okay I'm going to back away from that topic. Thank you.
00:14:14
Speaker
But I'm still going to approach it from another angle. right So um i if I want to know where Haskell thinks programming is going, I can read academic papers. If I want to know where unison is going, well, I can pretty much guess that it's as much collaboration as it is functional programming. So my question is, without detailing your personal plans, where would you like programming to get to in the next five, 10 years? What do you think we're still missing?
00:14:44
Speaker
I mean, I ah have a you know somewhat provincial answer. It's not like a big idea thing, but it's just like for the companies that I think have seen successful functional programming,
00:14:57
Speaker
Having that type safety flow through the whole stack, through the whole system where it's like if I can make a change in my database and see the nice helpful error message in my front end and in my server is like, I think that could be really huge. And that's something that a lot of the companies that I talk to really want. And it feels like there's efforts all over to try to obtain that through like, we write these contracts, we use these data interchange formats. And so for me, having ah compilers that can actually analyze the full system is something I'm excited about. okay yeah yeah i see
00:15:37
Speaker
there was This reminded me of your talk in which you had a number of case studies. It was like they had Elm on the front end. It was great. They had something else in the back end. Maybe that wasn't so great. And the interface between the two of them was broken. That's where they would see errors, for sure for sure. So you are thinking of taking your success in the front end and capturing more land. Well, i don't I don't personally see it that way. For me, it's more of like I have a career as a compiler author, and like I want to have career growth and do interesting work. And this is interesting work that I think can be valuable to people. OK. Are you rethinking value at all? What do you mean? What do you mean? I mean, um as a compiler author, it's very easy to be poor and unheard of. but Yeah, I'd agree with that. And you are you thinking, there's a certain amount of reputational success you have, thanks to Elm.
00:16:35
Speaker
is that what do you what do you think the success of your next step as a compiler author, assuming it happens, what would it look like? Will money be a factor? Will the ability to carry on being a compiler author be a factor? Will a number of people who use it and love it?
00:16:52
Speaker
yeah i think For now, the best I can say is I did a talk in the last strange loop called the economics of programming languages that lays out the challenges you face ah in an environment where like there are big players who can essentially, whatever thing valuable thing you're doing in open source, they can come and capture it and have all that money floated down.
00:17:20
Speaker
so like ah how well I look to like database ah projects where they often have models where they're able to protect themselves from Amazon and still be able to support the database that they're working on. so like Maybe an example of this is Nginx. I don't know if people know this, but like Nginx is open source, but there's also an nginx pro and they've done a really clever thing of like basically there are certain things that only companies only large companies want and no one else would even think about them or know that they exist and so those are the things that is in the pro version and so there's ways to draw lines like that and to be clear
00:18:09
Speaker
Elm is open source, it'll always be open source. I'm not talking about Elm. We're not talking about Elm Pro. Yeah, no, no, no, no, absolutely not. And I don't want anyone to think that that's not going to happen. Elm is BFT3, it'll always be. From Pay for Pack of News tomorrow, Elm Pro is coming. Don't do this to me. I'm sorry. So what are you saying?
The Pitfalls of Open Source and Exploitation
00:18:35
Speaker
I did a talk a year ago that I think lays out the challenges in in the in a way that I'm comfortable talking about. you Okay. I'm not here to make you uncomfortable. I'm here to pick your brains on interesting things. So let me bath away from that topic respectfully and talk about... There's another way that I can say it, which is like, I think When you go and publish code for other people to use, you're really putting yourself out on the limb to say, like I trust that the people betting benefiting from this will take care of me. And what I kind of got the message with Elm was that the that's not true. you know like When you have a venture-backed Silicon Valley company, like there're in their list of priorities, like
00:19:27
Speaker
taking care of you and doing the right thing is not like that high. yeah and so It's horrified by this thought. like Never considered it that high. For me as a programmer who's excited to share ideas, like I want to just share the idea, but at the same time, like I also need to protect myself from you know, people who say they self-identify, I'm a capitalist, I'm a venture capitalist, who want, if there's free value, they'll take it, you know? yeah So it's like a more complicated thing than just...
00:20:05
Speaker
this whole discussion of like, well, Eric Raymond in 1990 said, duh, duh, duh, duh, duh. And so like, that's the only framing we can use to analyze these projects. Yes. Yes. Okay. It's, it's reminding me of like, I used to do a lot of open source stuff and yeah.
00:20:24
Speaker
One thing you realize doing open source is like people will assume you're promising to maintain things forever for free and provide features for free forever. And that was kind of fun when I before I had kids. When I had kids, the price of one spare hour went to infinity.
00:20:41
Speaker
Yeah. And suddenly I realized the economic agreement. Yeah. And I mean, I saw that with as people in Elm World got older and had kids is like you start having this decision in your head is like, I can handle this incoming request or whatever, or I can spend time with my son.
00:21:01
Speaker
or you know what I mean and it's like 60 minutes of sleep and it's like on what basis can I say that talking to the stranger is more important than and it's just like you can't do that and so it's um that That's another reason why I felt like having some kind of organizational solution was important. so that like i mean i At some point I talked to a CTO of a company that are using Elm and we were talking about like ways we can do some kind of cultural
00:21:32
Speaker
investment like get things going get blog posts going and I was like kind of had a limit of like I don't personally ask people to do open source work and I say specifically if you're having fun I encourage it, but once you stop, it's like this isn't a like people will take things from you legitimately and like you have to be able to protect yourself. so Just because of the experiences I've had, I don't want to then turn around and walk someone else down that same path that I went down. and The CTO was like, oh, but I think they would do it for free. right and it's like and that's That was exactly the issue that I had through my career of like
00:22:16
Speaker
i I literally just heard exactly what you said about how this messes up people's lives, but it's like, yeah, but like, who cares? Yeah, yeah. We definitely see that in the industry. at high I don't see a solution, so I'm not going to spend too much time ah asking you if you have an absolute solution to it.
00:22:36
Speaker
but Okay, actually, oh I would like to share some thoughts there. So I think part of what had been so powerful about open source is that it captured this kind of like anti-corporate sentiment. But when you go to the founding documents, it really is from a specifically libertarian perspective. And like Eric Raymond like has said in interviews, like,
00:23:02
Speaker
Maybe this is a way to smuggle my values into these corporate structures and have them run in a specific way. And so I think it's ultimately a pace ah politically specific analysis of our industry. And for me personally, I look at it a little different in the sense that like I think a family business and a publicly traded business and are categorically different entities. right like And so once you start doing a more thorough analysis, like the energy that is against like large companies taking advantage of small people, it's like you can have a more interesting um conversation than just like, is the code free or is the code not free? It's like, are we able to support small creators
00:23:57
Speaker
or not. you know yeah and i mean One classic issue when you have a system that doesn't have any kind of like power distribution analysis is that it ends up being very favorable to powerful institutions.
00:24:12
Speaker
right So like if you have an open source project with one developer, and then you have an organization that can say, here are six people who can replicate that or just take the code wholesale and add onto it, and we have a marketing team and da, da, da, da. And it's like, is that in the original spirit of like being anti-corporate that that it is like explicitly permitted in the the way that we generally think about things based on this old ah writings from 1990 or whatever. Yeah, so maybe be you're saying we need we need to kind of update the open source mindset. How how I think of it is like, I think
00:24:57
Speaker
We're seeing a lot of creators like get burnt out and run into these walls. And I think ultimately like it's a failure of the analysis of the industry that if the goal is to have like independent, creative programming work,
00:25:15
Speaker
like this isn't sufficient to sustain that and make it healthy for those people. and so like I think you know there's this really interesting video of Eric Raymond where he's telling the story of like, I was at Microsoft for some reason and some stuck up looking VP got on the elevator with me and he says, who are you? and He's like, I thought he had some pretension around him and he says, I'm your worst nightmare.
00:25:44
Speaker
And ah and mean just watching it, I'm just like, that's you know is life isn't Star Wars. like This isn't how it works. And then you know now, 30 years later, like it's not their worst nightmare. They bought GitHub. they you know yeah And when you go to the original writings, like he's saying, look, this isn't about um code should be open source because that's like the right thing, he's saying it should be open source because that's better for business. like I forget which essay he writes that because like here are the six scenarios where it's just better for business.
00:26:24
Speaker
and like On top of that, all these cultural elements are put, but ultimately, like we are now multiple decades later and like it wasn't the worst nightmare of Microsoft. like All the big companies that are able to like take advantage of things are have embraced it. and so like If our initial thing is like to be anti-corporate, we have to look at ourselves and be like,
00:26:49
Speaker
on what level is this way of seeing the world like serving us? Yeah. Yeah. We definitely hit the point. We definitely made the case for all the different ways that open source is better for business. And maybe we forgot to make the case for why it's better for us. Well, yeah, but ah yeah, for, for independent people. Yeah. Yeah. Yeah.
Enhancing Functional Programming Accessibility
00:27:05
Speaker
Okay. Um, we've talked more about business than I expected, but I did expect to talk quite a lot about getting beyond the code. right So the other thing I really want to talk to you about is,
00:27:17
Speaker
We have this thing of value. We have this thing of great value called functional programming. You type to functional programming, if you want to get into that it's distinction. i And we are definitely struggling to disseminate the value of that idea out to the world. And I know you've got you're really good at thinking and empathizing with the other side of the wall.
00:27:39
Speaker
So give me some ideas on how I can do a better job of sharing the thing I think is absolute gold dust with the industry. Well, I'll say I think, like, i I'm always very positive towards languages. Whenever I look at a language, I try to see what's great about it, and I try to evaluate it based on what the language author wanted to do. So there'll be languages where everyone's like, ah, that languages suck.
00:28:07
Speaker
so Let's take PHP for an example. like It's hard to find a real enthusiast. At least I don't run into them often. But when you say, what from a language design perspective is so special that made this such an influential and useful thing, and it was the directness of like I want a website, I have a website. and I think when particularly intent functional world,
00:28:34
Speaker
people can get distracted by like the particular language design details and overlook, like like in Ruby on Rails, I think a big moment for it was like ah setting up a website in 15 minutes. There's like some video where it's just like, I don't have a website, I have a website. yeah And so I think that immediacy is something that, for cultural reasons, we overlook in the tech functional world.
00:29:02
Speaker
and like Working more there, I think, would have big effects. So I use Haskell all the time, and I love it, and I you know i think it's great. um That said, I do write some of my own like core libraries for the kind of work that I want to do. And there's stuff that you know I want to use the standard OpenSSL library. So I write C bindings to it, and I do that for myself.
00:29:31
Speaker
but like If we're trying to have that immediacy, like you can't say, well, first you choose the SSL C library that you prefer. yeah you when So are you talking, I thought you were going to be talking about the immediacy of understanding these ideas. no It sounds more like you're talking about we need to improve the developer experience. yeah the The immediacy of taking like For most programmers, it's like, I'm not coming here to like be on a learning adventure. It's like I'm coming here to like, I'm excited to make an app or to make a website or to make a server. And like if you can do that in five minutes, like all this other learning becomes an exciting side quest. But like if you're three weeks in and you still haven't made the website, it's like, just am I ever going to get there? like it's It can be really discouraging, I think.
00:30:25
Speaker
I mean, that was something from the beginning of Elm, I had an online editor and it was like, I'm not going to post about this until I have that editor working so that someone can go from the idea to directly like, oh, I made it. Oh, I changed it. Like I can actually feel what this feels like. yeah yeah And I think for some of the more advanced ones, like getting to that point of like you and I have experience where it feels great takes too long basically yeah yeah there are some languages that say oh you want to use this language okay go download our package and it's not going to school because you don't have this libc yeah exactly yeah so yeah i think that's huge
00:31:06
Speaker
um And it's not like that glamorous. I mean, I think that you see that at James Street, it's like they ended up making their own core library and own like separate from the standard one. um And it's like it is a big investment. And I understand like if the core developers are academics or, you know, having some kind of industry relationship or consulting or to support themselves, then it's hard to do that. But also, I feel like
00:31:38
Speaker
That's the path. I don't know. OK, yeah. In that case, let me ask you a more specific design question, because you're also a very good language designer. I'm going to frame it as the Ruby on Rails problem. right The amazing thing about Ruby on Rails is you type a few lines of code and you've got a website. The thing I always hated is you type a few lines of code and you've got a maintenance problem. sure and you have to make Whenever you're trying to design for accessibility and simplicity, you have to make some really good decisions or all you do is dumb it down and lock people in.
00:32:11
Speaker
And I think Elm has made some good and hard decisions about what to worry about and what not to worry about. um So I want your design thoughts on how we can, like, does which which parts of, how do we do a developer experience that gets easier without getting toyted? Sure. toy tank Yeah. So I think Python is a great example of this.
00:32:38
Speaker
Because the Python that everyone thinks of is like a small subset of all the things you can do in Python, and how inheritance works, and all these kinds of things. But when you come, you say, oh, it looks really nice and light, and there's a for loop, and there's an if, and that's kind of it. you know Oh, there's an array. OK.
00:32:57
Speaker
um and so i think Just because of a historical development of that language, the initial resources that everyone goes to are talking about like an early Python that was quite minimal features. And then as the as someone gets deeper into their path with it, they'll find out about this other stuff. But by and large, people stay in that simple area. And so I think having something like that in a language like Haskell, where it's like, look, you don't know about monads or applicatives. We're going to put that aside as like an expert area and say if you're just here to make a website, you're just here to make a server, use these libraries. Don't think about any of these extensions like these are for
00:33:47
Speaker
specific scenarios, which isn't to say to be judgmental of them. I mean, I use weird ones, but like if I was saying, hey, I'm goingnna i am now employed to build an organization of Haskell programmers,
00:34:03
Speaker
I'm going to specifically say like here are the boundaries of what we do in a like business environment. And we can get these benefits, but like for the purposes of when people come and go, we need to onboard people, like we can't have that level of complexity here. And you see that in like C World, where like there every feature you want is there, but every company has their own style guide of like this is what we use and this is what we don't. And so having like a basic default of like If you're here for the immediacy of get it up, don't have a maintenance burden. Be here and don't listen to other of people. um And as you build that expertise, maybe venture out.
00:34:48
Speaker
ah So you're saying you have a small subset that's definitely immediately accessible with that, but but you can keep that? one Yeah, you absolutely do. I mean, within my own code, it's like me and my wife are both programmers. And so when she writes Haskell code for the work we do,
00:35:05
Speaker
She does so in a server system that I wrote where the routes are done a nice way and it has this immediacy like she she learned Haskell before but she's like feels really happy and productive in that Setting this is an aspect of marriage. I've not expected Yeah, it's also like if you say to your wife like hey, I want to make this like multi-year investment in something that may or may not work out and I'm lucky that my wife is like, that's going to be cool. Let's do that. That's pretty nice. That sounds like more support than you ever got from the venture capital.
00:35:47
Speaker
Okay, so i want I want to come at that from another angle as well, because um there is definitely a sense that more immediately accessible languages get success in disseminating ideas. But I also, it makes me think of another language which doesn't have immediately accessible ideas and yet is being very successful and it's rust.
Rust's Success and Evan's Design Philosophy
00:36:12
Speaker
What's your Not what you take on Rust, but what you take on why Rust is succeeding in Mindshare. So going back to my personal analysis of open source, when you go look at the history of what happened there is Netscape was this huge internet company, big success story. Wall Street's paying attention. They have this IPO. It's super high. And it falls off. And part of what happens is they have this web browser that has all these bugs.
00:36:43
Speaker
And it's totally bug-ridden internet explorers coming for them. um And so they say, hey, there are these like nerds online who are talking about open source and free software. And the main thing they're talking about is like,
00:36:58
Speaker
Open source is better because all bugs are easy if you have enough eyes on them. And so when you go to those old documents, you find people explicitly saying, we are going to open source ah Netscape as Firefox.
00:37:13
Speaker
um specifically to get that free labor. And they there's some documentary where they actually bring in someone who's like been working for free in some Midwest state. And so it's like explicitly a cynical, how do we use these people for their expertise to solve this business problem that we have? yeah And it turned out it didn't really work for them. But the organization that came from it,
00:37:40
Speaker
i don't ah I'm good just going to keep going. It's Mozilla. And so they kind of became the arbiters of like what open source should look like, what it should be, while at the same time, like they're getting paid by Google to so Google can be default search. So they're saying like open source should work this certain way, but for us,
00:38:03
Speaker
These guys pay the bills because they're kind of like paying us off to be default. like It could be anybody. But for for up for you, we don't talk about that. For you, here's how it's going to work. And so I think they're, again, going to the Dart story, like a big part of why that release was really traumatic and difficult was because the CTO of Mozilla came out and like slammed it, like multi-multi-paragraph of why it was a horrible thing.
00:38:31
Speaker
And so I think they have a lot of weight in, culturally, in terms of open source stuff. And they're very trusted. And the fact that it came out of there and that it follows all of the guidelines that they define as what open source should be, like it on all these levels, it culturally aligns with what it should look like. And like no one has to worry about where the money comes from, because no one ever talks about it. and No one has to think about it. You know what I mean? and yeah You're an American, but you've moved to live in Denmark. Were you thrown out for not being capitalist enough?
00:39:06
Speaker
they they Waifus Danish, I'll say that. Okay, okay but there's self-selection. Okay. So let me ask a couple more questions before we turn it over to the crowd. and here's another thing i think about you right i have many i have too many thoughts about you it's not right we can delete that from the recording um it's like so you are very much as a designer And you're a good designer. Like, there are some people who are good at building compilers. There are some people who are good at design. It's where you see both. As a designer, it seems to me part of your technique as a designer for good systems is to disappear and think and then come back when you've got a good answer. Which I know Rich Hickey would endorse, going to sit in the hammock, right?
00:39:54
Speaker
um But given that you're someone who hides away until you've got a really good solution, why are you so good at like human affordances in your own designs? Shouldn't you be out there talking to people and like doing... and There is a life accident that happened, which is what I should have done is gone and get a PhD and try to be a professor because I love teaching and I love sharing my excitement about technical things or things I'm excited about. And by circumstances, that's not what happened to me. ah So I think it's just like, I really love sharing ideas and talking about them. And that's just a baseline true thing. So that whenever I'm feeling sad,
00:40:41
Speaker
about things, it's like, oh, like being able to talk about interesting ideas really always livens up. But yeah, I don't know if that answers the question. It makes me wonder if, in order to get more releases out of you, we should make you more sad. Because when you're happy, you disappear. I mean, I think a lot of effort's been put into that, and I'd say it didn't work. OK, on that wonderfully scary note, I think we'll turn it over to the audience for questions. Has anyone got any questions for Evan?
00:41:15
Speaker
Your point about the error handling now, and particularly you talked about your desire to see that flow throughout the whole stack, immediately resonated with me and made me remember an experience I had. I don't know where I was and what year, in 1997. I was working on a Java RMI system and I got an error.
00:41:38
Speaker
in which is so we have a client and a server and the client failed but sent me the exception of the client and the server that had been marshalled through. And I almost fell off my chair because the previous it was you'd get no response and then you'd see and you'd go to the logs and you'd see the server had crashed and you'd do a stoke up a debugger. And so it was such a big jump. And I feel that perhaps we've gone back to um telemetry and having to sift through logs again. So i kind of to thank you for kind of re kind of presenting the importance of error handling in terms of
00:42:15
Speaker
human productivity, but also kind of like stress levels and everything like that. But I would we just wanted to ask if there was any influences to you that made you consider errors more important than perhaps other people. What were your influences? Yeah. So because I learned stand-and-know in a camel at school and then learned Haskell as a hobby,
00:42:37
Speaker
um I faced these like learning challenges where I ultimately felt really betrayed. we're like it It had the sound of it being complicated. And so even when I felt I was like, I can do this, I wasn't confident that I understood it. And so it took like a year before I was like, oh, that's what it was the whole time.
00:42:59
Speaker
And then like three years later, it's like, okay, Monet Transformers, that's what it was the whole time. And so I legitimately was like, on a personal level, I felt really betrayed um about my time being, or my confidence being suppressed.
00:43:16
Speaker
um The other thing is that when I was working at Notre Dame, one thing we thought about a lot is we always kind of had to apologize. We're like, okay, the error messages are a little,
00:43:28
Speaker
You get used to them, you know, and I think anybody who learned a camel or Haskell University knows like after some number of months, you look at it and you just you kind of get it, you know, it doesn't make sense to you, but it's like, I know what to do now. yay Yeah. um And we really were annoyed that we had to.
00:43:47
Speaker
be like, it'll be fine. our um So weirdly what happened is I was at a conference in Beijing, weirdly, and I was just like, ah, I have some free time. I'm going to work on getting my error message to go to JSON. And as I was doing that, I was like, you know.
00:44:04
Speaker
I could actually, this could be a lot better. And I started just like tinkering with the particular engineering details of it. And it all came from that like side route. And so that's another reason like I'm not so... giving roadmaps is that like the roadmap would have said, I'm delivering this JSON feature. But what I realized as I was going through the code, it's like, oh, we can actually give really excellent error messages. And like I don't want to close those possibilities off by making promises of like which is more important ultimately. you know like So i hope I hope that answers.
00:44:45
Speaker
Any more questions?
00:44:50
Speaker
dude sheized
00:44:53
Speaker
If you had to start over, what would you do different?
00:44:59
Speaker
So I think it was hard for me to come to understand this, but like I think I was naive about Thinking people would take care of me. And so like I knew the creator of Python. And I kind of saw his path of like he's sort of naively making the language. Some companies support him before the 2000 tech bubble. And like yada, yada. He works at Google. He works at Dropbox.
00:45:30
Speaker
And like I kind of yada-yada'd the, well, what happened to me? And like to think, like oh, what happened to the Python guy? That's going to happen to me, too. It's stupid. like why would i And I didn't think, like oh, yeah, that's me. But like I didn't question that that path was of a specific moment, of a specific technology, all that. And so I think i when I had situations that were working,
00:45:57
Speaker
i wasn't I was too trusting and I wasn't like doing what I needed to do to be in a good situation long term. Does that make sense?
00:46:09
Speaker
One final question. Yes.
00:46:13
Speaker
So and just linking to that question, then what's the number one recommendation you would give to some fellow developer who's getting into open source software and would love to keep going that way? Because I don't. Yeah, just that... um yeah
00:46:36
Speaker
A lot of companies who use open source use it as a a business tactic. right So like they have a freemium thing, but that's a pipeline into a paid service. And so and that's when you go back to the original documents about it. like That's what it's supposed to be, according to Eric Raymond. And so if you are really making sacrifices in your life and there's no path for that to come back to, like that's That's serious. like You have to solve that. Otherwise, you're not going to get to things you love to do. And so like from my own experience, like I was never the person who should have been in charge of a consulting organization. like I can be talent, but like I should have pursued finding a partner who can do that other side where we both bring something valuable. And also I also should have had the confidence of, like
00:47:36
Speaker
you know I'm like, well, what do I bring? like I'm just some guy who works in compilers. I'm not even that good at LM. I don't use it. I mostly write Haskell. But like when you bring a reputation or people who believe in you and you bring the expertise, that's like so valuable to a consulting firm that you know you can't let yourself be taken advantage of. And a lot of business people like will do it if you if you are naive about
00:48:08
Speaker
how they operate.
00:48:11
Speaker
yeah On that note, I think we're at time, so Evan Chablitzky, thank you very much.
00:48:20
Speaker
Thank you, Evan. You know, listening back over that interview, I feel like at points maybe I crossed over into fanboy territory. If so, I admit it. Take it as a sign of how much I've enjoyed using Elm over the past few years, and how much I've enjoyed teaching it. It's a very nice, clean design to work with, and that translates into a very clean design to teach people functional programming with, which is something I've greatly enjoyed.
00:48:47
Speaker
What I take from that interview is, I think Elm has a future, a good future, perhaps in a larger, somewhat different form, but I'm left optimistic for Evan's creations. I'm also, off the back of that discussion, I am somewhat looking to my own future. There are similarities, I see, between what he describes as an open source software developer um What I've experienced as an open source software content creator, if that's what I am, it's got me asking questions. I don't have answers, but it's the end of the year. It's coming to the end of 2024, and it's a good time to be asking those questions and thinking what's next in 2025.
00:49:29
Speaker
But for now, thank you very much to those of you ah who are actively supporting the channel on Patreon and YouTube memberships. I really appreciate your support and your active support of the future of Developer Voices.
00:49:43
Speaker
We'll be back next week with another episode. And then things are going to get a little bit tricky because I'm going on a speaking tour. I'm going to Melbourne, Brisbane, and Sydney at the start of December. I'm hugely looking forward to it, but it's probably going to disrupt the publishing schedule. So bear with me. And if you happen to be at the YOW conferences in Australia, I'll be there. Please come and say hi. In the meantime, I've been your host, Chris Jenkins. This has been Developer Voices with Evan Choplitsky.
00:50:12
Speaker
Thanks for listening.