The Roc programming language (Interview)

30:41It has to prompt me. And the script author has no way to work around that. Um, I, I, as the runner of the script, all I have to do is change one. I don't even need to read the rest of the file. I'll run whatever you gave me. And I don't have any fear that it's going to break my computer because there's this way of basically sandboxing the whole script even if the author did not want it to be sandboxed and was trying to do something malicious interesting so let's say you have a dot rock file out there on your server and i go ahead and download that with my rock program yes do i then like pre-pinned this line into the file and then execute it or like how do you actually get that done something like that um you know we can go on a big technical tangent about this.

31:21But so basically, Rock has this concept of we call it platforms and applications. And the basic idea is this. Every Rock program is designed to be sort of embedded in. You could think of it as kind of like a framework, although a platform is not really a framework because it's got more responsibilities than that. It's got sort of a bigger scope than a framework. But it kind of comes from this observation of like, if you're building a web app, let's say in Ruby, you're probably building it on like Rails or Sinatra or something. You're not really starting from scratch and like empty like dot rb no dependencies you know thing you're gonna you're gonna build on top of something if you're building a game you're probably gonna build it on a game engine you might like i know some game programmers are really hardcore and start from scratch but like usually you're building on top of something that was already there so we sort of formalize that and because we formalize that into a first class language concept there's always a thing you're building on top of there's a bunch of really cool benefits that we get out of this so the platform is basically like here is a rock api so this is like the equivalent of like your rails api like here's what rails exposes here's the concept of like you know model view and controller that rails has and so forth and then under the hood there's a lower level language that's implementing a whole bunch of stuff including all your io primitives so for example one of the things that's cool about this is that it means that you can get sort of this domain specific experience which i loved from elm but it's now applied to more different domains so really simple example of this is if i'm doing a cli app i really want that cli app to have like write to standard out that's an obvious io thing that i want to do and i also want like read from standard in that's also a really common thing to want to do in a cli but if you're doing like a gui app like a desktop app like you know like a music player or something like that do you want standard in is that like a thing like no why why would you want that as an io primitive that's if anything kind of a foot gun that like if i have some dependency that's blocking on standard in that's just going to be a bug on a web server do you want standard in like do you care about that so the point is that like there's different io use cases for different domains a really clear example of this is in the browser like you mentioned that rock compiles the web assembly if you're in the browser do you want like a standard library in your language that has like file system io in it like rust does like rust also compiles the web assembly but rust standard library is like cool here's how you open a file and write to a file and it's like i can't do that in the browser so if i have like any dependencies that i'm building on that are doing that it's like I don't actually know what they're going to do in the browser, but it's not going to work because the browser doesn't have a file system.

33:46So what's cool about this is because when you're building your ROC application, you have to pick a platform and the platform not only gives you your domain specific stuff. Like if you're building a web app, you use a web app platform and it's like, here's how to do, you know, requests, requests and responses. And if you're building a CLI app, it's like, okay, here's main and here's how to do your IO for that. But everything is sort of tailored to like the exact use case that you're building for. If I'm building a web app, I use a web app platform. And there are already several of those out there in the wild in the rock ecosystem.

34:14I'm building a CLI app. I do this. If I'm building a graphical app, I do this. You know, game app, right? Use this like game engine platform. Getting back to the scripting use case. So what you're doing there is you're swapping out the platform. So what you can do is if somebody gives you a rock app, like a.rock file, that's a script that they want you to run. And it says, it has to say, here's my platform. And let's say they used some generic scripting platform the one line of code that i change is i swap it out for something called like safe script which is an api compatible platform with the one that they used so everything's still going to work except that safe script has for its io implementation under the hood all of these like yeah if you ever tried to read from like etsy password i'm gonna stop the script and prompt and there's no way the script author could do anything about that like we intentionally do not have like an arbitrary like ffi foreign function interface where like the script author can be like, aha, I'm going to sneak in some C code in here and get around your system.

35:07It's like, no, no, no. You just literally all you get is like what the platform provides you. And so if I, as the consumer of that, just swap out the platform for something that's API compatible, there's absolutely nothing the script author can do to get that. And there's, there's no escape hatch that they can use to circumvent that. That's pretty cool. So these platforms, are they effectively like if I was going to implement a platform, am I just like, it's like an interface or an API or is like a, another rock program that By Ron, or how does that whole deal fit together? So there's two pieces to every platform.

35:36There's the public API, which is what the application authors consume. So one of the hard design constraints of platform authoring is that if application authors need to not have any, they need to not care what's going on under the hood with the platform. They need to just be like, I don't know. Like I only know Rock. I don't know any other programming languages. I only know what Rock code is. And so I don't care what you're using behind the scenes. But if you are doing a platform, like you are a platform author, you do need to know not only how to make your public facing rock api that application authors are going to see but also the lower level piece which has to be written in some other language um so people have written these uh we call the host is like the the lower level part people have written these in rust and zig and i think maybe there was a c++ one but you can use any language you want we also have some like these are really like hello world level things but like swift like if you want to do an ios app um like in the rock repo you can see these examples um uh java people have done like a bunch of different jvm languages where you can just like write a.rock file and like, hey, here it is running on the JVM.

36:32One of the cool things about this is it means that Rock is also quite good at getting embedded into existing code bases, because you can basically say like, I'm just going to write a bespoke one-off platform that's just like my whole code base. And I'm just like exposing like entry points for the Rock code. And now you can be like, oh, cool. I have this big Java code base and I want to like write part of it in Rock because I think the ergonomics are better or the performance is better. We also have a really strong value of runtime performance. So we actually compete with We want to be faster than Go, but not quite as fast as Rust or like Zigg or C++ because that would require introducing memory and safety.

37:07But faster than all the like, I think Go is the fastest like currently garbage collected language. But yeah, so you can just sort of insert yourself into existing code bases. And then like that code base can just kind of import a.rock file. And one of the other things that's really cool about Rock is that we don't have like a heavyweight runtime. There's no like virtual machine or anything like that. it basically compiles down to the equivalent of if you're writing rust code and you're opting into rust's automatic reference counting all the time that's very very close to what you're getting with rock um rust programs can run run faster than rock programs because in rust you don't have to reference count everything you can just like in many cases choose not to do that um but in rock that's just sort of done for you automatically behind the scenes which makes rock code a lot more concise and a lot simpler than rust code among other things but it does mean that like you don't need to worry about like oh am i going to have like you know a javascript vm that's like running a rock vm it's like there is no rock vm it's just like you just call functions as if they've been written in c or rust or whatever else and they just sort of slot in there

38:16what's up nerds i'm here with kurt mackie co-founder and ceo of fly you know we love fly So, Kurt, I want to talk to you about the magic of the cloud. You have thoughts on this, right? Right. I think it's valuable to understand the magic behind the cloud because you can build better features for users, basically, if you understand that. You can do a lot of stuff, particularly now that people are doing LLM stuff, but you can do a lot of stuff if you get that and can be creative with it. So when you say clouds aren't magic because you're building a public cloud for developers and you go on to explain exactly how it works, what does that mean to you?

