[00:00:00] Richard: What I want is this sort of Elm like experience, but for this sort of long tail of domains, like yeah, web servers, but also like command line apps and native desktop GUIs and, maybe mobile apps, robotics.

[00:00:11] Jared: Hey folks, welcome back to Elm Town. I'm your host, Jared M. Smith. We'll be visiting with the always ambitious Richard Feldman today.

[00:00:20] Non-introduction

[00:00:20] Jared: Richard needs no introduction. He's done a lot for the Elm community, but if you're new, just to give a kind of rundown of some of the things that he's done, he is the creator of the Roc Programming Language and host of the Software Unscripted podcast. For folks. I'll set the context with , he's been an instrumental force for the rise of Elm. Some of his contributions include iconic talks such as "Making Impossible States Impossible" and "Scaling Elm Apps". He's given over 100 hours of teaching Elm in person. He's written a book, Elm in Action, presented two video courses on Frontend Masters.

[00:00:59] I asked him to join us to talk about how Elm inspired Roc. The fast, friendly, and functional programming language that's, quote, a direct descendant of Elm. Richard, welcome to Elm Town.

[00:01:11] Richard: Thanks for having me!

[00:01:12] Jared: Thanks for making the trip from Roc City.

[00:01:14] I wonder where Roc City is. There's gotta be some city somewhere named Rock City. I'm sure that exists. Right.

[00:01:22] Richard: Probably spelled differently.

[00:01:23] Jared: Yeah.

[00:01:24] Richard: with a K.

[00:01:25] Jared: There's at least Detroit Rock City, so.

[00:01:27] Richard: There you go, that's true, yeah.

[00:01:30] Jared: Okay, so to get started, I won't go through your full history. I think there's a podcast I will link to an episode you recorded with Lindsay Wardell on Modern Web where you kind of give more of the history of kind of getting started with programming in general. But

[00:01:47] Motivations to make Roc

[00:01:47] Jared: what experiences did you have leading up to the decision to make Roc? And guide us from there,

[00:01:56] the story of how it came to be.

[00:01:58] Richard: Like you mentioned, Roc is a direct descendant of Elm, and I would say that the three main motivations that led to wanting to make Roc were, one, wanting to use an Elm like language, not necessarily literally Elm, but a language that has, I don't know, what felt to me like the, uh, sort of, essential parts of Elm that I was looking for, in sort of other domains.

[00:02:18] So, besides, like, uh, front end web development. So that was one thing. Uh, I sort of knew that, like, Evan's approach to Elm is, like, if we're gonna go into a domain, like, uh, you know, front end web dev, or, uh, like, Elm on the server in Evan's vision, is, I think, really, really ambitious and exciting, and also different than what some people are looking for.

[00:02:37] Like, for some people, it's like, this is amazing, this is exactly what I'm looking for. And for some people, it's sort of like, I want something slightly different than this, or very different from this. So my feeling was like, okay, if Elm is never going to target like, Vim extensions, for example. Like, that's just never going to happen.

[00:02:52] That just wouldn't make sense for Elm. But whenever I sat down and say like, oh, I kind of want to try writing a Vim extension, I'm always like, I don't want to write Vim scripts, and then, you know, NeoVim now has Lua support, and I'm like, I don't really want to write Lua either. What I want is this sort of Elm like experience, but for this sort of long tail of domains, like yeah, web servers, but also like command line apps and native desktop GUIs and, um, maybe mobile apps, uh, robotics.

[00:03:16] Like there's all these different use cases where when you look at what's available in terms of programming languages, it's usually like, well, maybe you got like Lua or a JavaScript or like Python, but never really anything Elm like. So that was sort of a missing piece for me.

[00:03:29] Second motivation was there were some ideas that I had that, for one reason or another, were just never going to make it into Elm, and which I kind of wanted to try out.

[00:03:37] So in some cases that might be, like, this is a reasonable idea for Elm, but it's sort of too late. It's like, you know, if you tried this out on day one, maybe you could, you know, see if it was good or not. But, it's just like, Elm's, you know, it would break too many apps to try this out now.

[00:03:51] Another category of things , I talked with Evan about it, but it was sort of like, It fit my style, but not Evan's style, and so like, you know, you can only pick one way, obviously it's gonna be Evan's way.

[00:04:01] So, uh, so those are some things I was just curious to try out. So the big one there I would say is Roc doesn't have currying, and I talked to Evan about that. I was like, hey, I don't think, you know, Elm needs currying, and To make a long story short, Evan was not into that idea. But I was, so that's one of those things where you can only have one or the other. So I was curious to try things in that area.

[00:04:22] And then the third category of reason that I wanted to make Roc was just I was nearing the end of writing Elm in Action, and I was really looking for another like big project to sort of sink my teeth in that was gonna take a lot of time to work on. And Yeah, programming language sort of, uh, obviously takes a long time, um, but that was kind of an exciting thing for me.

[00:04:42] It wasn't like a downside, it was like, no, I, I actually really would love to do a really big, like, long term ambitious project like this. Um, so those are kind of the, the things that led to deciding to make a programming language.

[00:04:53] Back to the beginnings in 2018

[00:04:53] Jared: I wanted to ask about the timing here. I believe, according to the Roc language page, web page, there's the year 2018 on there. Is that when you started actually writing code for it?

[00:05:09] Richard: Uh, that's when I started designing it. That was sort of when I decided, like, okay, I'm actually going to do this. And so, I had this sort of general idea of, like, these goals that I mentioned, but I didn't really have any idea of how specifically that would turn into a language. One of the things that's really cool about Elm is that, and that I've always, like, sort of admired about it, is that it's really focused on this one domain, and then within that domain, everything makes sense.

[00:05:32] Like, you don't have these weird, you know, Primitives that you have to ignore, um, like for example, if you look at, uh, Rust compiling to WebAssembly to run in the browser, you have all these operations in the standard library that are around, like, file system I/O. They just don't make any sense in the browser, because you don't have that there.

[00:05:47] And I think for every different domain you can pick, you're always going to have some stuff like that, where some primitives make sense and other primitives don't make sense. And so I was trying to think, how can I sort of generalize this? Like if we're, if we're not going to make a language that's focused on one domain, how can we make it so that we can still get that sort of Elm-like experience of all the primitives make sense for the particular domain we're targeting?

[00:06:06] So this is where the, Roc's, like platforms and applications design came in, which we can talk about that later. But that's an example of something that I came up with in 2018. So the first line of code was actually January, 2019, but there was like quite a bit of design time before that, trying to figure out like, okay, concretely, what are the things that, you know, I want to, I want to put in this language.

[00:06:23] Jared: Yeah, I definitely would like to talk a bit about platforms, but kind of still going back to this timeline and the motivation here. 2018, you were working at NoRedInk, correct?

[00:06:34] Richard: Yes.

[00:06:35] Jared: And you were using, of course, Elm on the front end. By then, I'm sure you had quite a few hundred thousand lines of Elm code.

[00:06:44] And were you also using Haskell there?

[00:06:48] Richard: The timing here is definitely relevant because I don't remember if we had started using Haskell or not, but, one of the things that's definitely true is that the decision to use Haskell on the backend was one of the things that made me say, okay, I'm actually going to make a programming language.

[00:07:03] And the reason for that was, essentially, we had done this search where we were saying, okay, we're, we're unhappy with Ruby on Rails on the backend. We want to move to a different language, a more functional, statically type checked language, and we wanted something that was sort of simple, like Elm, like a simple type system and, you know, simple type system, purely functional.

