Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
Roc - A Functional Language looking for those Software Sweetspots (with Richard Feldman)
1.5k Plays1 year ago
Sometimes, what a programming language makes harder is just as important as what it makes easier. For a simple example, think of GOTO. We’ve been wisely avoiding it for decades because it makes confusing control flow desperately easy. Types and tests are other examples - they’re as much about specifying what shouldn’t work as what should. And perspective is what makes this week’s topic particularly interesting: Roc is a language that’s functional, fast, friendly, and extremely interested in making your life easier by enabling some possibilities and restricting others.
So this week we’re joined by Richard Feldman, the creator of Roc. He’s been an advocate of the Elm programming language for years, for its tight focus on taking the best bits of Functional Programming to the browser. And in recent years he’s been inspired to build his own language, taking that philosophy to other places and platforms.
But which bits are “the best bits”? And how do they change when the domain you’re coding for changes? How is Roc built and how would we build systems in it? Let’s find out…
--
Roc’s homepage: https://www.roc-lang.org/
Richard’s GOTO Copenhagen 2021 talk: https://www.youtube.com/watch?v=3n17wHe5wEw
Richard on Twitter: https://twitter.com/rtfeldman
Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/
Kris on Mastodon: https://mastodon.social/@krisajenkins
Kris on Twitter: https://twitter.com/krisajenkins
Recommended
Transcript
Introduction to Rock and Richard Feldman
00:00:00
Speaker
For this week's podcast, we're going to take a look at a functional programming language called Rock. It's born out of a language that I'm very fond of called Elm. It's a really nice language. And if you know anything about Elm, then you might know this week's guest, Richard Feldman.
00:00:15
Speaker
He's been hugely immersed in Elm's approachable, developer-friendly interpretation of FP for years now. He's given loads of talks about Elm, and he's been inspired by Elm because there's always been a limitation to Elm. It's just for the front end.
00:00:33
Speaker
So in this episode we talk about what Elle means to him and why it's inspired him to build a language that breaks out of that front-end limitation, but also really curiously why he sees that limitation as something very freeing.
00:00:49
Speaker
and why he sees the limitations of functional programming as freeing, and how he's trying to make a new language with comfortable limitations that works in many different domains.
The Vision and Philosophy Behind Rock
00:01:01
Speaker
He's almost trying to make Rock a universal domain-specific language by giving each domain the right set of constraints for that particular task.
00:01:13
Speaker
If you can't quite imagine how that would work, we should get into it. I'm your host, Chris Jenkins. This is Developer Voices, and today's voice is Richard Feldman.
00:01:35
Speaker
So joining me today is Richard Feldman. Richard, how are you? Doing well, Chris. Nice to see you. It's good to see you, too. I don't think we've seen each other since some conference in Northern Europe. Yes, go to Copenhagen 2021. That was where you gave me the my favorite explanation of what a pure function is or definition.
00:01:55
Speaker
which is a lookup table. I love that. I use that all the time now. Thank you. It's a nice way to think of it. I think I got that from some book on Lisp macros or some variant of that idea.
Balancing Family and Rock Development
00:02:08
Speaker
Very nice. Now, I can't remember. When we were at that conference, I can't remember if you were talking about Elm or Rock, or you were just making the switch. That's a good question. I think that was the conference where I gave some sort of general talk. I think it might have been why static typing came back. No, maybe that was a remote one. Oh, it was functional programming for pragmatists, I think. Which was, yeah, not really specific to either Rock or Elm.
00:02:39
Speaker
The people that know you, a lot of them are going to know you, because for a while, for a good number of years, you were the poster child for Elm. You were the face of Elm.
00:02:48
Speaker
I did a lot of Elm talks, that's for sure. And I wrote the book for Manning. Yeah. Element action, front end masters course, intro to element advanced element. Yeah. A lot of stuff. Are you still doing Elm or have you moved on? Uh, I wouldn't say moved on. It's more that I don't have time for things that aren't rock, especially now that I have a kid. Uh, it's, it's really like,
00:03:11
Speaker
My free time is like 90% rock, and then there's a tiny bit of exercise and guitar in there. And that's really it. I just don't have, like there's even like projects I'd like to do in Elm. I'd really like to go back and update Elm SPA example, but like,
00:03:27
Speaker
and LMCSS for a long time. I had like pull requests that would be open. I'd be like, Oh, this weekend I'm going to get to it. And then after a while I was just like, yeah, this is never happening. I said, I'm just never going to have like the bandwidth to do this stuff. So I still love Elm. I just, I just.
00:03:42
Speaker
feel like I have a more of an obligation to rock. Because it's like, if I want to make this new language happen, I just got to put in the amount of work that that takes. And it's a very large amount of work as it turns out. And the price of a spare hour once you've got kids is very, very different, right?
00:03:58
Speaker
Yeah. Yeah. I mean, it's really like, I mean, it used to be like, I got done with work and then it's like, cool. Now I have the whole evening and now it's like, I get done with work and I got to go pick up the kid and then go take him home and then feed him dinner and then give him a bath and then do some like play time and some story time.
Challenges and Solutions in Functional Programming
00:04:12
Speaker
And then then I get to eat and then it's like, cool. Now I'm exhausted and let's see how much time I have for, you know, maybe an hour and half an hour's worth of energy left.
00:04:23
Speaker
Yeah. Well, then it's like, well, you know, don't don't sacrifice your sleep because that catches up to you very quickly. And so, yeah, it's a difference. I mean, people have kids, I'm sure, very familiar with this. Yeah. You're listening to the joys of parenting podcast. Yeah. I mean, like it's it's also wonderful, but it's it's definitely there's just a math problem. Yeah.
00:04:44
Speaker
Okay, so let's put it this way then. There you are with a serious premium on your time, and you decide to dedicate as much of that spare time as you can to rock. So why? Why create a new language? What's burning inside of you?
00:04:58
Speaker
So the original motivation was three, I could break it down to three categories. So one was like, I'm like, I love Elm, but Elm is very focused on front end web development, or at least that was true at the time. Now there's like another thing that is unreleased, but is also very focused. And so I was like, but there's all these things that keep coming up that are not front end web development, where there's this really big gap between the user experience I'm used to in Elm and really love, and like,
00:05:26
Speaker
the thing that's available and like the best experience I can possibly get in that domain. So last example, this is like web servers or command line apps or native desktop, like graphical user interfaces. But another example is just like a VIM plugin. Like I was using VIM at the time and I'm like, I really would like to try to write a VIM plugin, but
00:05:45
Speaker
I don't want to do it in VIMscript. I want to do it in an LMark language or a database extension. I would really like to try that out, but I don't really want to. I was looking at the options and it's like there's PLPG SQL, which I'm like, I don't really like that. And then there's like, well, you can do PLV8, but now you have V8 running in your database. Do I really want that? And Evan made a good point about now you have garbage collection pauses in your database. Do you want that? I definitely don't want that.
00:06:12
Speaker
Everywhere I looked, there would be Arduino. There would be these use cases where it's like, yeah, if you want to do something in this domain, your options are limited to JavaScript or Python or Lua or C or some variant of that. And I was just like, none of these options excite me. I really want to try to get some sort of Elm-like experience in these domains, but I'm also like,
00:06:37
Speaker
Elm's never going to expand to these domains. The whole point of Elm, or a major point of Elm, is to be really focused and doing a really, really good job of this one particular focus use case. The idea of expanding Elm to cover all these things, it's not really Elm. What I wanted to try and do is to try and answer the question, is there some way to try and
00:06:58
Speaker
80-20 recreating that experience and try to make it so you can have what feels essentially like an Elm-like experience even if it's not like the absolute best of that one particular use case so that I can at least get that much closer to Elm or like an Elm-like experience in all these different use cases.
00:07:15
Speaker
Yeah. So that was, that was one motivation. Another was, um, over the years I'd talked to Evan who made Elm, uh, about various ideas that I'd had for Elm. And sometimes he would say, that's actually not a good idea. Here's what you're missing. And I'd be like, okay, good point. Good point. I didn't think of that. Sometimes he'd say, that's like a reasonable thing you could do, but it's not what I want to do with this language. So we're not going to do it.
00:07:37
Speaker
And then the third thing would be just like, that actually is a cool idea. We could try that, but it's kind of like that ship has sailed. It would be too big of a breaking change to try, given how many thousands of people are using Elm. And so those second two groups are like, well, hmm, I like this even if Evan doesn't. I would like to try it. Or I'm really interested in trying this thing out, but it's too late for Elm, but it wouldn't be too late for a new language built from scratch. So those were kind of like,
00:08:06
Speaker
accumulating as we have more and more of these conversations. Oh, I should mention that another category of things is Evan would be like, oh yeah, that's a good idea. Let's do it. And then that is an elm now. But of course, there's nothing burning inside me about those. I'm just like, cool. Good. So that was a second category of thing. And then the third category of thing was just thinking about
00:08:26
Speaker
I didn't really think about it this way at the time, but over time, it's become an increasingly important thing to me. It's just thinking about feeling bothered by the fact that functional programming or pure functional programming is not widely used in industry in all these different domains.
00:08:45
Speaker
You look at what's the most popular backend language. And you have to go very far down the list before you find Haskell, which is the number one most popular backend language. You look at game development. It's like people are doing game development in C-sharp. I get people doing game development in C++ and in Rust and in C, Zig. Those all make sense to me. I understand it. You have very tight performance constraints. But then people do it in C-sharp and Swift. I'm like, well, if you can do it in an automatic memory-managed language, why is there no functional programming option?
00:09:15
Speaker
for like, you know, game dev on like a console, not even just, you know, like on a computer, but like on a phone, like something like that.
Motivation and Goals for Rock
00:09:23
Speaker
And so I just started thinking, you know, I don't think that...
00:09:27
Speaker
It's correct in the world that there should be no viable option, no mainstream option, where people can just pick it up and say, I want to go to game dev in a functional style. And let's see how that goes in a world where C-sharp and Swift are considered reasonable ways to do it. Or on Java, of course, you have like, sorry, on Android rather, you have Java and Kotlin.
00:09:49
Speaker
If those are all viable that I totally think they're a functional thing, you should be viable. And in fact, should be a really nice way to do those things. And so putting all this together at some point, I kind of reached a point where I was like.
00:10:02
Speaker
I should do this. Nobody else is going to do this. I should just go and do it. And I have to admit that part of the motivation there was I'd sort of finished the book. Elm in Action took me like four years to finally ship. But I'd done these courses on Elm. And at that point, I was kind of feeling like I want another really big, juicy project to sink my teeth into. But I don't want to manufacture one in Elm just because that's what I know really well. It's like I want some project where I feel like this is something that I can really devote a ton of time to. This is before I had a kid.
00:10:32
Speaker
I had a long one time. Back when I was asking the question of how can I fill my time with something rewarding? You and your partner came up with a far more efficient answer to that. We planned to have a kid. I actually was thinking from the beginning, I was like, okay, everybody says when you have a kid, time is lower. How do I plan for it not having the project grind to a screeching halt when that happens?
00:10:57
Speaker
But basically, I was looking for something where I would like to be able to sink my teeth into something really difficult and where it's going to be something I'm pushing myself and learning a lot. I did an advanced LM course for front-end masters, but I didn't really have
00:11:13
Speaker
a sense of there exists a project within Elm that fits that characteristic. So it was exciting to me to be like, this is something I can work on for a decade plus. And if I'm successful at it, then it'll be really rewarding. And so that was also part of the motivation. So anyway, all these things came together. And I was like, OK.
00:11:32
Speaker
I think I'm going to do it. And so I kind of, in 2018, I started sort of drawing out some designs and like what, how do these ideas, like how do they all fit together? Like, how do we try to do this recreating the Elm feel and this long tail of domains, like 80-20 style. And I talked to Evan about it and his initial impression, I remember like I told him at an Elm meetup in San Francisco and he got this like smile out of his face. He's like, this is a very you language.
00:11:59
Speaker
which I kind of like, you know, I have guesses about like, you know, the different things that he meant by that. But, but I definitely take that as a compliment. So he kind of like helped me out with like, here's, okay, you're gonna need to read these papers about like, you know, types
00:12:14
Speaker
things. And here's how to understand the notation of these papers. So he was very encouraging and helpful. And yeah, so I started doing it. And I don't know, fast forward four or five years. And now we have a real website and like people using it. And it's it's becoming a whole thing.
00:12:34
Speaker
What are your defining domain features for this language? At the same time, what do you think makes Elm so special? Which bits did you pick of that that you thought these are priorities to have in a language?
00:12:50
Speaker
So to me, one of the essential qualities of Elm is the thing I was mentioning earlier, which is having a sort of domain-specific focus. And although we can't completely replicate that while sort of targeting the long tail of domains, one of the things that I do think is really valuable about that is having sort of a cohesive design for that domain. So as an example of this, so Rust has, in its standard library, as most languages do, ways to interact with the file system.
00:13:16
Speaker
read from a file, write to a file. But then you take Rust and you put it in a web application. There's this framework called U, Y-E-W, for Rust that's like, OK, compile your Rust app to WebAssembly, run that in the browser. Well, then the question, in my mind, immediately becomes, what about all these things in the standard library that aren't available in the browser, like file system access? What happens?
00:13:36
Speaker
happens if I call one of those. Or more importantly, what happens if I use a dependency that calls one of those? Like I have some Rust dependency that I depend on that maybe it depends on something else. And somebody just added a little, oh, we'll have a little on disk caching feature. And maybe it doesn't come up all the time. But all of a sudden, I'm running my app. And what happens? I mean, I have to assume it crashes or something. Hopefully, ideally, my app just wouldn't compile. But I don't expect that because it's using stuff that's in the standard library.
00:14:03
Speaker
Things like this just don't happen in Elm. In Elm, the entire ecosystem is totally cohesive. It's like you want to use it for browser-based stuff. The only things that are available in the whole ecosystem are things that are available in the browser. And so you just don't have that problem. Or you think about a database extension. Do you want your database extensions using the network, just willy-nilly? Yeah. I don't know. If I have a dependency that's like, oh, I'll go check for a new version of Unicode or Timezones or something like that, do I want that happening in the middle of my database without knowing about it?
00:14:33
Speaker
Probably not. So I think every domain can benefit from having some sort of first-class concept of like, this is the domain I'm working in, here are the primitives that are available, and they're sort of tailored to that domain. That's something I found at Elm that I haven't found in most other languages.
00:14:48
Speaker
In fact, very few other languages. So that's definitely something that we want to replicate in Rock. And so the way that we do that is we have this concept of platforms and applications. So a Rock platform refers to the domain that you're working at. It's something like a framework. So every application that you build has to have a platform. You have to pick a specific
00:15:10
Speaker
ROC platform to build on, and that platform's job is to provide all the domain-specific primitives. So ROC standard library actually does not have file system stuff. It doesn't have any IO at all. That all comes from your platform. So for example, if I'm doing a web server platform, it'll probably have things like file system stuff and TCP, but it probably won't have read from standard in. Because if you're building a web server, why do you want to block on
00:15:36
Speaker
hey, let's wait until we get input from standard in, that probably doesn't make sense in the context of a web server. But if you're building a command line app, of course that makes sense. That's a totally normal thing to do. So it's sort of differences like that, like having this domain-specific focus. And we can get into this a little bit later. But one of the other things that platforms do that's different from a framework, for example, besides being in charge of IO, is they're also in charge of how memory gets managed to some extent, which has some cool performance benefits that
00:16:06
Speaker
kind of behind the scenes and you just sort of get for free as an application author.
Technical Innovations and Domain-Specific Features
00:16:10
Speaker
Okay. Are you expecting people to write these platforms for Rock or is it something that the Rock authors provide?
00:16:20
Speaker
So we already have a couple of these. So the two most commonly used ones are, it's called Basic CLI and Basic Web Server. And as the name suggests, it's a way to platform building CLIs. It's a pretty basic one. And then same thing for the web server. And then we also already have a couple of variants of that. And anyone can build a rock platform. It's not like you need special, well, I guess you do need special knowledge in the sense that it's not very well documented.
00:16:44
Speaker
currently how to build a platform. We have a lot more. All the documentation kind of focuses on applications. The platform authoring story is a lot rougher right now. I mean, Rock's still a work in progress, and that's an area that's very work in progress. But yeah, so for example, we have a TUI, like a terminal-based UI where you have, rather than a typical command line thing that's just sort of like, well, we'll do print some stuff and then wait for user inputs. You have the keyboard, arrow keys, moving stuff around.
00:17:10
Speaker
re-rendering on every frame. And then you also have, in addition to the basic web server, there's another project called NIA, N-E-A, which is a Frisian word, actually, for never. And it also could be short for never ever allocate. But basically what it does is it presents the same kind of API as basic web server for just, I want to build my web server. But behind the scenes, it does things differently with memory management, where you never get garbage collection pauses and allocations are much more
00:17:39
Speaker
because basically what it does is every single web request you get the request comes in all the memory allocation for that entire request goes into this little arena that's dedicated for that request and it's bounded so you can say like I only want to allow this much memory per request if any given request goes over that it's going to immediately 500.
00:17:58
Speaker
And then, as long as you don't go over that, then basically it just keeps allocating into this one block. And then at the end, once you send the response back, it says, OK, all of that is now garbage. And it doesn't even need to free it. It can just say, all right, somebody else gets this now, not some new request gets that memory. So it's really, really cheap in terms of memory management. It's very far from mark and sweep garbage collection across all your different request handlers.
00:18:21
Speaker
But it does have trade-offs. It's not like that's just an unalloyed good. It's like you have to decide how much memory you want to allow for each of these things and so forth. And so that's a good example of innovation that can happen by someone saying, hey, I've got the same constraints, the same domain
00:18:37
Speaker
constraints, like the same primitives for this platform versus another one, you can now try it out as an application author. And if they have compatible APIs, I can just change one line of code and try out this different platform. It's like, cool, everything still works, but now your engine under the hood behind the scenes is different.
00:18:52
Speaker
So, yeah, this is the type of stuff that in Elm is not really possible. And on the one hand, that's good because it means you don't have these sort of like different decisions to make. Like one of the things that people love about Elm is that you can have this sort of
00:19:09
Speaker
like all the questions have been answered for you at that level thing. It's like it's a cohesive ecosystem built around like basically nobody uses frameworks in L. It's like, you know, you have the basic HTML stuff, you have HTTP stuff, everybody just kind of uses the stuff that ships with the language. That's a selling point of the language.
00:19:25
Speaker
Yeah. Rock can't have that selling point because we have this sort of long tail domains focus. But a corresponding upside that comes with that is that you can get this sort of experimentation with like different things in the community and people can try out different approaches like that. And maybe it turns out everybody loves the NIA approach and gravitates towards it. And maybe some people say,
00:19:44
Speaker
Our allocation patterns are such that they're kind of all over the place. Some requests use a tiny bit of memory. Some requests use a huge amount of memory. And so this just doesn't work for us. Maybe somebody else tries a variation of NIA that accommodates that while still trying to maintain the benefits. There's all these different ways that people can do those things. And I think it's really cool that it is possible to do that. I don't know of any other language, specifically when it comes to memory management, that has done that.
00:20:10
Speaker
Do you foresee someone writing a platform that's specific to the front end and eventually subsuming Elm?
00:20:20
Speaker
Oh, well, eventually subsuming Elm. No, I don't see that happening. But it has already happened that people have tried building Rock in WebAssembly and building a front-end UI, I think. So it turns out, because of the way that Rock has compiled, it's not quite possible to do the Elm architecture in the same way that Elm has. There's a lot of details behind that. But if you try to just do the normal HTML message thing that everybody loves in Elm,
00:20:45
Speaker
it's not, you can't quite implement it in rock for various reasons. There's like, you could do it with like an extra type variable, which is like kind of an ergonomic and yada, yada. But to me, I think one of the things that makes Elm so great for the front end is that it's so tailored to that and is able to do things like Elm compiles to JavaScript. If you're comparing, compiling WebAssembly to JavaScript,
00:21:11
Speaker
I would have thought back in the day when I first heard about WebAssembly, like, oh, that's just an upgrade. Like, you compile to WebAssembly, you get to go faster. Amazing. Well, it turns out now that we've actually done some compiling to WebAssembly, it's not that simple. It's actually there's a lot more complexity that you don't have if you're compiling to JavaScript. For example, there is no way in WebAssembly to directly access the DOM at all. You have to go through JavaScript. So what ends up happening is if you want to build a WebAssembly application like you or like doing it in rock,
00:21:39
Speaker
You have to compile it to WebAssembly, and then there has to be this JavaScript layer that does all the DOM stuff that sort of communicates back and forth with WebAssembly. And of course, there's overhead there. So it's like maybe your individual WebAssembly things are running really fast. But unfortunately, the corresponding downside of that is you have all this mandatory extra overhead of sending stuff to and from JavaScript in order to do things with the DOM.
00:22:00
Speaker
So A, it's not a given that the WebAssembly version is actually going to be faster. B, it's also not a given that the WebAssembly compiled assets going to be smaller. It might actually end up being bigger, especially because Rock has a monomorphizing compiler, which is great for other domains, but not as great for the web.
00:22:16
Speaker
So to me, it's like I totally understand the impulse to want to build that, because a lot of people like having the exact same language on the client as on the server, rather than, for example, having two very similar languages, like Elm and Rock are very similar. Personally, that's what I'd go for. I'm like, Elm is the best at this, and there's a whole ecosystem, and so forth, and pair that with Rock on the server.
00:22:40
Speaker
But I totally understand that some people want to do both. But I don't really see that leading to Rock subsuming Elm in the same way that just because it can be done, people will simulate Elm in TypeScript.
Comparisons and Distinctions: Rock vs. Elm
00:22:55
Speaker
And it's just not the same experience. I think the experience would be a lot closer with Rock than with something like TypeScript. But at the end of the day, I think
00:23:04
Speaker
There's just so many nice things about Elm that are really hard to replicate in Rock, even if we've got this sort of 80-20 thing that in that one domain, I just don't think it's ever going to be as good. But maybe people will prove me wrong, but that's just kind of my prediction.
00:23:20
Speaker
Okay, so let's talk about some of those features of Elm and whether they've made it into Rock. For instance, one of the headline things is it's probably the most user-friendly version of a Haskell-like type system that I've seen in the wild.
00:23:42
Speaker
simplifying. Let's not say dumbing down, but simplifying the Haskell type system to the greatest hit. That's one way to look at it. If you're coming from a Haskell background, I can see why that would be the way to think about it. Evan did a lot of standard ML in college. He learned Haskell later on. I can't speak for him directly, but I don't think he thought of it as like, let's take Haskell and let's subtract things, but rather like, let's start from standard ML, which is already a lot simpler.
00:24:11
Speaker
make some adjustments to that based on what I've seen in Haskell and OCaml and in these other languages. And I think the main thing that Elm takes from Haskell is actually syntax, if anything, like compared to standard ML. And also, of course, the idea of having pure functions for everything and taking out the direct mutation capabilities. So Rock does all those things too. But yeah, I mean, definitely
00:24:34
Speaker
For me, pure functional programming has always had its benefits rooted in subtraction. It's about taking the whole possibilities of what the CPU can do and saying, we're going to intentionally restrict that to this subset of things that you can do because there's a bunch of benefits if you do that. It's not like you're just taking capabilities away from yourself for no reason.
00:24:54
Speaker
And you're taking them away because then there's this whole category of things that you don't have to worry about anymore. And it unlocks these other things that become a lot easier to optimize or to improve in various ways that, if you have the full range of capabilities, become a lot harder to do or to do reliably, especially across a big ecosystem.
00:25:13
Speaker
So to me, it's not so much about starting with Haskell and simplifying. It's more like starting with some sort of arbitrarily large language that can do anything, mutations, side effects, whatever, and then saying, OK, let's take out mutation. Let's take out side effects. Let's take out this and that, and then figure out what's the sort of essential core. And then if we have to, and we run into certain use cases where we're like,
00:25:41
Speaker
this is really un-organomic, we need to add something back in to make this use case work, then we do that. That's kind of how I look at it, and I think that's pretty similar to how Evan looks at it too.
00:25:55
Speaker
Things that were unergonomic that we wanted to add something to. This is a complexity that we just have to bring back in, because it's not going to work. Oh, I see. So it's not back in specific, but it is long tail of domain specific. So one of the things that Elm does is that it has, so I'll contrast it to Haskell, because I think that's the easiest, or to Rust, I guess. So in Haskell and Rust, and also now in Rock,
00:26:20
Speaker
The way that you have two things be equal to one another is you have, in Haskell we call it a type class, in Rust they call it a trade, in Rock we call it an ability, but basically you say, here's what equals means for this particular type. I'm defining some sort of new type, and in that type I'm saying equals semantically means this. So whenever you use double equals on these things, it's going to run this function on this particular type.
00:26:47
Speaker
that's quite useful if you're defining custom data structures. Like if I'm making a custom hash map or a custom tree or something like that, I want to be able to have these in my tests and say like, okay, in my test, I want to assert that this thing equals that thing. And
00:27:01
Speaker
in that world where I'm saying I want to be able to define what equality means in a sort of custom way, I also want to be able to say, well, hash should also match up with equals. And there's ways you can do this. So I have a package in Elm called Elm Sorter Experiment or Elm Sort Experiment, something like that, where I basically just said, OK, well, every time you want to do equals on one of these trees or whatever, you have to pass in a comparator function that tells me how to compare its elements for sorting purposes.
00:27:31
Speaker
So sorting, equality, hashing, all of these things are sort of in common. And in Elm, it's like, well, OK, we have a certain set of baseline data structures where this is all well-defined. Defining your own custom data structures just does not come up that much in Elm.
00:27:48
Speaker
My expectation, though, is that when you have a lot more different domains that you're targeting, it is going to come up more. So there's this blog post from people in Elixir who talked about a blog post by a company that was using Elixir. And I think it was maybe Discord. But they basically had a chat client with a huge number of channels in it.
00:28:07
Speaker
And they talked about how they needed a custom sorted set data structure with really high performance characteristics for dealing with a situation where you want to keep the list of users sorted all the time. But people are joining and leaving the channel or the chat all the time in real time. And you just need something that's really dedicated to that. That's an example of the type of thing that I think is really difficult to just satisfy by making the standard library bigger and bigger. Because depending on your use case, you're going to run it all sorts of different variations of things like that.
00:28:36
Speaker
So we really wanted to have some way that people could make their own data structures and define what equality and sorting and hashing means on those. But I explicitly did not want to go as far as Haskell or PureScript do, where you have higher-kinded types, where, in addition to saying, in Haskell type classes, you can say, here's equals, and here's hash code, and here's sorting. But also, you can go a step further and say, here is a monad, and here is a monoid, and here is a functor.
00:29:05
Speaker
and classify things in that way, depending on who you ask, that's a great feature. Depending on who you ask, I'll say, traversable is great. What about traversal? But there is definitely a lot of added complexity of the language there. There's definitely a lot of downsides that I don't hear talked about as much as the upsides. And I just didn't want to have that in rock as a language. That's one of the things I would want to subtract if I were starting from a Haskell perspective.
00:29:32
Speaker
So the design ended up basically being that you have equals and hash. And we actually don't have sort yet. Inspect is about to land, which is a way to customize when you're debugging something, like debug printing it. You can customize that too. And so basically, all these things are designed to address the fact that, unlike Elm, we do have this broader scope. And I anticipate that wanting to customize those things is going to come up a lot more often than it does in Elm.
00:30:00
Speaker
Okay. Okay. So I'm just, I'm just trying to think how this is going to play out when you've got several platforms working for roughly similar domains. Like from what you're saying, I can foresee a future where you have a platform that's specific to writing Postgres triggers. Totally. Yeah. And how, how is someone going to write that platform? What do they write? Do they write it in rock?
00:30:28
Speaker
Great question. So the short answer is that every platform has two pieces to it.
Rock's Architecture and Language Interoperability
00:30:33
Speaker
One part is the public facing rock API. And if you're a rock application author, that's the only part that you see is like, oh, here are the rock things that I can use, the primitives. The other part of it is the low level implementation. And we call that the host. And that's always written in a language that's not rock. So every platform has the rock part and the non-rock lower level part that sort of implements
00:30:55
Speaker
all the primitives at a really low level. You can use whatever language you want for that, but it needs to basically be something that's compatible with C. You can use C itself, or C++, or Rust, or basically any language that does C interop. Actually, right now, at work, we have this big Node.js back end vendor, V-E-N-D-R. That's the company I work for now.
00:31:18
Speaker
And it's this very large Node.js backend, and we're introducing Rock to that by basically using Node.js' C interop. So we have this sort of custom platform that's just designed to be like, use Rock on Node.js. And the idea is essentially that any
00:31:34
Speaker
Anything that can call a C function can call a rock function. So that includes Node.js using its C interop. And so I have it set up. There's actually a thing we've published called a rock esbuild. If you're using esbuild with Node, you can just include this, and then you can now call rock functions from Node. And that's basically the way that it works, is the platform's job in that case is to translate. It's a little bit of C code that translates between here are your rock types in memory,
00:32:00
Speaker
And let's just get those and translate those into node types. And then back the other way, such that node.js, you call this rock function passing a node string, which is actually totally different in memory from a rock string. And then that gets translated by the little platform glue into a rock string. And then the rock function runs and gives back an answer. And whatever rock data structures, those get translated back into node. And off you go. And so you can just do that in the middle of your, you know, you literally import a .rock file. And now you can just call rock functions from node.
00:32:30
Speaker
That makes me wonder what, I thought I had a handle on what rock was, but now I feel like the ground has been pulled out from under me. If you've got like Rust and JavaScript under the hood and rock user space functions above, what's the layer that's actually rock?
00:32:48
Speaker
So essentially, the part that's 100% rock is the application code, or any libraries that it depends on. So for example, my coworkers at work, all they have written is rock code. None of them have done any of the C stuff. I'm the only one at work doing that.
00:33:03
Speaker
that sort of glue layer. What they see is basically like, OK, here is a way that I can call a rock function from my C code. So for example, they'll just say, all right, we have this part of our code base. It's doing these calculations. I want to rewrite that in rock. They'll introduce a new .rock file. We have our build set up already so that as soon as you import that, it knows what to do. And it'll compile that and set up the interop behind the scenes.
00:33:27
Speaker
So they write the rock file, import it in their TypeScript code on Node, and then they just call it. And it just gives back an answer. And it's almost as if you were calling a TypeScript function from their perspective. The only difference is instead of importing a .ts file, they're importing a .rock file. So this is an example where unlike basic CLI and basic web server, which are very much like
00:33:47
Speaker
The platform's job is to provide this very generic experience for like, you want to build a basic web server completely in ROC from the ground up. Here, the platform is serving a different purpose, which is to be a binding layer where ROC is almost like this scripting language or like this new thing that you're introducing to a very large existing code base. So the platform scope, in this case, is like the entire existing vendor back end.
00:34:13
Speaker
And then, but the same strategy still works. So the important part is that the end user experience when they're writing the rock code is just like, yeah, I don't know. Everything that's available to me just works here. Any primitive that's here will work fine. We can also introduce new primitives. This is not something you would normally do in a sort of general purpose platform. But in a bespoke platform like this, where you're just trying to introduce a new language to an existing code base, we can do stuff like,
00:34:41
Speaker
I'm going to introduce a new platform primitive that's like, make this very specific request to our database, which is all wired into Node and all that stuff. But on the rock side, you're like, I don't know. It's just a function I can call. And it's going to do the database thing. So I don't care how it's implemented, just like how in basic CLI, I don't care how the function to read an environment variables implemented. That's all behind the scenes details. All I care about is I have this nice rock API that says, here's how to use these things. And given these primitives, they all fit nicely together and work really well.
00:35:09
Speaker
And so our strategy in this case is we're trying to incrementally transition the back end from being all Node.js to being someday all rock is sort of the ultimate goal. But you can also imagine somebody using a very similar thing in a game where you have a large C++ or Rust or whatever code base. And you're like, there's this one part of my code where it's not as performance critical. And I just want some nice language that I can just work quickly in that's memory safe, et cetera.
00:35:36
Speaker
You can just do that in rock and have the rest of your whole code base be, you know, the game. And maybe you don't ever intention intend to transition the whole thing to rock. But again, you can provide all of your game primitives to rock all these, you know, low level, draw this, draw that, whatever operations that rock can just sort of be like Lua, just a little bit of an add-on. Actually, the original joke name for a rock was type pure functional Lua. That was the joke name before it got the name rock.
00:36:01
Speaker
Because you do get a lot of games where the main engine isn't C++, but then the scripting for the MPCs, that will be in something, like, famously. Yeah, I don't personally have any game dev experience. I know there's sort of a spectrum, is what I've heard. Some people will say, I don't want to use any scripting language. And then some people will say, I want to have a game engine.
00:36:24
Speaker
everything in C-sharp or Swift or whatever. And then some people are somewhere in between. Well, they'll do a mix of a lot of C++ code, but then some bits are Lua. Like I said, not my world. But the point is that Rocket has turned out to be very well suited to being embedded like that. OK. Now I'm starting to wonder if I could do something like build a Rock platform that was specific to, say, Kafka.
00:36:51
Speaker
Sure, I don't see why not. I mean, I don't know. I've never used Kafka directly. So I don't know if there's a query language or something like that. But yeah, I mean, anything where, so actually we have examples in the rock repository of people doing really basic like hello world level stuff, but like calling a rock function from Scala and Java and Kotlin and Ruby and Python, like basically any language that has C interop, which is kind of like all of them, you can call rock functions from that.
00:37:20
Speaker
in a way you're seeing rock as the sort of universal domain-specific language.
00:37:27
Speaker
Yeah, I hadn't thought of it that way, but that's a pretty good way to put it. You can have that for the marketing, if you like. The tagline is fast, friendly, functional language, which are the values, the main overarching design goals that I think are powering the language. But in terms of use cases, I think that's a pretty good way to think about it. What are you writing Rock, the compiler itself in? Is it in C?
00:37:53
Speaker
It's in Rust. When I started out, I hadn't really done a significant amount of low-level programming since college and then before that middle school.
Compiler Choices and Performance Optimization
00:38:07
Speaker
I was never really very good at it. I always get seg faults and stuff. I remember thinking,
00:38:14
Speaker
Starting a new codebase from scratch, I really, really wanted to end up being as fast as possible. So I want to use one of these languages that really doesn't put a ceiling on how fast this can be. It's like maximum performance. I'm not really sacrificing anything because I'm going to spend like 10 years of my life at least working on this thing. I don't want to end up saying like, oh, and now if you really wanted to be faster, you got to rewrite it in Rust or whatever. So I didn't want to have that happen.
00:38:39
Speaker
Even though I didn't really know much Rust at that point, I had a very limited amount of experience. It was at the intersection of having this promise of, you won't get seg faults in this language. As long as you can get it compiled, you'll be safe from that. And also, the performance ceiling is essentially unlimited. I think if I were starting it over today, I would have considered a lot of alternative languages. I don't know if Rust would have been the best choice. Zig is the one that would be really tempting for me.
00:39:08
Speaker
In comparison to Rust, Zig is a much, much simpler language. And certainly the memory management part, which now that I've seen how the compiler is shaken out, it turns out that the memory management is actually very simple in terms of what we need. Because basically, we don't want to do a bunch of allocations and deallocations. That's really inefficient. We really just want to say, all right, we're starting up
00:39:29
Speaker
do a bunch of allocations for parsing and canonicalization and type checking and all that stuff. And then once you finished everything and you've compiled the output artifact, that was all garbage. Throw it all away. So the fact that Rust provides all of these, like this detailed tracking for all these lifetimes, our lifetimes are actually really simple.
00:39:47
Speaker
With that in mind, I don't know that I would have chosen to sign up for all of the complexity and especially long compile times, which really bother me increasingly now that we have this big Rust code base, like 300,000 lines. But at any rate,
00:40:02
Speaker
At this point, it's sort of like Rust is what we're going with, we're sticking with. So it's kind of a moot point. But yeah, been overall happy with Rust, though. I mean, it definitely delivered on that promise of like, we don't get segfaults all the time in the compiler. We still do sometimes because we are generating machine code. Like, there's no rock doesn't compile to a VM. It's just like straight to byte bitcode, like the actual machine code. So because of that, we sometimes generate code that has segfaults because it doesn't have a varo checker.
00:40:31
Speaker
CPU instructions. Overall, Rust deserves this reputation for memory stability and safety. This is something I wanted to ask you about. In Rock, you're essentially writing a compiler that compiles to two different targets, web assembly and assembly assembly.
00:40:54
Speaker
Well, more than two. So we have four different compiler backends, which is to say things that output the final artifact. So WebAssembly is one. Another one is x86 assembly, or x64 assembly. Another one is arm assembly.
00:41:10
Speaker
Sorry, I'm saying assembly. I mean machine code. WebAssembly is whatever, binary. Same thing with those. And then the last one is LLVM, which is in its own category because A, it's different than all those other ones. And B, LLVM itself can actually compile to WebAssembly and to ARM and x64. The problem is that it's quite slow.
00:41:32
Speaker
So we use LLVM when you do an optimize build. You pass dash, dash optimize, and now you're using LLVM instead of one of those other ones. And basically, what that means is your compiled program will run faster, but it's going to take longer to compile. So even if you tell LLVM to do zero optimizations, as it turns out, it's still quite slow to generate that code to the point where what we were seeing was on non-trivial rock projects,
00:41:57
Speaker
almost all of the time in compilation would be waiting for LLVM and also for linking, which we're doing our own linking as well. But basically it was like all of the parsing, name resolution, type checking, mono-orphization, all of that was just kind of a drop of the bucket compared to waiting for LLVM.
00:42:12
Speaker
and then waiting for linking. So yeah, we ended up just doing our own like, go straight to machine code. Those are partially in use right now. Right now, only the REPL is using all those. We haven't quite integrated it into the full build system. But that's kind of like one last step that we've got to get over to be able to use those dev backends, as we call it, like the development backends.
00:42:34
Speaker
But yes, there's a lot of that going on at the compiler. I'm sort of stepping back and thinking of the scope of this. And you don't have a background in writing programming languages, right? That's true. This is the only one I've... Well, I can't see that.
00:42:49
Speaker
I've written the whole thing. I mean, I'm not even the number one committer anymore. I've never tuned in. Someone's passed me by. Folger De Vries. Shout out to Folger. He's awesome. But I mean, we have a bunch of people and they're all sort of have different areas of expertise, like things that they're like the best at.
00:43:06
Speaker
I'm really not the best. I don't think it any one thing in the compiler anymore. Like when I started, it was just me, like all the commits. But now like for any, if you look at any point in the compiler, I can say, well, Brian Carroll is the WebAssembly guy. Like he's your man. If you want to know how the WebAssembly part of things works.
00:43:22
Speaker
If you want to know about the linking, talk to Brendan. If you want to know about type checking, especially when it comes to abilities, talk to IaaS. And if you want to talk about, you know, monomorphization, talk to Folkert. And, you know, it's really become a lot more of a sort of the more time goes on, the more I'm
00:43:40
Speaker
more time I'm spending on like project management and like thinking about how all the pieces fit together and like who's working on what and like design stuff and less and less like I'm sort of like driving the project forward through code because there's other people who are doing those things like you know better than I can.
Design Focus and User Experience
00:43:59
Speaker
I actually ended up spending a lot of time most recently on coding the website.
00:44:03
Speaker
Because not that we didn't have people who are capable of programming a website, but more because I'm just very particular about how I wanted things to be communicated and so forth. And how things to be presented. So a common question I'm asking myself now is,
00:44:21
Speaker
what can I spend my time on that is sort of irreplaceable to me, where I'm like, it's something that even if I could delegate it, I really don't want to because I feel very protective of that particular thing. And certainly one of the things is like, how are we communicating about the language? That's the thing that's very important to me that I really want to control, whereas with something like type checking or monomorphization or code generation, those are very, very important. But I feel a lot more comfortable explaining to someone else what the goals are and then just sort of saying, OK,
00:44:50
Speaker
You got this. It's interesting how the project has evolved over time in that way. Interesting. I've got to ask you about that, but I have to briefly, since you brought it up, ask you what's Rock's website written in?
00:45:04
Speaker
Oh, a combination of things. So the way I think about the website is, at the end of the day, I really want the final compiled artifact to have certain characteristics. It's really important to me that, OK, so a really simple example of this. Back when Brian Carroll first got involved in Rock, we didn't have any WebAssembly support at all. Basically, people would ask, hey, does Rock target WebAssembly? And my answer would always be,
00:45:30
Speaker
Technically, LLVM can admit that, but we haven't really tried. Brian completely changed all that, so he wrote the whole dedicated WebAssembly backend without LLVM at all, just going straight to the binary. He just completely overhauled Rock's ability to compile WebAssembly, and now actually WebAssembly is the most complete backend that we have now. Thanks, Jim.
00:45:49
Speaker
So shout out to Brian. But basically, he was asking, why is it not more prioritized? And I said, well, honestly, we just don't have people who have use cases in mind for it. I mean, the main thing that I'm excited about for RockTarting WebAssembly is I would love to have a REPL on the home page that's running completely in the browser so that if we ever get on the front page of Hacker News, it won't flood our tiny server and take it down. And then people are trying to come and try out the REPL, and they can't because they're getting errors because our server is host.
00:46:19
Speaker
And I mean, very recently that literally came up because we have a completely static website. We have no, like, there is no rock server backing any of this stuff on the website. It's all on Netlify and just static assets, including the web REPL, which Brian got down to six megabytes because, which is, you know,
00:46:37
Speaker
Not nothing, but also it's the whole rock compiler. When you use that REPL on the home page, every time you enter something, it's compiling WebAssembly on the fly. It's like compiling, monomorphizing, type checking, generating WebAssembly, and then actually sending that WebAssembly back to JavaScript so that JavaScript can evaluate it. Because besides no DOM access, another thing that WebAssembly can't do is WebAssembly is also not allowed in the browser to run more WebAssembly. So the WebAssembly in the REPL has to go
00:47:02
Speaker
say, hey, JavaScript, here's some new WebAssembly to run. The JavaScript says, cool, I'll run it. And then tell the old WebAssembly what the answer was. So there's a lot of intricate machinery going on in that little rectangle. But so that's the type of thing where it's really important to me that
00:47:18
Speaker
That runs really well. I even spent time, we have a list of sponsors across the bottom, corporate sponsors. Which, if anyone is interested in sponsoring Rock, by the way, we happily accept donations on GitHub and Libera Pay. I'm not sure how to pronounce that. And also corporate sponsors, just DM me on Zulip if you're interested in that.
00:47:38
Speaker
But they all have logos that thankfully are SVGs. So I actually inlined all those logos into the HTML so they wouldn't need extra network requests. And also, I used classes for the white versus black parts of them so that their letters are still visible in light mode versus dark mode.
00:47:54
Speaker
So stuff like that is really important to me. How all of that is generated is actually not that important to me. So I actually used to just use plain HTML. And then at some point, someone implemented a little rock DSL for generating static HTML that looks a lot like LMHTML. So it was very familiar to all of us. And I started using that just as kind of a way to get like, OK, we'll have a comment header bar across all of these, just like basic code reuse stuff.
00:48:19
Speaker
And so now a lot of it is written in that. And then also, it does some markdown parsing. But at the end of the day, if we were doing a really complicated web app, of course, I would reach for Elm. But this is just a static site. It's not like we need Elm architecture for complicated state management. It's like we have a tiny sprinkling of JavaScript for a couple of little interactive things.
00:48:42
Speaker
But it's really like, my goal for the website is really that it's largely static. And actually, one of the things that I try to do is I try to make it so each page, to the extent possible, works without JavaScript. So the homepage, actually, if you disable JavaScript, because there was a time in my life when I tried browsing the web that way, and eventually I kind of gave up, but it was really nice how many pages loaded instantly.
00:49:04
Speaker
If you go to the home page and you turn off JavaScript, what you'll see is everything works except for the REPL, which is just hidden because that can't work without JavaScript. But everything else works, including at the bottom, we have a large code sample that's interactive. You can click on things to show an explanation of what that piece of code is doing. I actually did all that using CSS so that if you're browsing with JavaScript turned off, it still feels like it works.
00:49:29
Speaker
So anyway, that's, that's what's important to me is like the final end user experience, not so much like, you know, how we're building it. Okay. I can see, I can see why you're holding onto the design of the language rather than the implementation there. I have to ask. So if someone's curious to play around with rock, what's the status of rock at the moment?
00:49:50
Speaker
So you definitely can. So we're before our first numbered release, like it's all nightly releases right now. So there actually isn't that much stuff changing right now. If you go to the community link on the web page, we kind of have a little link to some sort of upcoming plans of things that are like in the works. There's a known coming breaking syntax change around how imports work, which is motivated by a really, really cool feature that I'm very excited about. But that's going to take
00:50:19
Speaker
So hopefully we'll ship that in 2024. We'll see. Um, but basically it's, uh, it's from my perspective, like I don't see how I put this, um,
00:50:32
Speaker
OK, so there's a lot of different trade-offs around introducing numbered releases to a language. And one of them is a communication thing. As soon as you have a version number, people start having different expectations. I remember seeing a really strange in retrospect comment, but at the time I was kind of like, yeah, I kind of know what they mean. I think it was on Hacker News, where someone basically said, I have certain expectations of an ODOT to release of a language.
00:50:59
Speaker
And I remember thinking, I know what he means. It's not like I have no expectations. But at the same time, it's kind of weird. It's clearly what someone's trying to communicate with a 0 dot release of a language is this is unfinished. Expect things to not be totally polished and that there's going to be breaking changes.
00:51:21
Speaker
So I kind of like partly I'm thinking of it as like, well, maybe no version number is the new ODOT one. That's how you really communicate that like, look, you're dealing with something that's unfinished and like still has a ways to go. So the reason that we decided to sort of redo the website and make it like a real website, because before we kind of had this placeholder that just had a bunch of texts about like explaining things. The motivation there was to just sort of communicate like, hey, this is a real thing you can try now.
00:51:46
Speaker
Everywhere that you can install it or in the tutorial and stuff, we try to take care to note that, hey, this is an unfinished language. It's definitely like you're going to hit compiler bugs. You're going to hit things that are just not there yet. So I would definitely encourage people to try it out. I would say if you want to try and use it at work,
00:52:03
Speaker
just know that you're entering risky territory. It's not going to be totally smooth sailing because there are things that are unfinished, that are unimplemented yet, that there's going to be compiler bugs, compiler crashes. So we're comfortable using it at work because I'm sort of there to make sure that things can't go too wrong.
00:52:24
Speaker
But definitely, I think if you want to start using Rock on a more serious project, I would strongly recommend getting involved in Zulip chat and telling people, hey, here's what I'm planning on doing. And then people can tell you, well, here's what to watch out for. Here's the things, the sharp edges you might run into. And we can give you some support with that.
00:52:41
Speaker
Whereas like a year ago, I probably would have just said, don't do that. Like don't attempt a serious project at rock because it's just not going to go well. Now it's more like, well, as long as you're OK with the sort of bleeding edge experience and you're comfortable running into some problems and having to work around them, you can totally do that now. And it's sort of crossed over that threshold where I went from sort of recommending against it to being like, well, let me give you a bunch of caveats. And if you're OK with those caveats, then
00:53:08
Speaker
go for it. There's a lot of things to really like about the language already today. Obviously, we're working towards a future in which I can just say, it's great, go try it, but we're not there yet. It's growing up. It's growing up. It's not at that level. Away from production, what about the other end of the spectrum? If you want to learn rock, is there a good way to learn it at the moment or are you assuming someone's coming in with a certain amount of knowledge?
Future Development and Expansion Plans
00:53:30
Speaker
Oh, sure. I mean, so there's a tutorial that just kind of explains, like, here's how to make a command line app in rock. We should probably also make one of those for other platforms, like the web server. I've sort of toyed around with the idea of maybe expanding the tutorial to start you off building on the command line platform. And then because when I first wrote the tutorial, that was the only one we had. And then sort of maybe transition towards the end
00:53:49
Speaker
being like, OK, and now let's build a web server, and then you can use the command line to talk to your web server you just built. I think that'd be kind of cool, but we'll see if I actually do it. But at any rate, the tutorial, I think, is plenty enough to get going on application development. However, if you want to learn how to do platform development, basically the procedure for that right now is just kind of like ask people, because there isn't a tutorial for that. And part of the reason there isn't a tutorial for that is that that's an area that's sort of heavily under construction, and the tutorial would get outdated pretty quickly if we did have one.
00:54:19
Speaker
So yeah, hopefully that will change also over the next year, but we'll see. Okay, so maybe I'll make this the last question, but do you foresee a future where there's like a package manager where you download libraries and another package manager where you download platforms or how's that gonna work?
00:54:35
Speaker
Oh, so I think it would be all one package manager. So I mentioned earlier that there's a syntax change for imports. Part of the motivation for that is there was a longstanding design question of exactly how do you want to be able to share common packages across platforms. So a really easy example of this is error reporting. So my previous job, we used Bugsnack for error reporting. At this job, we used Sentry. Let's say that someone wants to publish a Sentry or Bugsnack package that says,
00:55:02
Speaker
Here's how to report an error or the report to log something that's happened. Well, you can imagine wanting to use that on a web server platform, also on a CLI platform, maybe in your native desktop app platform, mobile app, whatever. All of these things sort of raise the question of, well, if they all have their own different set of I-O primitives, and this is something that wants to do I-O, how do you write something that's sort of platform agnostic while still that does I-O operations? So we came up with a design that actually has
00:55:31
Speaker
Oh, it's awesome. I'm really, really excited about it. If you want, we can get into it. But basically, the upshot of it is that what will end up happening is that you write that platform, and essentially, it declares in a way that turns out to have a bunch of side benefits, like, here's what I need in order to be able to run me. I need some way to do HTTP requests, which means I need a function that's given a request, run this task, and then it's going to give back a response.
00:55:59
Speaker
if you can provide that permit for me if you have that available somehow then you can use this package if you don't have that i'm sorry i don't i don't work so in your hypothetical database extension platform where you just don't have. You know that function available then you just can't use this package a compile time like you it's not like you know you run and you get an error it's like you just cannot depend on that you'll get a build error.
00:56:21
Speaker
So what's cool about that is that it's also flexible. So even if the command line app has a slightly different way of doing HTTP than the web server and a slightly different way than the native desktop or the mobile, whatever, it doesn't matter because at the end of the day, as long as you can provide that function which does that thing, then Bugsnag's cool and you can use it and just everything just works.
00:56:43
Speaker
So, that's sort of where the design ended up, so now you can have completely platform-agnostic packages, even if they do I.O. Obviously, if they don't do I.O., it's like, okay, you only get done on the standard library, you know? Go for it, no problem. That's easy. And who ends up writing that kind of bridge? If you've got two platforms with the same capability but different APIs, who bridges them into the bug stack?
00:57:05
Speaker
Oh, I mean, there's no bridge necessary, really. So basically, the design of the imports feature that makes this work nicely is such that as soon as you import Bugsnag, it sort of gets wired up, if that makes sense. It just looks like, basically, if I'm writing the Bugsnag module, I can declare at the top of my module, I need access to this function that has this type. And if I don't have access to it, then give an error. If I do have access to it, then it's like, this is how I do HTTP. So I just call it.
00:57:35
Speaker
And I don't know what the implementation of that function is going to be yet. But I don't care, because I'm just like, look, that's a dependency I have. In order to import me, you must provide this. Given that you provided this, I'm going to call this and all my implementations, and that's it. OK, but if you've got one platform that has two platforms with a HTTP API, but one of them thinks that the URL should be first and the method should be second, and the other one thinks the method should be first and the URL should be second.
00:58:02
Speaker
Yeah, great question. So the answer there is that culturally what we want to encourage is when you're dealing with operations like that, we want to encourage platforms to do the lowest level thing possible. So rather than saying I'm going to like Bugsnag saying I need an HTTP that requires a URL that's a string versus a URL that's a list of bytes or whatever.
00:58:25
Speaker
It's rather that you have something much more low level than that. That's like, I need something that has these exact pieces to it. And if someone wants to build an HTTP request thing on top of that, they totally can. And maybe Bugsnag depends on that convenience wrapper that's more ergonomic and has a GET function and a POST function, whatever. But
00:58:46
Speaker
What the platform should provide, every platform should provide that wants to provide HTTP, is something that's super low level that's just like, here you go. This is the bare minimum. It's all the information. And you can actually have a package that defines what that is. So you can have a package called low-level HTTP. I'm not sure exactly what the name for that should be. Yeah, we've talked about low-level HTTP, HTTP effects, something like that. That basically, every platform can say, OK, cool. I will depend on this and just use it as a way to sort of
00:59:15
Speaker
specify what I'm providing to you. And I'm going to conform to that. And then now the ecosystem can say, oh, well, as long as you're depending on HTTP low level, which is also what I depend on, then we know that these functions are going to sync up. And then different people can say, well, I'm going to have a different wrapper around this, a different convenience wrapper. And it doesn't matter, because as long as your library is using that sort of common denominator of like, this is the lowest level idea of what an HTTP request is, then everybody can work with everybody else.
00:59:42
Speaker
OK, OK, so you almost need it's running me like the hardware abstraction layer you get in like embedded device programing. Maybe, but like a much, much simpler version of that. Yeah. Remind me where we go to try out rock. Rock, so ROC dash laying dot
Conclusion and Call to Action
01:00:00
Speaker
org. Awesome. I think it's time for us to go and do that. Richard, thank you very much for joining us. Yeah, thanks for having me.
01:00:08
Speaker
Thank you, Richard. I will say if you do go and check out rock-lang.org, link in the show notes, there's one extra thing in there I thought was worth highlighting for a bit of information design. It's got a section in there called Code Samples with Explanations, and there's a block of rock code that you can look at. You kind of expect that for a language site, right?
01:00:30
Speaker
But if you click on any line in that block of code, it gives you an explanation of what that line's doing and which language features it's trying to introduce you to. And it's just a nice way of, in a compact way, going a bit deeper on what it's trying to explain to you. And I mention that because if you're ever writing a site that has to explain itself through code, I think that's worth looking at and filing away for future projects.
01:00:57
Speaker
Before you file away, or before you file me away, which way around does this work? Before you file me in this episode away, if you've enjoyed it, please take a moment to like it, rate it, share it, subscribe, notify, comment. There are so many verbs. You know which ones apply to your platform. Please, the feedback is really helpful. So do take a moment. And I think that's all there is to say for this week. So until next week, I've been your host, Chris Jenkins. This has been Developer Voices with Richard Feldman.
01:01:26
Speaker
Thank you for listening.