38:50In some ways, it means these all came from somewhere. Like there was a simpler time before clouds where we'd get a server at Rackshack and we'd SSH or Telnet into it even and put files somewhere and run the web servers ourselves to serve them up to users. Clouds are not magic on top of that. They're just more complicated ways of doing those same things in a way that meets the needs of a lot of people instead of just one. One of the things I think that people miss out on, and a lot of this is actually because AWS and GCP have created such big black box abstractions. Like Lambda is really black boxy.

39:24You can't like pick apart Lambda and see how it works from the outside. You have to sort of just use what's there. But the reality is like Lambda is not all that complicated. It's just a modern way to launch little VMs and serve some requests from them and let them like kind of pause and resume and free up like physical compute time. The interesting thing about understanding how clouds work is it lets you build kind of features for your users you never would expect it. And our canonical version of this for us is that like when we looked at how we wanted to isolate user code, we decided to just expose this machines concept, which is a much lower level abstraction than Lambda that you could use to build Lambda on top of.

39:58And what machines are is just these VMs that are designed to start really fast or designed to stop and restart really fast or designed to suspend sort of like your laptop does when it closes and resume really fast when you tell them to. And what we found is that giving people as primitive is actually there's like new apps being built that couldn't be built before, specifically because we went so low level and made such a minimal abstraction on top of generally like Linux kernel features. A lot of our platform is actually just exposing a nice UX around Linux kernel features, which I think is kind of interesting.

40:31But like you still need to understand what they're doing to get the most use out of them. Very cool. OK, so experience the magic of Fly and get told the secrets of Fly because that's what they want you to do. They want to share all the secrets behind the magic of the Fly cloud, the cloud for productive developers, the cloud for developers who ship. Learn more and get started for free at fly.io. go again fly.io so how close are you to catching go and when and how are you going to catch it uh well in terms of popularity or performance no in terms of performance so arguably we already have uh so this was back in like 2021 we did a um proof of concept where the benchmark actually gave a talk about this at strange loop was called um outperforming imperative with pure functional programming uh and basically um we did this benchmark where it was a quick sort on i think it was like a million um 64-bit floating point numbers and we compared rock go rust no it might have been c++ um and uh yeah c++ i think uh rock go c++ java and javascript and for that task we just barely edged out go we were slightly faster than go and rust or c++ was faster than us obviously i do think in the new compiler we will probably be slightly slower than go at that one like like just on the other side of it because one of the optimizations that we use to get there we decided was not worth it anymore like given our experiences with it and we're gonna planning on dropping it from the new compiler so i wouldn't be surprised if that one like put us like slightly below instead of slightly ahead on that one particular benchmark um but that was always kind of a silly benchmark in the first place because it's like who cares about like doing than that handwritten textbook quick sort with no optimizations you know like no handwritten optimizations but it was it was kind of a good sign i mean basically the the short answer for like how we can be faster than go is that like go we do what's called like unbox data structures a lot so if you have like a struct in go um which would be kind of the equivalent of like a object like a plain you know unadorned object in javascript um just some data no like you know runtime information or anything on it.

42:41In Go, that's not a heap allocation. It's just like plain old stack memory. It's just really straightforward. Same thing in Rust, same thing in C++, same thing in Rock. We also don't heap allocate our closures, which is very unusual for a functional language. We have spent a lot of time making that happen. And that was one of the reasons for the rewrite was that the approach that we used in the current compiler turned out to have some bugs that we thought were just like, oh, we just need to squash these bugs and then we'll be fine it actually turned out the very last sliver of like those bugs which which do come up actually are not fixable incrementally they require a really serious re-architecting of multiple parts of the compiler we do have a proof of concept of like if you do that that does fix it um but the proof of concept is like a really tiny subset of rock so it's like okay now we need to productionalize that for real but yeah so basically like similarly to rust um we don't like box things by default uh we do automatic reference counting for memory management and we use llvm much like rust and c++ for compiler optimizations and llvm is just really really good at optimizing your code go does not use llvm so the fact that we are sort of like at parity in terms of like generally speaking how we do memory management like which things are heap allocated and which ones are not but we get llvm on the other side generally means that we can just kind of be faster than go the one counterbalancing fact is that we do have more functional apis and again without going on another long tangent which we can go on a i guess a quick one um if you're interested about our opportunistic mutation um there are api differences that might mean that go is faster than us at some things and also vice versa i guess the brief tangent about that is uh opportunistic mutation is also something that we are unique in like industry focused languages for doing there's some research languages that do it so we're not the first to come up with this but the basic idea is this uh in a lot of functional languages you have like immutable apis you're like immutable data is awesome it has all these really nice properties it's great but there's a downside that like if you try to do this in javascript for example you're going to be like defensively cloning stuff all the time or like yeah automatically right it's just like cloning cloning cloning like all these things like oh it's immutable but i need to get a new one so i'm going to like clone the whole thing and except one thing is going to be different that's extremely slow um so what we do is uh i call it opportunistic mutation there's other names for it in like compiler literature um like functional but in place but that's so long to say um i like opportunistic manipulation that's it's long it's impressive and it sounds like it rolls off the top i'm already saying it so i like that name yeah so so the basic idea is that it's like if you so we do automatic reference counting um let's say that i'm like uh for example i want to append something onto the end of a list first of all in most functional languages list refers to like a linked list uh but for us it's more like javascript or python where it's actually like an array and like a flat array in memory normally in javascript like you're like i want to append something onto the end of the list and get back a new list at the end of the day, that requires cloning the entire existing thing and then like sticking something on the end.

45:33And now you have the new one. Well, that's terrible for performance, obviously. Much faster is to mutate it in place and just say like, yeah, just stick something on the end. We're done. So the CPU likes that. But as a programmer, if you're trying to do everything with immutable data, because you like the semantics of that and how things sort of change together and you don't have to like worry about like, wait, did it change at this point or that point? It's just like, no, everything just kind of flows from one step to another. How do you get the performance and the semantics? And our answer to that is this opportunistic mutation thing.

45:59Really, really simple idea. It's basically like at runtime, we look at the reference count and we're like, okay, if the reference count is one, guess what? Nobody else is observing this thing. So if I just go ahead and stick it on the end, nobody's going to know. It's going to be fine. If the reference count is higher than one, then I can't do that. And I do need to clone it first, but then the clone now has a reference count of one because I just made it. So from then on, like the rest of the pipeline, it's all going to trigger the opportunistic mutation. So basically you can think of it as like, it is potentially doing the like, you know, clone your thing, but kind of our hypothesis.