[00:07:22] Uh, and you know, a language that's for backend web development. And we really couldn't find anything that sort of fit all of those criteria. And so what we ended up going with was essentially.

[00:07:34] Haskell, but try to do it in Elm style. The reason I say that was one of the motivations, or one of the things that led me to conclude I should actually make a language was that in that search I was like, why doesn't this exist? Like, how is it that, you know, this doesn't seem to be a thing that anybody's working on? And obviously there's a lot of languages that almost fit that criteria. Like, you could say, oh, like, OCaml's a good back end language, and it's like, yeah, but it's not purely functional. And, you do have this whole, like, object system that you're just, everybody just kind of pretends isn't there, like, kind of ignores. Um, I wasn't really looking for that.

[00:08:05] It's like, a nice thing about Elm that, that is, you know, really nice in terms of, ergonomics, but also just in terms of the feel of the language, is that there's no, like, Elm the good parts. You know, it's not oh, only use this subset of the language. It's like, no, actually, the language is just small in a way where all the pieces fit together and are useful together.

[00:08:22] Um, so, you know, that was, like, kind of a problem with OCaml. You know, F sharp, you have, again, like, another set of tradeoffs. You know Haskell has its own set of tradeoffs, Peerscript has its own set of tradeoffs, and we really talked about absolutely anything. but in the end, it seemed like, well, let's just use Haskell and try to use a subset of it was sort of like the option that made the most sense for us. But at the end of the day, I felt, look, there's people out there who want to do, you know, who want this experience to be good, and not just sort of, um, trying to take another language and use it in a way that it's not really designed to be used.

[00:08:58] Jared: That's really interesting. Yeah, I think Haskell is made in a way that made it possible for you to build an Elm like Haskell, right? But, at the same time, There were probably a lot of things that you had to decide where it was like, you're, it was almost like you got to play around with building a language, right?

[00:09:19] Like you're, you're like, well, we want Elm, but we, you know, we're going to use it in this particular domain. And so, you know, we, these are the particular pieces that we want to fit in there. Did you feel like you were sort of designing that? Like you were, this was like a precursor to building. You're like, wait a second.

[00:09:34] Like, I'm almost doing that.

[00:09:36] Richard: Um, I didn't really personally have a hand in that aspect of it. So, um, I know, like, uh, several people worked on the sort of, uh, like, our custom prelude, like, which is sort of the Haskell standard library variation. There was a mix of adding new things, so like the pipe operator, for example, and then sort of removing things or saying, like, let's not use these things.

[00:09:58] Um, so it's like simultaneously only using a subset of Haskell, but then also adding some other things that, you know, Elm had that, um, we were missing. So, um, given that I didn't personally work on the, sort of, the design of that standard library, it wasn't really a motive, not really a motivation, but it wasn't, um, for me it didn't feel like that was, like, really related to Roc.

[00:10:17] Uh, the main way that that related to Roc was just sort of the realization that, like, there's a missing piece out there in the world. And, like, even after Evan ships his, uh, sort of vision for Elm, quote unquote, on the backend, which is not what most people, you know, sort of, uh, think of when they hear that phrase.

[00:10:34] I figured there's, there's still going to be some percentage of people who want the sort of more traditional, you know, arguably less ambitious, um, version of a, of a backend server.

[00:10:44] Jared: Right. Okay. Yeah, that makes sense. So yeah, the, the motivation seems clear here to me. And I think that fits with a question that I often ask is what is the Elm equivalent on the backend? And so that's your, that's your answer to that, right?

[00:11:02] Richard: Well, I, I would say, I mean, so like I said, you know, Evan's got his sort of design for Elm on the backend and Evan's design is, I think mostly based on the observation that if you look at, like, you have an Elm frontend, and then you have a database. And obviously the database is necessary for persistent storage across multiple sessions and things like that.

[00:11:21] So both of those pieces seem, like, essential if you want to have some, like, you need a user interface and you need some sort of persistent storage. And Evan's observation was essentially, okay, then you have this web server in the middle. Like, what is it really doing, right? You have like, it's like, well, the UI sends some data to the web server, usually JSON, and then the web server turns around and sends, decodes that JSON, and then turns around and says, okay, let me turn that into a database query, and then the database comes back with this data, and then the web server turns that back into JSON to send it to the client.

[00:11:52] Sort of like, what, what's your job really? I mean, what's, what's the essential value that you're really providing here? And in that design, it's like, yeah, is. Is that really a thing? And so Evan's kind of idea was, could we just get rid of that? And just have, you know, essentially a Postgres extension or something like that where you're able to just write only Elm code and it's taking care of sort of end to end.

[00:12:15] And then you're just writing, describing in the client, like, here's what data I want to get out of the database. And then on the database you have some, you know, Elm code running that's taking care of authentication and all that stuff. and then that's it. And you've simplified your whole stack and a lot of sort of problems, um, and potential pitfalls go away.

[00:12:33] That's really cool. That's really exciting. Like, I think that's, um How a lot of applications just ought to work. It really makes a lot more sense than, like, the traditional model that we have in the web world. Um, having said that, I mean, like I said, I mean, there's also some percentage of people are never going to get on board with that, for one reason or another.

[00:12:51] And I'm not saying they are or are not correct, but rather that, if nothing else, I feel like having that option out there means that they're not, you know, at least they're not saying, Oh no, you know, I still feel like there's this missing piece. Or like, you know, Evan, when are you going to add the more traditional thing to go on top of the thing you actually want to make?

[00:13:10] So I see it as sort of like, this is not necessarily the obvious answer for people who want to, you know, who like Elm on the front end and want to have an Elm like back end, but rather that it's like, for people who want the Elm like front end and then, for one reason or another, the thing that Evan's making, you know, don't make sense for them.

[00:13:26] Jared: right. Yeah. I guess what I'm thinking of is on maybe on other platforms, right. On On a more general, uh, set of use cases where it's like, well, maybe I want it to be inside of, inside of a, um, uh, container on a, you know, something on AWS, like you want to have the, that control of where you place that. I think that there's a more sort of industry expected direction. And so I think, you know, of course, Roc is ambitious in a lot of different ways, but something that platforms make possible is this ability to say, yeah, do I want to build a Vim extension? Or do I want to build a web server? Or do I want to, whatever the case may be, and use this particular language.

[00:14:20] So

[00:14:20] Richard: One way to say it is that if you're trying to migrate from an existing backend, like, um, NoRedInk is in that position, um, then one of the advantages of this approach is that it means that you can not only, uh, have a like, like one option that you can always do, which is what we ended up doing with Haskell, is you can have sort of a separate server that runs the new language and then the frontend talks to some combination of the new and the old.

[00:14:46] Or, in Roc's case, you have the ability, since Roc is quite good at being an embedded language, where you can sort of run it in the same process, the idea would be that you can have more granularity there. So you can say, for example, I can, from my Ruby code, just more directly, more easily, just call a Roc function rather than having to have a whole separate service and stuff like that.

[00:15:05] And that is something that's possible with Haskell. So Brian Carroll actually made a little proof of concept of doing direct Ruby to Haskell FFI. I don't actually know if that's in use in production, but it is definitely possible. Um, but Roc is designed to be sort of good at that, whereas Haskell, it's like it supports it, but I don't know if that's something that is, uh, I don't know, really an intended use case, I guess.

[00:15:25] How Roc compares to Elm