46:34And so far this has proven to work out in practice, um, was that like in practice, the way you write your program tends to be, you're only passing around things that only are being used in one place. Most of the time, if you're going to be modifying them anyway. So the amount of cloning that you, your program needs to do actually should be extremely extremely minimal and that's exactly what we've seen in practice um there are sometimes cases where it's like well i wrote my program in this way but it was doing unintentional cloning and then i got it to be much faster by like kind of refactoring it to just do things a little bit differently so far that's gone fine uh as far as like educating people when they're like hey my rock program is slower than i expected like you know why and then we look at it like oh just write it in this slightly different way instead of this way and It'll be totally fine.

47:20It kind of remains to be seen like, I don't know, like what does that look like if you have a giant rock code base? Is it like a problem or not? But given the fact that a lot of people write like JavaScript in like a functional style where it's just cloning all the time, clearly it's not like a deal breaker for some people. But I hope is that what we've seen so far will continue to scale where it's just like, yeah, you just get in the habit of writing things in like a style that's totally reasonable and looks nice and is easy to understand and just has these really nice properties. And what you get is the performance of a language that's mutating all the time, but the semantics of a language that doesn't even have a formal concept of mutation except behind the scenes as a performance optimization.

47:57So way back in the day, I was writing some Objective-C because I was trying to be on Apple's platforms. I remember they added ARC, automatic reference counting, at a certain point. And either I was using it wrong, and which is probably the case, or it would get screwed up. and maybe it's because you could do it manually or automatically, but sometimes the count would get off and things would get funky. And I'm wondering if ARK, was that just a circumstance of Apple platform changing over time? Is ARK solid where it's like, if it says one, it's correct. It's counting correctly no matter what, or could it be off and it thinks you guys have won, but there's actually something else referencing it and the count got off somehow.

48:38In our case, we actually have never seen that be a problem. I mean, I guess there might have been at some point we had like a bug and like you know our standard library or something reference counting uh one of the things that i've learned like the hard way is that reference counting if done manually is super error prone um it's like if you're if you're trying to do the increments and decrements like it that was one of the hardest things in the compiler to get right in the first place was like where to insert the increments and decrements and on top of that we also have optimizations that are like oh in this case we can see that it's going to increment it and then like later on the same function decrement it before it gets passed anywhere so just eliminate both of those don't bother but like for example early on we were trying to um uh do some of this by hand in like one of some of the early platforms i just remember it was like it's so easy to get it off if you're doing any part of it by hand even if most of it is automatic so i'm guessing that that was really a case of like objective c letting you do it either by hand or automatic and then the the by hand parts like messing up the automatic parts i totally remember that i think you're absolutely right it was like i had some by hand and then i'm like switching over to the automatic and it's like in that migration, there was just no way that I was going to be right because I had some manual things that would screw up the automatic.

49:44And I was like, this is a total mess. I'm better off just managing myself. But that was in that circumstance. I imagine if it's at the compiler level for you and you're never doing manual in the programming language itself, it's probably way more reliable. So if you're just using Rock and you're doing application development, it just feels like a garbage collected language, except that there's no concept of a GC pause because a traditional like market suite garbage collector or like tracing garbage collector is like the category of those things. Like there is some moment where they're like doing a, you know, like traversing the heap and like finding what can be freed.

50:19Modern tracing garbage collectors are much better than this than they used to be in terms of like minimizing GC pauses and latency and stuff like that. But reference counting, one of the reasons that reference counting is pretty cool on like applications like UI development is just that it's totally incremental. It's like you're just constantly like freeing little like bits here and there as the program is running so there is no like you don't need to do something super fancy to avoid like pauses because you just naturally don't have pauses it's all sort of like spread out over the you know all the different allocations in the program that's really cool i mean take take that go come on where's that yeah but i mean in all seriously in all seriousness like part of the reason that we like to be competitive with go is just that i think go does a really good job of delivering really good runtime performance and really good compile time performance but you know i would rather use a language with rock semantics than a language with go semantics but i still want those things i still want it like we want to compile faster than go and run faster than go because why settle you know like we we have the potential to design things in a way where we can pull that off and we want to pull it off so um you know realizing those dreams is like uh i don't know it's been exciting every time we've gotten a result where we're like nice it's actually like it wasn't just possible in theory we pulled it off in practice and i'm really excited to like ship 0.1.0 and like let people actually try out the whole experience yeah that's gonna be rad well you mentioned go and or maybe i did we both did and it made me think of if error not equal nil because that's what i think of with go which makes me think about error handling makes me think about undefined and nulls because oftentimes that's what you're checking all the time and rock does not have a null or a error or a nil or an undefined it also does not have an optional maybe thing but all there's all but still sometimes you have a thing sometimes you don't so like how do you handle the circumstance where you might be getting some back something and you might not yeah so i'm biased but i think rock has the best story of this of any programming language um but i'm biased let's hear it so let me explain how it works so so although we don't have uh something like option or maybe uh we do have result and result works pretty much the way that it works in like rust or ocam or something like that which is pretty much it's like maybe except that you have um the success but also you have an error type so it's like maybe it's like i either have this thing or i don't so much like null result is like I either have this thing or I have something else that's like an error that explains what went wrong.

52:52So oftentimes that could just be a string that's like, oh, I couldn't find this thing because of whatever reason. And a special case of that is you can just have nothing for the error type. It's just like an empty error type where there's no extra info. And that kind of works the same way as maybe. The reason that we have that particular design is centralizing everything around result means that you can improve a lot of ergonomics and say, like this is just for saying I either have this thing or I don't like when you're returning it from something as opposed to using it for like data modeling as well so it would be really weird to have for example in your I don't know data model you're like representing like here's a user or something and like maybe they do or do not have an email address it would be weird to put a result in there and say like oh like they either have an email address or like error no email address in my like data model that's more of like a functions return result because it's like this operation succeeded or it failed it's not really like about data that's the like faq entry of like you know why did we choose not to have options so we do still have result now the reason i say i think we're the best at error handling is actually something that's more to do with uh what we call anonymous some types so a lot of programming languages have a concept of i guess the most common term i've heard for this is algebraic data type um so this is something that a lot of people have said they want and go and the low level version of this is what's called a tagged union that's what zig calls them for example um or or c and basically what it is is it's just like um you have like some series of alternatives so you can say let's use like uh traffic light colors you have like red green and blue a lot of languages have that concept and it's called like an enum um so it's like an enumeration of like three different options red green and blue it's exhaustive meaning that like if you have one of these stoplight color values you only have red or green or blue there's no such thing as like other that's not really a thing right now if you want to introduce a concept of other what algebraic data types let you do is you can say red uh i said blue what what color traffic lights green and blue i don't know i was just rolling with it no i'm just i'm i'm often like graphics land right rgb all right rgb in this hypothetical world, we have traffic lights that have blue in them.

55:03Let's go red, green, yellow, like actual traffic lights. Okay, fair. Different order. So let's say that you want to expand that and you do want to introduce a concept of other. What you can do is you can say red, green, yellow, other, and then other has what we call a payload, which means it has some additional data associated with it. So you could have other and then like a string payload that basically says, okay, it's either it's red, it's green, or it's yellow. or if it's other, then I have this string that describes what the other color was. And the critical distinction there is that if I have red, green, or yellow, I don't have that payload.

55:37It's like those are just like, nope, it's just the value and nothing in there. Only if I'm in the other case do I have this extra piece of data. Now, in a lot of cases, what you end up doing with algebraic data types like this is you end up having payloads in all of the different options or most of them or all of them but one or something like that. And so what's really nice about them is it allows you to really specifically say like, okay, under this circumstance, I need to provide this extra data. Under this circumstance, I provide this other totally different shape of data. And it just basically unlocks this like really nice experience of like modeling your data in a way where you can say like, okay, under this scenario, I have this to work with.

56:16Under this scenario, I have this to work with. and also when you're constructing that data it's like okay if i'm in this scenario i have to provide these pieces of information or else i cannot get one of these values and so it lines up really nicely between like here's what i need to provide if i'm in this situation and i'm saying like hey we're in this situation um and also like here's what i have access to when i'm in this situation and then the exhaustiveness piece of that is still there where like when you're extracting a value out of this uh it's like this is where pattern matching comes up is you can say like okay if i'm in the red scenario, do this logic, like in a, like a switch statement or something like that.

56:49Sure. Um, if I'm in green, do this, if I'm in yellow, do this. And if I'm in other do this, but also only if I'm in other, do I have access to that string? And in none of the other branches, do I have access to that? So you can do this in like TypeScript, but it's pretty clunky, um, in languages like rock and, uh, and rust and stuff where this is a first class thing. It's like super ergonomic to do that. Okay, that's algebraic data types. But what Rock has is the anonymous version of that. So it's not like everything I just told you is true and you can do all that stuff in Rock. But we have one extra thing, which is that if you want, you can also build these up on the fly.

57:23So, for example, instead of defining up front, we have traffic light colors, which are like red, green, yellow and other. I can just write a totally normal conditional that's like, OK, if this is true, blah, blah, blah, blah, set this variable equal to red. And in another branch, set this variable equal to green. and another branch set this variable equal to yellow. And Rock's compiler will just infer based on my having used that anonymously, pretty much exactly the same way that it'll infer things based on if you just use curly braces to make an anonymous, we call them records, but anonymous object in JavaScript or something like that.

57:55You don't define anything upfront. You just use them and it just says, oh, cool, I will infer that the type of that variable that you've been setting to red, green, or yellow or other with a string in it is just like, yeah, it's like either it's red or it's green or it's yellow or it's other with a string in it. No problem. I just infer that and you don't need to like define anything up front. Now, what's really cool about this is how it applies to error handling. Because now what you can do is you can say, okay, let's say I'm like trying to read from a file. This is a classic example I like to give of like why this error handling is really nice.

58:29I'm reading from a file. That file contains a URL inside that URL. I take that URL. I do an HTTP request to that URL. I get back the response and the response says like, here's some information I want to write to a different file. So this is a file read, HTTP request, file write. All of those can fail in different ways. What's really nice about Rock is that when you just call those, it just looks like the most straightforward, like just TypeScript, Go, whatever. You just like call the functions and just do the IO and it just happens. But behind the scenes, the compiler is just tracking automatically using this feature.

59:02Here's all the errors that could happen and it's just unioning them together. And at the end of the day, what that function will return that does like those those three calls is just like okay it's a result which either has i succeeded in which case here's the answer of all those things if any one of them failed you have an error type that is just an algebraic data type of the union of all the things that could go wrong so it could be like network failure from the http request it could be like you know file system was read only from the file right or it could be like file not found from the read um all those things just get put together and you can just do a pattern match on them and it's just like here are all the possibilities the compiler will tell you if you forgot one because it's like hey there was this error that you didn't handle that was in the union of these things but at no point did you have to specify anything like you can write no type annotations anywhere in that program you just call the the three functions just totally normally um and then you're like yeah it just accumulates the errors that can happen i guess one detail i did leave off is that we do do something that rust does where the sort of like error propagation is explicit rust does this with a question mark operator at the end which is what we we do the same thing so basically it's like if you want to say run this io operation and if it failed do an early return to with with the error you put a question mark at the end of that function call like after the close paren um and this is nice because it means that all of your control flow is explicit so like unlike exceptions where you have to be like defensively like try catch it's kind of like inverting that where it's like hey if this might cause an early return with an error you can see where those happen because there are question marks there you also use bangs in a certain way that i couldn't tell if it was idiom or enforced i'm assuming it's enforced the exclamation mark at the end of a call means something i don't remember what it means and is it real or is it like ruby where it's like it should mean that but you could use it whenever you want you know it's funny it's like ruby but it is enforced with a compiler warning so um this is what we call purity inference.

1:00:57So essentially the way that effects work in Rock, this is also different from, I don't know of any other functional language or imperative language for that matter that does this. But the basic idea is super simple. Because Rock's APIs are designed to be based around immutable data, you can very, very easily write a function that is doing quite a lot of stuff, and yet it's a pure function. Pure function, for those who don't know, short definition is like a pure function is one where if you call it, passing the same arguments, you are guaranteed 100 guaranteed to get the same result back like the same answer every single time same arguments same result and also it doesn't do any side effects like it doesn't affect other parts of the program that are in an observable way um so uh we actually have a concept in the type system of which functions are pure and which functions are effectful so all the io functions i just mentioned those are effectful the way you can tell the difference is uh there's two ways so from a types perspective it's a really really subtle distinction but basically like uh if you if you have like the list of arguments uh for the function and then you have an arrow and then the return type that's like the type signature for a function if it's a thin arrow like dash greater than that's a pure function if it's a thick arrow that is equals greater than that's an effectual function and so we have this convention which again is enforced by the compiler that um effectual functions have an exclamation point at the end of their name actually we did take that from Ruby.

1:02:17Ruby has that for like destructive updates and stuff like that. So basically, if you're, for example, like reading from a file, it'll say file.readbang. And that tells you that when you call this function, it's going to be effectful. Now the compiler also enforces that only effectful functions can call other effectful functions. Pure functions are not allowed to call effectful functions. And that's not because we're trying to be mean. That's just like the definition of a pure function. Right. Otherwise you're not pure, dude. Right. And one of the ways that we actually make use of this is that like this isn't just like a you know we're trying to organize things for the sake of organizing them one of the things that um the new compiler is doing is that if you're writing a top level constant like you're saying like foo equals just like the top of the file not like inside a function or anything like that we actually will um so first of all you're only allowed to call pure functions in those constants um like you can't be like foo equals like at the top of your uh you know file outside of any function and just like run effects in it but because you're only calling pure functions we actually will evaluate that entire thing at compile time you can make that as complicated as you want so you can do like really complicated transformations and like you know um not have to like hard code so many things you can like call whatever functions you want as long as they're all pure and the compiler can evaluate them all at compile time because it knows like yeah they're pure functions like they don't have any side effects it's fine like you just you just do that one of the things that's cool about this from uh like going back to earlier on we were talking about um like one of rock's goals is to be really good at getting embedded in other things.