[00:15:25] Jared: So let's talk a little bit then about what Roc is and how it compares to Elm.

[00:15:32] Richard: The biggest difference between Roc and Elm is just that Roc compiles the machine code, uh, and not JavaScript. And that's by design. And, and some, you know, we get asked periodically like, Hey, when will Roc compile the JavaScript or to the BEAM, um, or JVM? And my answer has been consistently, like, I don't wanna do that , um, it compiles the machine code or web assembly, which is kind of, you know, more portable machine code.

[00:15:53] But that's sort of the level of abstraction we wanna target. Um, so basically, uh, the. That has a couple of interesting implications. So one thing that people commonly say is, Oh, couldn't Roc just compile to WebAssembly and then you could run it in the browser? Which technically is possible. But one of the things I learned from Elm is that Targeting the browser is a lot more complicated than just like, Oh, you literally have something that's able to run in the browser.

[00:16:19] There's just like a lot of considerations and a lot of care that has to go into doing something like that. one thing that I discovered, uh, I don't know, a couple of years ago, is that if you want to do The Elm Architecture in Roc, it actually doesn't really work, or at least it can't work quite in the same way for a couple of reasons.

[00:16:35] So one is that Lazy in elm/html relies on using persistent data structures behind the hood. And if you don't have persistent data structures, then you can't do the cheap reference equality check to see if, um, if you need to, like, if you can skip rendering a bunch of stuff. Now, Roc does not use persistent data structures, which arguably maybe this is actually the biggest difference.

[00:16:57] I don't know, it's one of the two, probably the machine code or the lack of persistent data structures. But one of the other experiments that we're trying in Roc, um, is this idea of opportunistic mutation. So basically, rather than having persistent data structures, so like in Elm, you have like a persistent list, it's like a persistent linked list for your basic sort of, you know, sequential data structure.

[00:17:19] And then you have like Dict and Set are also both persistent data structures. And in Roc, uh, none of those are the case. So in Roc, instead, what we have is essentially, Once you, uh, create some sort of Roc value, initially, it gets a reference count of one, meaning only one thing is referencing it. Later on, it can get shared in multiple places, but, uh, if it ends up that you try to do something like a, you know, List.set, uh, to like, you know, set some particular element, uh, to a particular, uh, value, then it's not going to, uh, well, it's either going to, like, deeply clone it, or if there's only a reference count of one, then we know, well, look, nobody else is referencing this, so. If we just mutate the one that we've got, nobody's going to know, and then return that one.

[00:17:59] It's going to be unobservable. And so the idea here is that, hopefully, and so far this has turned out to be accurate, thankfully, The idea is that this lets us, in practice, get a lot closer to, or even compete with, languages that have imperative, just mutate everything type of performance. However, this does have a downside of certain things that Elm does, like Lazy, um, don't, like, just work the way that they do in Elm.

[00:18:28] So there's, there's sort of a different set of trade offs there. And, so, as a consequence to this, um, this means that, like, you know, Roc is maybe useful in a different set of domains. And, personally, I'm fine with that because, although, another thing I get asked about is, like, Hey, I want to do, you know, Roc in the browser because I want to have the same language on the front end and the back end, which, personally, I think is kind of overrated, but whatever.

[00:18:49] Um, I do think that it's a relevant consideration that like, it's, you're not going to get the same exact Elm experience if you were, even if somebody did create like a virtual DOM Roc thing. Um, just because there's, there's just different trade offs there. So yeah, it's, it's, uh, it's a complicated landscape.

[00:19:06] Jared: Yeah, that's really interesting though. So, of course, there are ways that Roc diverges from Elm, but are there any particular principles from Elm that continue to guide Roc in which you've said no to certain things because of those principles?.

[00:19:27] Richard: I mean, definitely the, the biggest principles to me are sort of aiming for a sort of small set of simple primitives. I mean, like Elm's logo is the Tangram because It's a small set of simple primitives that you can make surprisingly many things from. Roc's logo is sort of an homage to that. It's an origami bird, because a Roc is a type of mythical bird, and that is R O C, is a mythical bird.

[00:19:49] Also spelled R U K H, depending on which language you, uh, you look at. But at any rate, um, it's a mythical bird, and origami, like tangrams, Origami is like similar but not the same to Tangrams, but they have that shared sort of foundational thing where it's like you have a small set of simple primitives that you can make surprisingly many things from.

[00:20:07] Um, so basically I think that is the essence. If I, if I had to pick one thing, it's just a small set of simple primitives. One of the things that, uh, Roc does do differently from Elm is we have a different set of I guess, like, stylistic things? So, partly that's some syntax sugar in the language that's a little bit different from Elm's.

[00:20:26] Um, so we recently introduced this exclamation point operator, which is for chaining tasks together. Um, chaining tasks together comes up a lot more often in, like, if you're not using Elm architecture. Because, like, in Elm architecture, oftentimes you're chaining things together with, like, commands and messages and stuff.

[00:20:42] And so, like, You know, Task.andThen it comes up, but it's like not that common. Whereas in, if you're making like a sequential script that's just doing a bunch of IO, it comes up constantly. And so, uh, for use cases like that, which Roc is targeting, that's something where we have a, a real need for, or maybe a lot more of a demand for, um, like making that really concise.

[00:21:05] So we just added that pretty recently, and that's been like a big hit. But that's something which I don't think Elm needs that. I don't know. I mean, yeah, you could do something like that, but it just wouldn't come up that often. Similarly, we also have some different stylistic choices, which kind of just have more to do with my personal preference, I guess.

[00:21:23] So, like, records use colon instead of equals for the fields. Personally, I like equals being reserved for assignment and not being in there for records. I think both are reasonable, but that's just a little personal preference. We also have trailing commas instead of leading commas from the formatting perspective.

[00:21:41] That's actually how I used to do things in Elm. Originally, when I first started writing Elm, before elm-format existed, That's how long I've been using Elm. Um, But when, uh, Aaron started working on, um, elm-format, uh, he was, well actually, so the way that this happened, we were at the Elm Meetup in San Francisco, and, There were two people, uh, Jeff Smits and Aaron VonderHaar who were there and Evan had been talking about how we should have something like gofmt, like "Go format", um, because it's like a really cool thing, uh, and I didn't really know Haskell, so I didn't feel comfortable trying to write that, but I was really excited about the idea and I was talking to Aaron and Jeff about that and saying like, hey, you know, you guys know Haskell, do you think you'd be interested in collaborating on making this exist?

[00:22:22] And Jeff said, well, I'm going back to Amsterdam in a bit, so I'm not going to have, you know, bandwidth for that, and Aaron said, I think I could solo it. But I need a spec. Um, and so, I was like, oh cool, well I know that Laszlo Pandy wrote this Elm Style Guide, so if you want, I could just sort of translate that into a spec.

[00:22:37] So I basically just like, wrote up like, a detailed specification from that, and Laszlo had said like, okay we're doing, you know, trailing, uh, leading commas rather, like commas at the beginning of the line, etc. So, even though that wasn't my personal preference, I was like, this is my thing. Yeah, the idea is like, let's just like have something consistent, um, but I figured like, you know, if Roc's going to be different from Elm, then I can, I can switch it over to my preference.

[00:22:59] It'll be fine.

[00:23:00] Jared: Okay, cool. Yeah, so I wondered what the origin of the Elm style guide was. So that's, that's good to know. I hadn't heard that story before.