1:03:44Not only do we not have a virtual machine, but also we don't even have a concept of like in it, like you don't have to like boot up a rock program. You can just like call the entry points and like just whatever happens happens because all of our constants get compiled all the way down to just plain flat values in the compiled rock binary, which means that like there's no initialization. You can write, you know, whatever, like foo equals and then have a bunch of initialization logic. But that initialization happens at compile time rather than at runtime, just using your ordinary plain rock code as long as they're all pure functions.

1:04:19And so that's a, it's a concrete example of a way that the rock compiler itself is using purity for benefits, but also like pure functions just have all these like really nice properties, such as if you're calling a pure function and you're like, oh, I want to cache this thing because it's kind of expensive. It's like, no problem. You just like use the arguments as the cache key and like it's definitely going to work out. all right so there's yeah a bunch of stuff like that and like you know with concurrency like you can run pure functions and like concurrently and there's no problem a lot of stuff like that that's awesome so in a world where i'm doing operator overloading as you described earlier and i'm overloading the plus pure function i can't go shoving some effectual stuff in there i can't call file.read or file.write inside of there could i uh so great question uh so i guess the short answer is it depends.

1:05:09So first of all, because of the naming convention, if you tried to name it plus without the exclamation point and it was effectful, you would get a compiler warning because it's like, hey, you're supposed to put an exclamation point there. And then if you add the exclamation point, then the sugar is not going to work anymore. Right. So you could. So compiler warning is the level of enforcement. Like I could still get away with it, but the compiler is going to tell me, hey, this is a bad idea. Ah, OK. So that is yes, you're right. But also we do take it a step further, which is that. So one of the things that's certainly true is that oftentimes even if it's not something i want to ship to production i do like want to use like io in the middle of some pure function just for debugging purposes like for example i'm like i'm really lost in the middle of this thing i just want to write to a file like what's happening right now so i can debug it so we also make it so that that is a compiler warning um i should give the caveat that uh that doesn't work for the constants use case like when you're doing in the middle of a constant like that's happening at compile time so then we actually just like don't know what io is um because that's a platform thing so that's not available so that is like a hard warning i'm sorry a hard error but in general though this is actually part of rock's design philosophy i've been calling it uh inform but don't block and what i mean by that is basically like we try to make everything to the extent possible like non-blocking in terms of like compilation problems so we will give you a warning and also like we are kind of hardcore about warnings in that if there are any warnings when you build the compiler exits with a non-zero error code so that'll like fail your ci if there's any warnings so like warnings are taken seriously it's not like ah it's warnings don't worry about it it's like no like you need to fix all your warnings having said that um it's also true that like for example if you have a compile error at build time one of my pet peeves about compiled languages in general is that they will pretty much all with one exception haskell has a flag where you can kind of turn off part of this.

1:06:58It's like, if I have anything wrong with any part of my entire code base, I can't run any of my tests until I fix every single one of those. That always really bugged me because when I spent a lot of my career in working in dynamic languages, it's like, you could always run any test you want. And that really unlocked all these really nice workflows where I could be like, oh, I'm going to like try out this thing and experiment with it. And if I like how it's going, then I'll commit to continuing further with it. But oftentimes I'd try it out. And even though I knew there was a bunch of broken stuff around it, just by being able to try it out or like write some tests around it led me to realize oh you know what i actually want to go in a different direction and i'm really glad that i didn't over commit to this and have to fix absolutely everything and i really want to preserve that in rock so what we do is basically like we as much as possible we'll say like hey i'm going to tell you about this error if you actually run this code and we get to this code path and runtime it's going to crash because it's like we can't like in some cases it's like there's there's nothing we can do about like a naming error if you like reference a variable that doesn't exist it's like look i'll tell you about it at compile time and if you run the code as long as you never hit that variable like we can run the rest of your program no problem but if you get there we're gonna have to crash because it's like we can't proceed we don't know what variable you're talking about yeah but the idea is like inform but don't block like always tell you like about all the problems we know about at compile time give warnings give errors but don't block you let you run the program anyway let you run your tests anyway because oftentimes that's just the better workflow.

1:08:21So this is another area where I roll that into developer experience of just giving you the flexibility of working in different ways depending on what you're trying to do. On the topic of going to production, what does the deployment or the shipping, the sharing, the distribution story look like? Yeah. By default, very similar to Go in that it just spits out a compiled binary that you can just run on a machine. We also do cross-compilation. So this is something that a number of languages have. So basically like you can just say like rock build and then you can say dash dash target equals like, you know, X64 Linux.

1:08:55And even if you're on a Mac, it'll spit out a binary that you can just go hand off to X64 Linux. In practice, I guess that means that like, you don't need to have like a Windows CI and a Mac CI and a Linux CI. You can just have one CI of whatever you want and it can build for Mac and Windows and Linux and all those things. So you don't, nobody needs to have the rock compiler on their machine to run something that rock built. separately you can also uh build to like a dynamically linked library so this would be like if you want to use rock for like um like plugins like editor extensions or something like that anything that can load like a c based plugin or something like that um that includes like programming languages i had a actually you can see this in the repo you can try this out ruby actually um will let you import uh compiled like c modules uh just like straight up so you can actually like if you go to the um on github uh like we have this in the examples directory you can like basically like compile rock to a dynamically linked library that just like says like hello world or whatever um load up irb and just like import that module and it's like hello from rock you know just like straight up no like no fanciness needed and then of course uh the third way is web assembly like you can compile rock directly to compiled uh web assembly binaries sounds almost too good to be true what are the downsides richard what are the downsides oh sure um i mean well an obvious major downside today is that like the current compiler although it works so first of all the static dispatch stuff doesn't exist in the current compiler that's one of the reasons for the rewrite is that we hadn't figured that design out yet um so what you get today is like not as cool as some of the stuff we talked about earlier second there are also like like i mentioned with the um it's called lambda set specialization but the the thing with the like unboxed closures um there are like known bugs with that that are blocking certain like people tried to implement certain really cool projects in rock and they got stuck because although if you're doing simple stuff like or like you know applications they don't come up but as soon as you start trying to do really fancy platforms that'll unlock a bunch of other things they got stuck on these lambda set bugs that were like oh in order to fix that we gotta you know do a big rewrite so big rewrite yeah those those limitations definitely big downsides but let's let's pretend that we've solved all those we have the new compiler it's 2026 and like heaven of code exactly we're here we've arrived so now i would say so these are downsides that are sort of like downsides we accept as like long-term downsides um number one i'll just get this out of the way first it's different it's like you can't be much better if you're not going to be much different so like there's going to be a learning curve it looks pretty familiar i think from a lot of you know a lot of people who are used to mainstream programming languages will look at the code and be like cool i can like follow what's you know going on but there are going to be some semantic differences like for example since we don't have a first class concept of mutation there is no like array.push, you know, it's like, oh, there's, it's always going to be based on append and there are implications to that where like code gets structured a little bit differently, I would say in a nicer way.

1:11:40Um, but there is kind of like a, you know, a ramp up there. Another thing is that again, because we don't have a first class concept of mutation, and this is very much because like the language design philosophy is like simple language, small set of primitive, simple type system, simple, simple, simple, like be simple but powerful um and and very ergonomic uh there are some algorithms which like actually quicksort the reason i picked quicksort is because it's like if you try to write that in a purely functional style um we didn't have for loops back then the new compiler is going to have for loops um but in a very limited way where they don't affect purity and stuff like that or can be used without purity uh that's actually a controversial thing in like functional programming circles but if you're not like into functional programming it's like yeah for loops sure sometimes i want a for loop but if you're like imagine haskell having a for loop right it's like inconceivable well i do work in elixir so i do know uh functional yet for loops right there oh that's funny oh so so by coincidence as we're recording this the most recent episode of so i have a podcast called software and scripted um we do like a lot of technical deep dives and stuff i just had on jose valim as the most recent guest and literally we're talking about for loops and he was talking about like the challenges of trying to get for loops into elixir which i guess he's been trying to do, but they never have been able to get a design that quite checks all the boxes.

1:12:53It was a fun conversation. But in some languages, yeah, what did he say? It was something like, he was like, some people have accused me of being like a sleeper agent, you know, because I'm trying to get for loops into Elixir. But this is actually like, and you know, that's without going on another tangent about language design and for loops. That is an example of something where I feel confident enough in my love for functional programming that I'm like, yeah, no, this is a good fit for this language to have for loops because sometimes that's the best way to write the thing is like, it's just like an imperative for loop is just the most straightforward, nicest code to read for that particular use case.

1:13:30I also bring that up as an example of a downside, like you were saying earlier, because there are just some things where it's like the nicest way to write it is to actually have a first class concept of mutation. And the fact that we are as a simplification, not including that in the language means that you might have to write it in a way that is not quite as nice as if you had that tool in your toolbox. Now, of course, having that tool in your toolbox opens a huge can of worms in terms of like, now your functions don't have the same guarantees. You might have to do more defensive cloning, yada, yada.

1:13:55But it is a trade-off that I'm willing to acknowledge, right? In the spirit of that FAQ of like, no, we think this is worth it. It's the right way to go. And you can't have simplicity without subtracting some things. So there are some things that we've intentionally subtracted. And that means you have a simpler language, but it means that some things I acknowledge are going to be less ergonomic than if we had, you know, more tools for them. I also like this, this kind of reminded me that like the topic of for loops and whatnot reminded me of another thing that is, I guess, unusual, makes rock unusual compared to other functional languages, which is that we do have that concept of like first class effects where like, you know, you have the exclamation point and not.

1:14:37And implication of that is that you do end up with a form of like, what color is your function? So like, if you have a deeply tested call of pure functions and you're like, oh, I actually want to do like file IO in this, you know, the leaf node here, that's got this huge stack of calls above it. Well, guess what? You have to convert all those two effectual functions. Now I would argue that unlike the, like, what color is your function? This is not like, it's just, it's just a fact about pure functions. Like, yeah, if you do that, it's not a pure function anymore. And like, this is just rocks type system telling you about that.

1:15:05But again, like if you're in an imperative language that doesn't track those things it doesn't have that in there you don't have that downside you can just like introduce io at any point and not have to convert anything of course then that comes with the trade-off of like do you know whether whether your functions are pure or not um so those would come to mind as concrete examples i would also say um the fact that i mentioned earlier about the like scripting use case like we intentionally do not have like arbitrary cffi like only the platform gets to do low-level things the application just doesn't get to do anything period if you want you can design a platform that says like hey here's a way where you can like i expose as a function that's like, give me a string and I'll load a dynamic library off of that.

1:15:41And you can do stuff with that, but it has to be done through the platform. And that does kind of, you know, FFIs have downsides in terms of security and other things, but they also have upsides. And so the fact that Rock doesn't have one of those, that's another downside. So I could go on for a while about downsides of Rock, but... Yeah, but that would be against your best interest. So I'll stop you right there. What's the library story? Like how do I work with other people's code? Yeah. So, um, so right now it's very simple. Uh, we have plans to make it a little bit fancier, but while still preserving, um, the, the properties that I want to preserve.

1:16:15So the nicest thing about it, I would say is that right now, if you, so I mentioned like rock, we want to be good at scripting. One of the cool things about how rock can be nice for scripting is that if you want to have a single dot rock file and that's all you're distributing to people, you don't have to give them anything else, just one dot rock file and they can run it. That dot rock file can have dependencies in it. Uh, because there's no separate like package.json file like that. It's just like you literally put them in your ROC code at the top. You say like, I want this dependency and I want this dependency.

1:16:40They can all just be in one file if you want. The dependencies are based on a URL. And one of the cool things about this is that I don't know of any other language that's doing this actually. The URLs have to be in a specific format. Right now, the specific format is that basically at the end of the URL has to be a hash of the contents of what's behind that URL. So this is a security feature. So the basic idea here is like if I have this URL and it's like downloading this package and i'm like you know putting it on my system um what happens if that url gets compromised and like now somebody puts a malicious thing there i don't want to download that automatically anymore that's really bad for me so the fact that we have the hash baked in means if somebody does compromise that url the worst thing they can do is like take it down and like you know make it 404 or something they can't actually like you know give me something malicious because if i do it's going to fail the the you know the check that rock does when it after downloads of things.

1:17:31It's going to be like, oh, this doesn't match the hash that was in the URL. And so that's a really nice security feature. And of course, if they want to change the hash, well, now they have to change the URL. So the URL is going to 404. Really basic, really simple security measure. Once it's downloaded, it gets cached on your machine. Also, we don't have the equivalent of a node modules directory in your local folder. It's all just in a global immutable cache in your home directory, which means that, again, thinking about scripting as a use case, you can say, like here are my dependencies there's also no like npm install step it's just like the compiler just like when you do rock run and the name of a dot rock file it just like automatically downloads your dependencies into your home directory if they're not already there if they are there great we don't need to redownload them again um it also doesn't need to like contact a central package index for updates it's just like yeah we just they're either in the directory or there's the url um and then basically like when it runs it also doesn't need to do any like caching in your local home directory the design we have for caching is also going to be um in the in the home directory rather than the local directory so much like with you know zero dependency python for example if you run a script it's like it's not going to put any garbage in the directory it runs it's just going to do everything in like a cache directory and like the home directory um and then just run and that's it uh we also have a design for um version ranges which is actually a little bit based on how go does those with their like minimum version selection basic version of that is like in addition to the url having the hash we're also going to have a concept of like you can put a version number in the url and then the compiler will automatically select a version from those based on like uh you know like the what it finds across all the different urls you asked for and they can ask for you know versions of one another yada yada and yeah there's a whole design for that but we have not implemented that yet but uh the new compiler will have it yeah versioning was what i was going to ask you next so you uh you hit that one off once you set a hash in the url i'm thinking how do you actually deal with like what version you want.