[00:23:12] Richard: Yeah, I'm sure you could find it somewhere. Um, like Laszlo I think wrote it in like 2013, 2014 maybe. He was Evan's uh, manager at Prezi. It was like Evan reported to Laszlo who reported to the CTO.

[00:23:24] Jared: okay.

[00:23:24] Richard: Yeah, he also made the uh, first version of the time travel debugger. Laszlo did.

[00:23:30] Jared: Right, yeah.

[00:23:31] Richard: Yeah.

[00:23:32] Jared: Cool. Going way back.

[00:23:34] Richard: Yeah. There's, there's a video online of him present of Laszlo presenting the time travel debugger somewhere.

[00:23:39] Jared: Yeah, I think that used to be on the Elm website, wasn't it?

[00:23:43] Richard: yeah. I forget what the URL was. Um, yeah, the Mario demo.

[00:23:49] Jared: Yeah, exactly. That's cool.

[00:23:51] So, I want to go back to what you were saying about this particular operator, because I wanted to mention an article that you wrote, uh, recently called Functional Semantics in Imperative Clothing. I'll put that in the show notes, but I think that's a good demonstration of why that, uh, particular, uh, tool is, is useful.

[00:24:13] And so, yeah, I'll, I'll put a link to that.

[00:24:16] Richard: Yeah, that's a great example of Roc wanting to target different domains than Elm. It was like, literally, we had a bash script. It was like a dot sh script, and we wanted to port it to Roc. It's like, I mean, you could port that to Elm, but like, you know, it's not, it's not really what Elm is designed for. Uh, whereas Roc, like, that is actually something that I've always wanted Roc to be good at.

[00:24:37] I would like to be able to just write, you know, the scripts. And at the end, like, after we added that syntax sugar, it ends up looking, like, basically the same as the bash script, except, I think, actually a little bit nicer, in part because we have much nicer conditionals than bash does. and then, you know, you get the full power of, like, everything's statically type checked and type inference and, you know, functional style and all that good stuff, so yeah, that's uh, that to me was like a really exciting moment for, I mean, it's like a bash script, it's like, you know, who cares?

[00:25:05] But I was excited.

[00:25:07] Jared: I think it is exciting. It's, it's just, um, a good explanation and simple enough that it's easy to grok. So. Yeah, cool.

[00:25:18] Minimizing the erosion of simplicity (governance models)

[00:25:18] Jared: So, I wanted to now talk a little bit about how you govern Roc compared to Elm, and particularly because it's something that you said about how you want to keep a small number of primitives, and one of the things from the page about governance in Roc is, quote, you want to find a system which minimizes the erosion of simplicity.

[00:25:44] Do you want to talk a little bit about that?

[00:25:46] Richard: Sure, so, um, I think the page you're referencing is, uh, slash BDFN on the, uh, on the website, roc-lang.org. Yeah, so I, I use this term BDFN, meaning Benevolent Dictator For Now. Um, so basically, my plan is that I want to initially, like, while the language is sort of, you know, getting up and running, um, be the, like, Benevolent Dictator.

[00:26:06] Basically, the way that works in practice is like, we kind of, like, everybody who's involved in Roc, uh, like, the sort of core contributors, we don't have, like, an official core team or anything, but, um, the people who've contributed the most, we, we sort of talk about everything, um, uh, in Zulip, pretty much, Zulip chat, um, but basically, uh, I sort of have the last word, so if we can't come to some consensus, which we usually can, um, then at some point, it's like, it's on me to make the final decision.

[00:26:31] But at some point, uh, like sometime before I die, hopefully, um, I would like to transition that to something, some different model that can sort of outlast me. And my hope for that is that it can be some sort of system that doesn't fall into the trap that a lot of sort of, uh, languages that are, in that sort of mode where there's not one person running it anymore seem to fall into which is where they just eventually just creep and get more and more features over time just like a little bit more a little bit more a little bit more and then you're you know fast forward 10 years and it doesn't matter how simple the language used to be now it's a complicated kitchen sink language. And it seems like a lot of, that that seems to be the sort of default thing that happens over time to languages that have sort of a committee running them. So my hope would be that sometime and I don't I don't personally know exactly how this would look.

[00:27:22] I consider this to be an unsolved problem, like, globally right now. But my hope would be that you can end up with some sort of, I don't know, conservancy model where the goal is try to avoid adding features at all costs. Well, not at all costs, but the challenge there is fundamentally that Almost certainly, the correct number of features to add to a language over time is not zero, it's just low.

[00:27:46] Because sometimes, I mean like, you know, you get hardware changes, right? Hardware changes can influence software changes, which can mean that sometimes it makes sense to add a new thing to a language. You know, the environment around you is changing, so probably at some point it's going to make sense to change some things.

[00:28:00] The question is, how do you minimize that? Because unfortunately, it seems like there's often a dynamic that happens where You have this committee of, let's say, ten people. I guess it's usually a lot more than that, but, um, ten people and one person says, I want, I want this feature added. And the other nine people say, well, we don't want that feature added.

[00:28:17] And even if everybody has the mindset of like, let's, let's try to minimize features added, at some point you kind of, you know, if you have like a voting system, you end up with incentives where one person says, hey, hey, If you vote for my thing, I'll vote for your thing, alright? Yeah, then I can get my thing in, and you know, we're gonna get your thing in too, but whatever, I don't care.

[00:28:33] Um, and then, one thing leads to another, and before you know it, you know, you're adding features left and right. I don't know how to prevent that, but I hope we can figure out some sort of system for doing that. I actually think, weirdly, um, Evan made a really good observation about language specifications, which is, he was talking about Standard ML and how they had a language spec, and he pointed out that arguably that has sort of inhibited Standard ML from evolving as fast as it could have otherwise, because you have, because changing the spec is like a much more challenging process when you have different implementations out there.

[00:29:11] That actually sounds pretty appealing, once the language gets to that point where you want to minimize changes, where if you can get a spec out there and get multiple implementations, um, then, uh, you know, that can potentially be a tool for making it harder to add things. Uh, but then again, I mean, I look at languages that have, you know, big specifications like C++ and stuff like that, and like Java.

[00:29:31] It's like, well, They're still adding plenty of features anyway, so So yeah, I don't know what to do about that, but yeah, hopefully That's sort of natural erosion of simplicity. There's some way to prevent it from from getting out of control We'll see.

[00:29:47] Jared: yeah, that's interesting. That does sound like a challenging problem, but hopefully one that that's a figureoutable. I'm sure it is.

[00:29:56] Richard: I hope so. Yeah

[00:29:58] Jared: So that actually makes me think about an episode of Software Unscripted that you recorded about industrial design with Greg Wilson, where he talks about how earlier on in Python's evolution.

[00:30:13] It was a good language for teaching programming, but over time, because it's become more used in industry and just simply that, you know, designed by committee process has now added a bunch of new features. And so it looks a lot different. There are always new things being added, which, yeah, of course, erode that simplicity.

[00:30:36] So

[00:30:37] Richard: Yeah, I mean, I remember thinking, um, when Guido announced he was retiring from Python, thinking, well, you know, so far it seems like Python has not gotten out of control, but even though it's, you know, like a 30 year old language, um, but who knows? Now, now that there's not one person at the top saying no to things, uh, you know, what's going to happen?

[00:30:59] And I don't know, I mean, I guess, I guess we'll find out.

[00:31:02] Jared: right. Yeah, so that makes me think, because Greg also mentioned another language, Lua, that has kept a few, fewer number of, of, uh, features, so I don't know the governance model there, though. Maybe that