1:19:20Yeah. Really simple answer there is that basically like the thing that we're taking from goes and they have this whole long blog post about the design of like minimum version selection. It's really interesting read. As I understand it, they kind of changed it a little bit from what they wrote there. But basic idea is this, is that each of your dependencies needs to say like, okay, I depend on at least this version of this file. And we treat different major versions as sort of basically different packages. Like they might as well have a different name because they're just like, yeah, if you have a different major version, they're not possibly compatible or they're potentially incompatible so we don't select them but if you have different minor versions that's fine what we will select is just like what is the lowest minor version that we can get away with while still satisfying everybody's constraints so if package a like i depend on package a and it says like oh i need i'm gonna use bug snag as an example that was like the error handling thing we used at my last web dev job um and you say okay great i have uh i a package a depends on bug snag version 1.2.3 and package b that i depend on depends on bug snag version 3.4.5 so no actually i need them to be the same major version so 1.2.4 let's say 1.2.3 to 1.2.4 so each of those urls has the hash in it i know exactly what 1.2.3 is and what 1.2.4 is and i have the hashes for both etc it's all just the same url based design that i described before what the compiler can then do is it can say, oh, well, I see that you have among all your dependencies, like in the 1.x.y range, like where they're all, you know, the major version number is one.

1:20:49The highest one that we need is 1.2.4. Great. We'll select that and use that for both of these two things. Like the one that needs 1.2.3 also gets 1.2.4. And that should be fine because they should be API compatible. We also want to do the thing that Elm does, which is where you basically have the compiler awareness of what major versions mean and you can just like tell people when they're publishing like hey this needs to be a major version bump because you actually like made a breaking change to your api compared to the old one this is something elm like hardcore enforces i'm not sure if we're going to be as hardcore about the enforcement uh just because of the like url based thing it's a little bit more complicated if you're a little bit more like distributed and less centralized in how you're getting dependencies but it is really cool that like in elm like if you try to publish a major breaking change where it's like yeah this actually is like api incompatible with the previous version i published elm is like nope you need to bump the major version number that's not optional here because like i can see that you made a breaking change i i looked at the diffs and the types um so we want to do the same thing at the very least in the like inform you so like we don't ever want it to be the case that someone publishes a new version and is surprised that it like doesn't build and the compiler is going to rely on that so it's like when it's selecting these versions it's assuming that 1.2.3 and 1.2.4 are at least api compatible and your code will still build even though obviously they might not be bug compatible maybe you were relying on a bug in 1.2.3 or something but that is kind of the the price we pay for like code sharing yeah 5 % how good is claude at writing rock code so we actually have something uh at rockland.org um in the docs section on the built-ins we have a little um it's like this is for llms basically And it's a little like markdown document that you can just like either copy paste in the LLM or just like put in your, you know, dot rules file or whatever.

1:22:36That's basically like, hey, here's what this language is all about. And it's just sort of like a little, yeah, it's a little primer for like a large language model. Does that work pretty well? Yeah. I mean, it's hard to say because there aren't really any like big rock code bases so far. But like definitely if you give it like enough examples like that, I've actually like even without using that thing, I've had it. I've had good experiences with being like I've opened a dot rock file and I'm like, hey, look at this thing. can you like write some new function like in that style? And yeah, I mean the funniest thing that I've seen it do though, is like sometimes because rock is like really not super represented as training set surprise when there's something that it has not seen any examples of, it'll just make something up.

1:23:15And quite often it will guess like something from like Elm or like Haskell or like some other functional language. Cause like, it's just like this feels kind of like a functional thing. So like maybe it's this and it'll just kind of throw it in there. And then usually when that happens, I kind of chuckle and I'm like, no, no, it's actually this and Brock. so it's obviously not going to be as good as like you know languages that are like really heavily in this trading set i actually view that as kind of like similar to the ecosystem thing where like historically whenever you make a new programming language people would always say like well no one will ever use this because it doesn't have the ecosystem of you know gigantically popular language you know a it's like yeah okay but new languages do come up and exist and like you know they weren't there before and then like you like rust for example people would have said like oh nobody to use Rust because it doesn't have the C++ ecosystem.

1:23:59It's like, yeah, but then that happens over time. And it's the same thing with large language models. It's like, no one will use this because it's not in the training set. It's like, okay, I know. That's the downside at first. When you're an early adopter, you're going to have to deal with it. Occasionally, it hallucinates some Haskell in there. But in the same way that the ecosystem is small at first, but over time, it grows. And then that stops being a downside once you get a certain amount of adoption. And the tradeoff is, as an early adopter, you get to be a lot more of a voice and more more prominent contributor to the community, you know, because you got in early when it was, you know, not the most polished.

1:24:32Right. I was speaking with Mads Torgerson recently. He's the lead designer on C Sharp. And we were kind of lamenting that it's probably never been harder to break out, though, as a new programming language than it is now because of these tools and the selection bias, kind of like the rich stay richer effect of an LLM either choosing a tool or a language because you don't care if you're vibing it or just not being as ergonomical or as useful to you. And so maybe you just pick Python because it knows it better. Whereas you're kind of interested in rock, but you're like, yeah, I'm not going to get much help here.

1:25:08I feel like it's going to be harder and harder to actually break out in the next few years. What do you think? I thought that my opinion on that has actually completely 180 since I actually tried it. So the experience that I had was like, intuitively that makes sense. Right. But so the experience I had is like we as i mentioned earlier we did recently well recently as like several months ago decide to rewrite the compiler in zig i had done some zig but i i really not used it like super in anger for like a like a big code base before so there was a lot of like learning that i had to do what i found was that a zig even though it's like a pretty niche language today is plenty well represented in like claude's data set that like you can just kind of jam on it it doesn't really hallucinate you know i i've not seen any problems with like claude for um like having problems with that.

1:25:56But what's really great about it is that I know from plenty of years of experience of trying out new languages that there is always a ramp up period when you're trying a new language that's always been a really significant downside, which is like, I don't know what character to type next. I know what I want it to do, but I don't know how to say that in this language. And when I hit that roadblock, I always have to go find documentation, but maybe there's like, it's like a weird symbol. And so I don't, I can't like Google for it effectively. And I'm like oh what part of the tutorial is going to talk about this thing or like i know conceptually what i want to do but i don't exactly know even like what to search for i'm just like here's i have this like thing that i want to do i know the language could do it i just don't know how to do it that problem is gone in the large language model world because i just tell the large language model hey i want to do this thing i don't know how to do it in zig and it's like here you go i just wrote it for you in zig and i look at it and i'm like i can guess what this code does like it's it looks like it does what i want and if i want i can now now i know exactly what this code is I can go look up the docs if I'm concerned about that, but it feels so much less choppy and like stumbling around in the darky to like get ramped up on a language compared to the old days where like we didn't have access to these tools.