[00:31:19] Richard: Yeah, me neither. I don't really know much about Lua. Um, I mean, I know some like tidbits here and there, but I've never really used it. I've never, yeah, I don't really know.

[00:31:27] Jared: Yeah. Now I'm curious. I'm going to have to look that up and see if it, if it's different, if maybe that might have some influence on it, but Anyway, okay, so

[00:31:36] How teaching Elm informed Roc's design

[00:31:36] Jared: Let's move on to overcoming barriers with gaining users of functional, of a functional language like Roc. So how has your experience teaching and talking about and being an early pioneer of Elm affected how you approach solving those problems?

[00:31:53] Richard: Hmm. So the main two ways, and.

[00:32:00] these are gonna sound kind of, I don't know. Maybe surprising to some people. But the main two ways that they affected Roc are in two pieces of language design. So, like you mentioned at the start, I've spent over 100 hours in person, in a classroom, teaching people Elm.

[00:32:19] And these are people who didn't know Elm before, just beginners. And, uh, this is like, I did Frontend Masters. I did, uh, a bunch of practice runs for the Frontend Masters thing where I would go on, like, weekends when I lived in San Francisco and I'd just go to, like, a local boot camp and just be like, Hey, come in for free over the weekend and I'll teach you Elm.

[00:32:34] Um, did, like, Women Who Code and, uh, Yeah, anyway, so, um, I got a lot of data points around, first of all, trying different things, like I would experiment with different teaching techniques, um, and then also with, like, what are the things that I consistently saw people getting tripped up on. And the things I saw people getting, like, beginners getting tripped up on, um, fell into a few different categories.

[00:32:54] So one was, like, they would trip over it, but they would kind of get used to it pretty quickly. So a really good example of this is the parentheses. So a really common thing that people would mess up is, out of habit, they'd say, like, foo, immediately open paren. And then, you know, put some stuff in there.

[00:33:09] Maybe they'd like put commas between the arguments. But the thing is like, you know, if you have nice enough error messages, then people would just kind of figure that out pretty quickly and just, you know, get in the habit. So that's fine. I think that's kind of normal learning curve stuff. The two that I thought were a bigger problem, um, were one is like the two biggest things that, uh, that I saw beginning to struggle with where like by the end of the eight hour workshop, I would think I don't, they don't really get it.

[00:33:34] Um, they don't understand how it works. Uh, one was JSON decoding. Um, and I know, uh, I mean, I'm personally responsible for JSON decode pipelines. So I, I, I have to take some blame for that. Um, on the one hand, like the sort of schema like design, um, looks pretty nice when you're like in a big code base and you, you want that flexibility.

[00:33:56] But as far as a beginner learning experience, the, the, the types are just really confusing. I mean, I would sort of walk through an explanation of like, okay, now see, it's like applying one more and one more. Um, But I could just see from people's expressions that they just don't get it. And even, honestly, like, intermediate to advanced people a lot of the times don't understand how the types work.

[00:34:18] They're just sort of like, I don't know, somehow it works, just don't worry about it, just use the thing and it's fine. Um, which on the one hand, I mean, Based on what its purpose is, which is to sort of look like a schema, it works for that. But on the other hand, it always bothered me that people were using it and not really understanding how it works.

[00:34:35] It just feels sort of magical. So that was one of the things that I was like, okay, is there some way we could sort of get rid of that aspect of the learning curve? Because even if you're writing, Non UI stuff, things like serialization, deserialization come up in all sorts of different domains. So that was one piece.

[00:34:52] The other thing that I saw beginners struggle with was currying. And this is something that always comes up in intro workshops because as soon as you have a function with multiple arguments, You have to explain why there's multiple arrows in the type, and if you don't explain that, somebody's gonna ask about it, and then, you know, so, so you end up, uh, needing to explain that, and again, this was one of those situations where I'd have this whole spiel that I would go through where I would show it one step at a time, and at the end, some people would get it, but it was generally a pretty small minority.

[00:35:20] It seemed like most of the class, in general, would, after watching me go through the whole explanation of how currying worked, they'd be like, Every individual thing you said made sense, but I still don't get it, like, intuitively. And then, now, to be fair, it wasn't like the end of the world, because they wouldn't generally walk out of the class totally confused.

[00:35:38] It would be more like, I don't really get the currying thing, but I don't know, it seems like not a big deal. And then eventually it would click, like much later, but, um, or some amount later after the, after the class was over. Um, but again, it always kind of bothered me that it felt like I had to go through this whole explanation, and then, you know, at the end, people would still not really get it.

[00:35:58] So Roc addresses both of these in different ways. So on the encoding and decoding side, um, we do have a language feature called Abilities, which lets you, well, without going down a huge rabbit hole, um, basically there's a way that you can do JSON essentially using type inference. So you can just say like, here's my user, just call decode, say, I want to decode using JSON.

[00:36:19] Um, and it'll just kind of do the same thing that, uh, that, uh, Decode pipeline does where it goes through and like, finds all the fields and you know, um, you know, expects them to be there the way that based on how you use it, um, in your code. So the learning curve on that basically just goes away. You just don't have to explain any of that.

[00:36:35] You just say like, just call decode on, you know, JSON and it'll just take care of it for you. Um, and then same thing with currying, it just took currying out of language and so, there's no need to explain that either. so those are the two main ways that, teaching Elm a lot, like, and sort of onboarding people to functional programming, um, influenced Roc.

[00:36:52] Now actually, I will say, um, this exclamation point operator really gave me an interesting new perspective, which is something I'm about to experiment with soon, um, when I'm, uh, when I revise the Roc tutorial. The exclamation point operator essentially works like async await, or it looks like async await, it looks like the, uh, the await part, except instead of saying await space and then your thing, it's like you put an exclamation point at the end.

[00:37:14] That's basically it. So it's like foo exclamation point is similar to await foo. what the piece of feedback that I got was, um, that my explanation of this, which I explained in that article that you, uh, I guess will link to in the show notes, uh, Um, Functional Semantics in Imperative Clothing, It's just syntax sugar.

[00:37:32] It literally desugars to the equivalent of Task.andThen in Elm. Um, and I thought that that was a big selling point. To me, I'm a big fan of syntax sugar in the sense that, um, It means that you can still have a small set of simple primitives, But, uh, where, you know, you learn how they work and then you kind of got it, uh, but you can make the code look a little bit differently.

[00:37:53] And so, uh, you know, It's, in my mind, sort of a different category of thing. If it's like, you cannot get these semantics any other way besides this language keyword, versus you actually can write this one of two ways. This one is just a convenience for the other one, because that means that I don't have to think about like the rule set being bigger, if that makes sense.

[00:38:13] It's like, well, no, this is, this is the same set of rules that I have to, that I have to keep in my head. It's just that like, oh, this, this is like a slightly different way of doing that. Kind of similar to a function call. the feedback that I got was that, um, someone actually found the concept more confusing because I had explained the sugar.

[00:38:31] As opposed to, um, so I was asking like, hey, and this is coming from an imperative background, um, they're saying, yeah, like once you got into that whole syntax sugaring thing, it started to look like, you know, this is like callback hell where you have all these nested callbacks. And I was like, well, yeah, but the point is you don't have that because you have the syntax sugar that fixes that.

[00:38:49] Um, And I said, Well, what do you think about async await? Do you have the same barrier there, like with the mental model? Or does async await feel kind of more natural to you? He said, Oh yeah, async await feels totally reasonable to me. So I thought, Huh, maybe we should try teaching it as if it's just async await.

[00:39:05] Um, or, or, in other words, like, don't explain the sugar, um, in the beginner materials. Maybe later on, you can explain, hey, by the way, this is just syntax sugar, you know, just desugars to this. But maybe for beginners, it's actually easier if you don't explain that. You just say, well, anytime you want to do an effect, you put the exclamation point, and that's it.

[00:39:21] Um, I think that's really interesting, because it's not something that I would have guessed. Um, but it is the type of thing where, um, You know, you change the language and now maybe there's a different, maybe there's an opportunity to lower the learning curve even more for somebody coming from an imperative background.

[00:39:36] Um, and obviously at some point you have to understand the mental model of like, here's what tasks are and I want to transform them in these ways before I run them, um, to do error handling and concurrency and things. but yeah, maybe it's better for beginners coming from imperative backgrounds if we don't explain that up front.

[00:39:51] Jared: Interesting. Yeah. Don't, don't show what's happening behind the curtain. Just Let it

[00:39:56] Richard: Or, or at least not, not early on, maybe later on, you know,

[00:40:00] Jared: Yeah. Would the compiler error messages be the same, regardless of the syntax you used?

[00:40:07] Richard: Uh, currently they are, although we actually want to try to special case the exclamation point ones more, um, just to try to sort of present it more in terms of like what you're seeing. When we first built the feature, it was one of those things where we're like, this is an experiment, we don't really know how it's gonna go, but um, we'll try it out, see how it goes, and uh, fortunately it did seem to go well, so now we can kind of invest in it more, but at first we didn't know.

[00:40:31] Jared: Sure. Okay.

[00:40:34] Design process

[00:40:34] Jared: So, this kind of leads into another question that I have. It's about the processes you use to discover new designs. And from the episode of Software Unscripted guest hosted by José Valim, it's, you said, quote,

[00:40:50] "something that I learned from Evan is a good way to think about programming languages, that every programming language is in some sense, an experiment" which we were just talking about.

[00:40:59] "You have an hypothesis that something's going to be good and good experience are going to go well, but you don't really know until you try it out and people use the language and then you find out." End quote. So obviously this is an example of that, but what, is there some, like, how do you get a sense of knowing that it's working out?

[00:41:21] Do you just kind of gut feel or is there like some, uh, of a more clear process for that?

[00:41:30] Richard: that's a great question. I, I would say it's mostly gut feel. So that's a mix of seeing what people's reactions are and then trying to interpret those reactions. So sometimes, um, people will say, you know, I don't like this. It feels weird. Um, sometimes people will say, uh, this, this feels great. I love this.

[00:41:49] But the interpretation part comes in because if I were to look back at a number of changes that we've made to Roc, um, There's quite a few things where, right when we made the change, there was a decent amount of negative feedback. People saying, ah, I'm not sure about this. And then later on, people were like, oh, actually that was fine, I got used to it pretty quickly.

[00:42:09] Like, I didn't, you know, it was inconvenient. Because that's the thing, change is always a little bit uncomfortable innately. The question is like, you know, is it worth it later on? So, actually, currying is a really good example of this, because, if you ask people who've been using Roc for a while and who used a language with currying before that, um, actually, like, much less than 50 percent of the Roc community has used Elm, uh, which is surprising to me.

[00:42:30] I would have guessed that it would have been a lot of, like, Or mostly, um, people who are like, Oh, I like Elm and I want that experience in other domains like me. Um, but it's actually a huge number of people who are like, this is their first functional programming language or, um, maybe they'd like dabbled in a few languages before.

[00:42:45] And this is the first one they've actually sort of used, um, seriously. But, um, which is great. Like, and, and I also hope that there can be some like cross pollination there where I'm like, Hey, if you wanted a really nice language for making UIs, you should use Elm. Um, But, uh, but basically I, uh, I have seen a pattern already where, um, people who are used to languages with currying, who try out Roc for a while, they just like forget that Roc doesn't have currying after a while.

[00:43:13] It's just like, some, somebody new will show up, um, to Zulup and be like, Hey! Roc doesn't have currying, like, really? Because that's something I use all the time. And then someone will just chime in and be like, You know, I thought the same thing, but it's totally fine. Like, it's not. You just get used to it very quickly.

[00:43:30] Because, I mean, part of the reason that I had this intuition that that would be an experiment worth trying was that I remembered from my experience with Elm just thinking back on like, How often do I actually use this? And it kind of broke down into two categories. One is, obviously, the pipe operator I use all the time, and Elm's implementation of the pipe operator relies on currying, but you don't have to do it that way.

[00:43:50] You can just do it as, like, the pipe operator is its own thing, which is how we do it in Roc. So, you still get the pipe operator, so that part's fine. Um, and then separately, I would, like, very occasionally partially apply something when passing it to a higher order function. Um, and, yeah, it was convenient in those cases, but It's just, it doesn't come up that often that it's like, I really miss it, and I definitely appreciate the sort of simplicity of not needing to teach it and also not needing to, um, deal with the occasional error, like, compiler error message that's like, Like, so in Roc, if you don't pass enough arguments to a function, it just says, hey, you forgot an argument, right?

[00:44:26] Whereas in Elm, it can't say that because you're always allowed to leave off an argument, and that just curries it, and then you, You know, you get used to the sort of pattern of error message where it's like if you see this really long type but one of them has like a slightly different, like, oh no, I forgot an argument.

[00:44:39] I, I know what that means. Not a great beginner experience and even as an advanced user it's just nicer to just see the like, you forgot an argument, that's it, you know. Um, so yeah, there's trade offs in both directions but that's an experiment I think has worked out but again there's no, there's no like objective way to do that.

[00:44:55] Um, it's really just kind of like, do I feel that it's, it's worked out and in that case I think so, yeah.

[00:45:01] Jared: Okay, cool. So.

[00:45:04] Working at Zed Industries

[00:45:04] Jared: One of the things that I wanted to talk about is you recently announced that you will be working at Zed Industries.

[00:45:12] Richard: That's right.

[00:45:13] Jared: Yeah, so the, editor, the Zed editor, which I've now started using as a daily driver since, uh, the, uh, the Elm integration is there. And, uh, it's just, yeah, it's just amazing. I was able to go from Atom which I was still holding on to up until this year where everybody else had moved on to VSCode.

[00:45:36] Richard: Oh, wow.

[00:45:37] Jared: I just, yeah, I just was like, uh, I know it's so close. It's so close. And then when they opened it up and the Elm integration got in there, I was like, all right,

[00:45:47] Richard: Well, you know it's the same team, right? It's the same people who made Atom that made Zed.

[00:45:51] Jared: Yeah, yeah, exactly. So, so I was

[00:45:54] Richard: there.

[00:45:55] Jared: Yeah, I guess it really fits with, with how I like to work, but yeah, I just, um, I find that really exciting.

[00:46:04] So I want to talk a little bit about how, how do you hope that, that change will shape your work with Roc?

[00:46:14] Richard: So, the main thing that I'm hoping that working at Zed will do for me in Roc is that it will teach me about, or give me some hands on experience with, um, editors in general, and then also more broadly, uh, like native desktop GUIs. So these are both two domains that I want Roc to be good at, and also two domains that I don't really have any significant personal experience with.

[00:46:36] Um, so getting to just like, sort of do that type of work in anger, like day to day, um, I think will really help me out with, uh, like being able to make Roc good at those things. So I already mentioned earlier, like I had this, uh, Going all the way back, I had this motivation of like, I want to be able to use Roc for editor integrations, like writing, you know, VimScript alternatives, um, and like editor plugins and stuff.