1:27:02Like the new user experience, if it's, you know, sufficiently represented in the dataset, but even if it's not, like I said, you can help the model out with this thing. It feels so much easier to get into it. And the other big downside that I mentioned, like the historical thing that everyone always talked about was ecosystem. You know what tool is really, really good at taking an existing library and porting it to a new language and like taking out like 95 % of the time consuming drudgery of that. So you could just kind of like review it like, you know, large language models. Like if you want to get like your favorite, you know, hashing function in rock, for example, like that's something that like porting that from, you know, whatever language a to like to rock by hand, really, really painstaking and error prone to like annoying.

1:27:44now I can just be like, hey, okay, Claude, you know, port over all the tests first. I want to make sure all the tests are in place and I'll hand review the tests to make sure like, okay, these are doing the same things as the other tests in that repo. Great. All right. Now I'll start porting over the implementation. Oh, tests failed. Great. Go fix them. Like here's, you have all the source code on both sides, the amount of time that it should take to bootstrap an ecosystem and like get it to a point where it's not going to be as big as, you know, like big longstanding ecosystems, but getting it to a point where ecosystem is not really a blocker for people and they can kind of like get into the language and like reach for hashing or whatever, you know, bug snag off the shelf, I think should be a lot faster.

1:28:21So putting those things together, I'm like, I actually think it might be easier than ever for like a new language to break out, especially because if you're like, I'm in this big code base that I have and I want to start using a new language, it's like easier than ever to start writing code in that language, like from a, you know, with the help of a large language model. And if I'm just going to be mostly writing in English anyway to synthesize the new code like why don't i have it synthesize code that's like easier to read and to review and you know that like has nicer properties to be like oh this is a pure function so i don't have to go like worry about what the implications are like that's there's a lot of advantages to reviewing code that you get from switching languages but if you're just telling the model what code to write in the first place like you know why would i tell it to generate python when i could tell it to generate rock you know gotcha that's interesting yeah i can definitely see that if i was going to pick up rock tomorrow and i didn't have an actual use case yeah or care in the world i just want to write i just want to learn and write some rock code i just want the best rock experience what would i build where rock really shines and i could be like oh okay i get this what kind of a thing would i build that's a great question i mean i don't um i don't usually think about it in those terms so i would usually turn it around and say like what do you want to build i would say i mean the three things that i think rock is currently the best at uh would be like command line apps uh like server-side web apps and there is a platform for doing like native graphical applications um if you want something that's like a little bit more fun there's uh this thing called wasm 4 which is like like really like lo-fi like retro gaming kind of stuff in the browser so people have made like um like a maze thing and like a like rocky bird which is like flappy bird but uh so if you want to like do some game stuff I would recommend that one.

1:30:10We don't really have a, there is no like serious game dev rock platform yet. Nobody's built it, but you know, if someone wants to hit me up, uh, there also, there have been some like doing rock in the browser for like, you know, web dev front end stuff. Like you certainly can do that, but there isn't anything like really mature. So I wouldn't recommend that. I would say like servers and CLIs are the two that are really like the most robust and like, well, well used. Uh, so I would pick one of those two if that's something that you, uh, want to try rock out with. Cool. and where does the rock community hang out where are they Zulip uh so on the website rocklang.org yeah we uh we have a Zulip instance um it's uh it's definitely the place to go if you want to chat about rock things very cool we are Zulip users ourselves and it's nice to always come across other Zulip fans because we are somewhat few it's somewhat far between but relatively happy oh yeah cool Richard well this has been awesome I'm excited about rock I generally do leave these conversations excited about what I'm talking about because that's just the way it works.

1:31:10That being said, there's a lot to be attracted to here and I do want to give it a shot. Maybe I'll build a little app server or something and see how it goes. Should I wait till advent of code? I mean, is it worth waiting so I can get that nice syntax sugar or should I just dive right in? Up to you. I mean, I think since this stuff's going to change between now and then, I would probably default to saying wait till advent of code. But hey, I mean, like nothing stopping you from trying out uh you know like what it is right now and uh and certainly like the current compiler is way more feature complete um i would also note that like uh you know if a common thing that people talk about like being interested in when it comes to like developing a language is like hey like how do i get started on building a real thing um i don't know if you personally are interested in that because obviously you're interested in languages i don't know if you're interested in implementing languages but if anyone you know listening is we also have a pretty a lot of experience in like ramping up new contributors uh to the language to like getting involved in like hey i want to like actually like make something in the time checker happen right um there's like actual opportunities to do that right now whereas that won't be true once we get to like 0.1 that it'll be a lot more i don't know the number of like beginner friendly projects taper off okay so if i want to do that is zulip the answer there or is there is a github yeah zulip yeah we have like a beginner's channel it's just like you and there's even like an introductions in there and usually people will just like hop into introductions like hi i'm you know your name here and then like here's what i'm interested in you know i'm excited about this or that and uh we can uh chat from there super cool the website rock-lang.org what's the website for your podcast oh uh software unscripted.com it's also on like all the different podcast places wherever you get your podcasts yeah and we're on youtube now too oh cool well richard it's always a pleasure it's nice to catch up with you it's been i think a year or two we were together at the last strange loop.

1:33:03I remember that. Yeah. In person. Yeah. Strange loop. So great. Has there was rumors of like things that were going to arise and not replace strange loop, but kind of like carry on the spirit. Are there any events that have done that or that you know about? No, no, I haven't. I remember hearing at that conference, there were, there were some rumblings about it, but I, I don't think anyone actually did it. Yeah, I agree. That's, that's what, that's what I got going on too. I thought maybe you might know more than I do being even more of a language nerd than I am. I just think they're interested.

1:33:33You build these things. So that's a shame. Somebody needs to go out there and do something, at least in the spirit of Strangeloop, because it was such a great time. It really was. Yeah. Oh, well, c 'est la vie. Some of the best things in life, you know, they have a beginning, a middle, and an end. And we just look back at them fondly, and there's nothing wrong with that, I guess. Totally. Well, thanks again, Richard. Awesome time. Looking forward to rock. Check it out, listeners. Check the show notes for all the things and we'll talk to you on the next one. See you. Awesome. Looking forward to it.

1:34:05Thanks.

1:34:09Have you heard that we're doing a live show on stage at the end of July? That's Saturday, July 26th at the Oriental Theater in Denver, Colorado. Be exact. Why don't you join us for the entire weekend if you want? We'll be meeting up at a local pub Friday night, recording live on stage on Saturday morning. hiking Red Rocks, Saturday afternoon, and who knows what else. It's going to be a lot of fun. Ab and I will be there. Gerhard will be there. Even Breakmaster Cylinder will be there. Get all the details at changelog.com slash live. Thanks again to our partners at fly.io and to our sponsors of this episode.

1:34:48Retool. Check out agents at retool.com slash agents. Well, Apple's WWDC keynote came and went, but what does it all mean? Justin Searles and myself Wade our way through all the nitpicky details On Change Login Friends On Friday Talk to you then

1:35:40Game on.