[00:46:58] Um, also, uh, Roc itself is a language that I want to have this concept of like editor integrations baked in. So I've, I've been saying this for a while, but I have this goal of, It should be as easy to write an editor extension for Roc as it is to write a function. Like, you type your function, you press enter, you go down the line, and you're like, Alright, now I'm going to write an editor extension, and that's it.

[00:47:18] And when you install a package, you get the editor tooling with it, and this is something that, um, at first I thought we were going to have to make our own editor to do this, and then I later realized that, uh, for accessibility reasons, that's actually not true. So basically, uh, the goal is that when you install a Roc package, you get the source code, of course, and you also get the, um, the documentation, and then also you get editor tooling that's specific to that package.

[00:47:42] Like, if you have regular expression package, you have some tooling that'll let you sort of ideally, like, scrub through and see how the capture groups are working out and stuff like that. And just, like, play around with that in your editor. Uh, and then, you know, you can imagine, like, all sorts of different use cases for, uh, like, package specific integrations, which is not really a thing in any language right now.

[00:47:59] Um, at first I thought to do this we'd have to do our own editor, but what I realized is that well, when you think about Um, screen readers, like somebody, uh, who's using a screen reader and trying to edit their code. If we don't design that extension API in a way where by default, it's friendly to screen readers, then people with screen readers are just going to be out of luck because that's just how, that's how things tend to work in practice.

[00:48:22] Um, so it's gotta be kind of like HTML, uh, default screen reader friendly. And what I realized is that if we have an API for designing Roc extensions, that is friendly to screen readers, then it's sort of automatically going to be sufficiently generally specified that it can work across different editors like Vim and Emacs and Zed and VS Code and whatever else.

[00:48:45] So putting all that together, um, like those, those are things that I think I want Roc to have, but I don't actually know how to do that right now. Like I don't have any personal experience in like designing editor extensions. I don't really know, like, What the different trade offs are that editors are making, like in terms of how they're running their extensions and what's made available and so forth.

[00:49:05] And working at Zed should give me a lot more experience with that. Second thing is, um, native desktop apps. Like, it's always kind of bothered me, and I've talked to a lot of people who are bothered by this too, that, um, You have like a music player or like a chat client or something like that, and it's this big bloated electron app that takes, you know, gigabytes and gigabytes of memory and it feels like it shouldn't for like what it's doing, especially when you have like Winamp, which apparently just recently they released the source code to that, but I remember back in the day, Winamp, uh, just would run on my, like, 133MHz single core Pentium and, you know, it was fine.

[00:49:40] And, and now, obviously, like, you couldn't even run, like, a modern, uh, Electron based music player on that machine. Um, it's doing the same thing, it's just playing music, you know, one track at a time. Um, so yeah, I would love to have Roc be an alternative to those things, but again, that's a domain that I don't really know that much about.

[00:49:58] And fortunately, Zed is doing that, uh, taking an approach to cross platform native desktop GUIs that I would want someone to take, which is just going all the way down to like graphics card plus operating system APIs on each target operating system and that's it. No, you know, web browser layer in between that, just really like the minimum number of layers possible.

[00:50:20] Um, and so my hope is that we can use that to make a really good Roc experience on top of that.

[00:50:25] Jared: Yeah. Yeah. Both of those are really exciting.

[00:50:28] Platforms

[00:50:28] Jared: So kind of going back to the, the idea of, When you install a package, having the editor have something available there that goes along with that package to, to interact with it. So do you, do you expect there to be, and this, maybe this question, it would make more sense if we talked a little bit about platforms as well, because I think I, I also am curious about the discoverability of those.

[00:51:03] So maybe you want to talk a little bit about how platforms work and

[00:51:07] Richard: Sure. Um, so basically, uh, in Roc, we have the concept of platforms and applications. An application being essentially the, the, the thing that you're building that gets run. Uh, so, you know, in Elm, this would be like your elm.json, you know, for, for building an application. Um, and then you have a platform that you're building on, and that's a concept that doesn't really exist in Elm.

[00:51:27] The platform is essentially, um, It's kind of like a domain specific framework in the sense that like it might be like a game engine for example It's like this is I'm building a game. So I'm gonna pick a game engine platform, or you might say I'm building a web server So I'm gonna pick a web server platform, or I'm building a command line app and build a pick a command line app platform. Um Platforms are different than frameworks in that although they, they sort of provide that sort of domain specific foundational feel, um, they do more than that.

[00:51:56] So they also provide all of your IO primitives. So for example, um, if I'm building a CLI app, obviously I want to be able to write to standard out, write to standard error, and read from standard in. But if I'm building a web server app, do I really want a primitive for reading from standard in to be available?

[00:52:11] Does that make sense? Like, you know, you're handling web requests and something like, Hey, let's block on standard. And it's like, that's really not going to go well. So you're making a web server platform, and you just probably just don't have standard in as a thing. And you'll get a compile error if you try to, if you or any of your dependencies tries to, like, you know, read from standard in, that's just not, not going to work.

[00:52:27] Um, so that's, uh, that's pretty much it. Part of what platforms do. Another thing that they do is they're responsible for, uh, memory management and like figuring out kind of like how that works. So it's always automatic reference counting, but, um, without going into too much detail, platforms have a little bit more control over how memory gets managed, um, than you do in most languages where it's sort of like a one size fits all, like garbage collector or something like that.

[00:52:49] Um, so putting those things together, uh, the, the goal is that you're able to make sort of a, an end user experience that, As an application developer, it just feels like using any normal language, starting with a sort of a framework type thing. In terms of discoverability, these basically just work like normal packages, except that you, when you're building your application, you have to say like, this one's the platform, like, among your packages.

[00:53:12] It's like a little keyword called platform that you say when you're, when you're, um, you know, picking your dependencies. And that's kind of it. Then that determines, like, you know, uh, you get your, Uh, like I/O primitives and everything else from your platform that you pick.

[00:53:29] Jared: Okay, cool. So it would be, if you're searching the package ecosystem, you would find the platforms in there as well as a subset of those,

[00:53:39] Richard: Yeah, we don't actually have like a formal package index yet. Um, somebody made one. So right now the way that we do, um, packages, and it actually looks like this is probably what we're going to do going forward too, is that, In order to, uh, download a package, we have URL based packages, but, uh, they have a security feature, which I have not seen any other language do, but now that we've done it, I think it's really cool, which is that when you specify a URL to download a, uh, Roc package, the end of the URL has to be a Blake3 hash of the contents of that URL.

[00:54:11] So the reason I say that's a, and we verify that when we download it. So the reason I say that's a security feature is that that means if the URL gets compromised, or like, somebody tries to, um, uh, like, well, also if somebody tries to make changes to it, like, you know, it also means they're immutable in addition to being like, uh, you know, you don't have to worry about being compromised.

[00:54:30] Um, basically there's no way to do that without turning it from a working URL into a broken URL. So it's like either it resolves and then you download it and then the hash matches what was in the URL or it doesn't and you get an error or, you know, the URL is down and so you get a 404 or something. Um, so basically, uh, that.

[00:54:49] That's what we have for right now. Um, we're going to extend that to work with version ranges, um, soon ish. Uh, so we have an algorithm for doing that, which doesn't require, um, an index either. Uh, but basically once we have those two pieces, uh, then the last step is we need an index that you can use to search them.

[00:55:06] I imagine that we would probably have some way to filter based on, like, I want to just show me platforms versus show me, you know, non platform packages. Um, But yeah, I mean, uh, in terms of discoverability, that's basically the same as packages.

[00:55:19] Jared: Right. Okay. Yeah. So the platforms for me, the mental model was thinking about like Platform.worker in Elm and Browser.application, and then kind of, and then translating like, Oh, okay, well just what if there were more options that you could pick is kind of, and I know that might not translate directly in terms of how that works, but just that for me was a starting point to think about them.

[00:55:47] Richard: I see. Yeah, it's, it's kind of unrelated to Platform in Elm.

[00:55:51] Jared: Yeah. Um, but so then would you also imagine that, let's say that you're targeting, like, let's say a Raspberry Pi platform. Would there be some tooling that you would hope to have in the editor related to that particular platform?

[00:56:08] Richard: Definitely would love to have platform specific tooling, for sure. Um, so actually this has already happened, we've had a number of different Raspberry Pi, uh, Roc apps created already. Um, one's like a little robot that like, uh, goes around a track, which is kinda cool. Um, somebody else also made a physical clock, where it looks like one of those old school, um, like, liquid crystal display clocks with like the little, uh, like dashes for the makeup and numbers except each of the dashes is, uh, is basically like on a, on a little servo.

[00:56:37] So it actually rotates up and down, um, to like, you know, become, uh, like active or not. Um, and he made all the logic for that in Roc, which is really cool. Um, so yeah, so right now we don't have any editor tooling for that obviously, but, uh, one of the things that I've had in mind, and I hope we can get the performance good enough to do this, but I would really love it if we could end up getting.

[00:56:58] I don't know if it's an Arduino or a Raspberry Pi or whatever, but you have some sort of Roc app that is connected to some LEDs, like some colored LEDs, and then in your editor you have a color picker that's also all done through like an extension that's specific to that platform or maybe even some generic package, probably a platform though.

[00:57:14] Then you're able to just pick your color on the screen and then like in real time it's changing the LED, like physical LED, in the room and hopefully that can be like, you know, really smooth 60 frames per second. I don't know how fast you can get the refresh rate on those things with like, you know, if you have to like reflash the, the thing every time, then maybe that's not going to work.

[00:57:32] But I would love to try to get that level of user experience, um, if we possibly can. So that's, I don't know if it's possible, um, given the hardware, but, uh, but hopefully on the software side, at least we can make it fast enough that that's theoretically possible.

[00:57:46] Jared: Yeah, sounds ambitious. I love it. Well, well, we're nearing the end here. Is there anything you want to talk about before we move on to picks?

[00:57:56] Richard: Ah, I don't think so. Um, Yeah, this has been, uh, fun to talk about all these things.

[00:58:02] Jared: Yeah, yeah,.

[00:58:03] Picks

[00:58:03] Jared: So, what picks do you have for us today, Richard?

[00:58:06] Richard: Okay, so one is, uh, computerenhance.com. So, this is a website I've really been enjoying. It's, uh, it's a course entitled Performance Aware Programming. Uh, Casey Muratori makes it. And basically, uh, It's really, it is a paid subscription, um, and I don't have any affiliation with them, so I'm not getting any money for saying this, but, um, I just, I really enjoy it, and I want to let more people know about it, so basically, it's a way of learning, um, about, like, how to make high performance programs, starting from, like, the lowest level, like, hardware stuff and then, uh, sort of working out, basically understanding, like, what the actual hardware is doing.

[00:58:45] Um, so he gives an example of, uh, he starts off writing a little for loop in Python that, like, sums up a bunch of numbers. And then he goes through and actually like steps through the, like he builds Python from source and steps through like, um, the, the compiled code. So you can see all the different things that are happening in the course of doing that loop.

[00:59:03] And he's like, okay, now let's like rewrite this in C and see how much less work the computer has to do. And then we can, uh, write the loop in various like modified ways. And he ends up getting it to be like, it's like 10, 000 times faster than the Python one. It's really wild. Just, and that's like the like module one, right?

[00:59:19] And then he, then he gets into like really in depth stuff and. It's just, I found it to be really approachable and also like a lot of stuff that I never really knew about how to make computers go fast, um, and it's, it's just been really, uh, a good, great experience, like, learning from that. Um, so that would be one pick.

[00:59:37] Uh, another pick would be, uh, and I guess the videos for this are probably not out yet, but, um, I just got back from Software You Can Love, uh, conference in Milan, um, and this was the first conference where we actually had, like, uh, more than three Roc people hanging out in person. We had 10 people, uh, in the same physical space, which was cool.

[00:59:56] We all took a picture. Um, so that was like, at this point, the largest physical gathering of Roc programmers, uh, in one place, which is really cool. Um, it was, it was a lot of fun. Uh, we had, uh, I gave a keynote and then there were two other people who gave, uh, Roc specific talks. Um, but also like the conference just had a great vibe.

[01:00:13] It was like one of my favorite conference experiences I've ever been to. Um, and sort of the theme of the conference is about, like, basically building software with, like, uh, humans in mind. And, like, trying to make really delightful software and not As opposed to, like, software for, like, trying to maximize profit or other goals like that.

[01:00:31] Um, and it was just a really great vibe and, uh, had a had an excellent time. And I recommend people checking out the conference, but also, um, there should be videos from that up. Uh, cause they they live streamed the whole thing also. Um, uh, probably, uh, well, maybe by the time people are watching this. Who knows?

[01:00:46] Jared: Yeah, excellent.

[01:00:48] Yeah, I'll definitely find those if they're out by the time we publish this, then I'll add those to the show notes, and of course, computerenhance.com, I'll add that as well. Good picks. Well, I have two picks. Uh, the first one is unrelated to programming at all, but, uh, since we're talking about the Roc programming language, there's a rock band called Umphreys McGee.

[01:01:14] They are an improvisational progressive rock band, and they're very heavy on the, uh, the guitar. There's, uh, two guitarists, uh, Jake Cinninger and Brendan Bayliss and It just, it sounds really cool together. I think, you know, this is more, um, I learned this from Aaron Strick. I try to think of the picks that are kind of related to the person that I'm interviewing so that, um, they're more directed instead of a general pick to anyone.

[01:01:42] But yeah, I think, uh, that's, uh, one, a band that I've seen a lot of times in concert. And, uh, I think if you're into sort of rock guitar, then you might like that. So. That's one, and then the other one is Bret Victor's work on computer, human computer interaction. Um, definitely there's a lot of videos and, um, and things that he's done out there that I think, um, of course they've influenced the, the sort of vision I think that you have for Roc, and, and so I think, um, folks want to learn more about that and hopefully advance what's possible there.

[01:02:24] Um, It'd be pretty cool to check out. So, that's all I have.

[01:02:28] Richard: Let me sneak one more pick in, since you mentioned a progressive rock band. Reliqa, R E L I Q A. They're an Australian progressive metal band, and I've really been digging them. That's like the main thing I've been listening to for the past couple months, since I found out about them. Big fan, and they're really cool, if you're into that kind of sound.

[01:02:48] Jared: Okay, cool. Yeah, Reliqa. I'll check it out. Alright, well, thanks to all the folks listening out there. Please rate and share if you're enjoying the show. And thanks, Richard, for coming to Elm Town.

[01:03:00] Rock on!

[01:03:01] Richard: Yeah, thanks for having me.

[01:03:02]