WEBVTT 00:00:01.610 --> 00:00:05.710 Here's another episode of Rust in Production, a podcast about companies who 00:00:05.710 --> 00:00:07.690 use Rust to shape the future of infrastructure. 00:00:08.170 --> 00:00:12.570 My name is Matthias Endler from corrode, and today we talk to Richard Feldman 00:00:12.570 --> 00:00:16.630 from ROC about their reasons for migrating from Rust to Zig. 00:00:19.010 --> 00:00:22.170 Richard, thanks so much for taking the time for the interview. 00:00:22.510 --> 00:00:26.950 Can you say a few words about yourself and about ROC, the programming language you're working on? 00:00:27.370 --> 00:00:31.030 Yeah, sure. So I'm Richard. So my day job is I work at Zed Industries, 00:00:31.170 --> 00:00:33.450 making the Zed code editor, which is all written in Rust. 00:00:33.710 --> 00:00:36.630 So mostly what I spend my time on is writing Rust. On the side, 00:00:36.770 --> 00:00:39.530 I have been developing for the past several years, the Roc programming language, 00:00:39.730 --> 00:00:42.010 which I created, but I work on with a number of other people. 00:00:43.270 --> 00:00:47.690 Originally, Roc's compiler was written in Rust completely. And now it's being 00:00:47.690 --> 00:00:50.130 rewritten in Zig, which is what I assume we're going to talk about. 00:00:51.530 --> 00:00:55.690 Precisely. Yeah, it's perfect. we had said in 00:00:55.690 --> 00:00:58.590 a previous episode as well if you want to check that out we 00:00:58.590 --> 00:01:01.530 will link it in the show notes that was an amazing episode as 00:01:01.530 --> 00:01:04.650 well and also for this one i have 00:01:04.650 --> 00:01:09.210 really high hopes because your name was mentioned a couple times by a couple 00:01:09.210 --> 00:01:14.250 of our listeners because you wrote an article or maybe you published a post 00:01:14.250 --> 00:01:19.410 let's say about your migration from rust to Zig but before we get into that 00:01:19.410 --> 00:01:24.490 what is Roc what makes it special why did you start that project. 00:01:25.240 --> 00:01:28.100 Yeah, so Roc's tagline is fast, friendly, functional. 00:01:28.560 --> 00:01:32.340 And basically, it's a functional programming language. The goal is to be really, really fast. 00:01:32.540 --> 00:01:36.540 We want it to be the fastest garbage collected language. That's sort of the goalpost that we set. 00:01:36.700 --> 00:01:40.940 So I would say that Go right now, as far as I'm aware, is the fastest garbage collected language. 00:01:41.120 --> 00:01:45.640 And we want to be faster than Go, not as fast as Rust or C++ or Zig or any of 00:01:45.640 --> 00:01:48.720 those, because we want to be completely memory safe, guaranteed. 00:01:48.720 --> 00:01:51.600 Speed and basically the the goal is to 00:01:51.600 --> 00:01:54.400 be competing with languages like go or maybe like 00:01:54.400 --> 00:01:57.480 you know ocamel also has a good reputation for speed while being 00:01:57.480 --> 00:02:01.140 a functional programming language as opposed to like go being very imperative 00:02:01.140 --> 00:02:05.740 so yeah that's that's the goal in terms of speed in terms of friendliness it's 00:02:05.740 --> 00:02:10.080 like have really simple apis very very heavily inspired by elm Roc is sort 00:02:10.080 --> 00:02:14.160 of an outgrowth of my really positive experiences with elm but elm is targeted 00:02:14.160 --> 00:02:17.280 at compiling to JavaScript and front-end web development, 00:02:17.320 --> 00:02:21.440 whereas Roc compiles to machine code or to WebAssembly and is sort of trying 00:02:21.440 --> 00:02:25.100 to address all of these use cases that are not front-end web development. 00:02:25.660 --> 00:02:29.640 Also, Roc's design has evolved quite a bit from Elm's. Now it's a much different 00:02:29.640 --> 00:02:32.080 language. When it started out, it was very similar to Elm. 00:02:32.360 --> 00:02:36.640 Now it's a lot less similar, but I think the essence of that sort of ethos of 00:02:36.640 --> 00:02:41.180 simplicity and really nice APIs and really friendly compiler error messages and things like that. 00:02:41.460 --> 00:02:44.620 Actually, Elm's error messages inspired Rust, even though So I think Rust is 00:02:44.620 --> 00:02:46.340 now more famous for compiler errors. 00:02:48.100 --> 00:02:50.600 So all of that is sort of what we're going for with Roc. 00:02:51.220 --> 00:02:54.200 And take us back to the time when you started the project. 00:02:54.780 --> 00:02:59.320 What was the ecosystem like? What were some of the other languages that you 00:02:59.320 --> 00:03:01.960 got inspired by when you started with Roc? 00:03:02.160 --> 00:03:06.600 And also, what was that initial spark that told you, hey, I need to do this, 00:03:06.720 --> 00:03:08.700 and now is the best time for it? 00:03:09.900 --> 00:03:14.420 Really, the inspiration for it came from an experience I had. 00:03:14.600 --> 00:03:17.760 This is back when I was working at NoRedInk. We had this huge Elm front end, 00:03:17.900 --> 00:03:22.420 and we had Ruby on Rails for the back end. And Rails had been at the back end 00:03:22.420 --> 00:03:24.060 for long before we started using Elm. 00:03:24.220 --> 00:03:27.920 And we were trying to move the back end to something more functional. 00:03:28.460 --> 00:03:32.420 And kind of what we discovered was that there was just really this missing piece 00:03:32.420 --> 00:03:35.420 in the ecosystem, or at least that was my perception of it. 00:03:35.560 --> 00:03:38.960 We ended up going with Haskell and trying to use Haskell in kind of an Elm-like way. 00:03:39.260 --> 00:03:44.320 But my feeling was what we really want is a functional language that's statically 00:03:44.320 --> 00:03:49.960 type checked with type inference built around purity. So OCaml is a functional 00:03:49.960 --> 00:03:53.060 language, but it's really not like pure functions everywhere. 00:03:53.300 --> 00:03:57.300 It's sort of like pure functions are encouraged, but they're not really first class in OCaml. 00:03:57.830 --> 00:04:03.430 Same thing with F sharp. And basically what we ended up concluding was that it just doesn't exist. 00:04:03.570 --> 00:04:06.390 Like there is no Elm equivalent outside of the browser. 00:04:07.190 --> 00:04:09.930 And that was kind of the spark for me to go and do it. 00:04:09.990 --> 00:04:15.850 As far as what languages inspired it, really it was Elm plus like maybe little 00:04:15.850 --> 00:04:18.770 bits and pieces of other languages, but it's very primarily like, 00:04:19.050 --> 00:04:22.850 okay, how do I take this great experience we've had with Elm and translate it 00:04:22.850 --> 00:04:24.870 to other domains besides just the browser? 00:04:25.030 --> 00:04:28.690 And I didn't want to just do servers. The kind of the idea was i'd be using 00:04:28.690 --> 00:04:32.090 this phrase the long tail of domains like basically there's lots of different 00:04:32.090 --> 00:04:36.190 use cases out there it's not just servers there's command line apps there's native graphical apps. 00:04:37.270 --> 00:04:40.930 There's microcontrollers robotics you know there's this very long tail of different 00:04:40.930 --> 00:04:44.290 things you can do with programming and i wanted to see could we bring an elm 00:04:44.290 --> 00:04:48.310 like experience to all those different domains in terms of being a very simple 00:04:48.310 --> 00:04:50.970 functional experience yeah. 00:04:50.970 --> 00:04:55.370 And i could see a few ways how this could go because the Rust compiler is not, 00:04:55.530 --> 00:04:59.530 or the first version of it wasn't written in Rust because Rust didn't exist, obviously. 00:04:59.690 --> 00:05:02.190 It was written on OCaml as well. And, 00:05:02.810 --> 00:05:07.150 Then you have Elm, which might be another way to implement a new language on 00:05:07.150 --> 00:05:12.050 top of, or maybe there's a language that I don't know of that you could use. 00:05:12.190 --> 00:05:15.750 But why did you choose Rust and which alternatives did you consider? 00:05:16.490 --> 00:05:20.450 Yeah, also a great question. So basically, the reason I chose Rust was that 00:05:20.450 --> 00:05:23.390 I wanted the compiler to be as fast as possible. 00:05:24.070 --> 00:05:28.550 And I was, to be totally honest, scared of trying to do it in a memory unsafe 00:05:28.550 --> 00:05:33.190 language based on past experiences I'd had with segmentation faults that I really 00:05:33.190 --> 00:05:34.630 struggled to debug and stuff like that. 00:05:35.170 --> 00:05:39.790 When I was very young, like middle school era, I got into C++ because I wanted to do game dev. 00:05:40.070 --> 00:05:43.230 And I have some scars from trying 00:05:43.230 --> 00:05:46.690 to do that and bumbling around and just making a huge mess for myself. 00:05:46.850 --> 00:05:50.990 And the pitch of Rust of being, hey, you can have this really, 00:05:51.070 --> 00:05:54.570 really high performance ceiling. In other words, there's no mandatory garbage collector. 00:05:54.810 --> 00:05:58.070 There's no built-in boxing of things you 00:05:58.070 --> 00:06:01.310 can be as fast as a c or c plus plus program but 00:06:01.310 --> 00:06:04.150 you're going to have memory safety you don't have to worry about seg 00:06:04.150 --> 00:06:06.990 faults and all these things that that you know i had these bad experiences with 00:06:06.990 --> 00:06:10.910 in the past that was the pitch that sort of sold me because my thinking was 00:06:10.910 --> 00:06:14.610 well if i do the compiler in oCaml or Haskell or something like that yeah that's 00:06:14.610 --> 00:06:17.650 going to be a more familiar experience to me but at some point i'm going to 00:06:17.650 --> 00:06:22.470 reach this point where i'm like i want it to go faster and i can't because i'm 00:06:22.470 --> 00:06:24.550 limited by the performance ceiling of this language. 00:06:25.270 --> 00:06:27.870 I don't want that and then at that point i'm like what am i going to do 00:06:27.870 --> 00:06:30.850 i'm going to say oh now i rewrite it in rust you know this is something that's happening 00:06:30.850 --> 00:06:34.270 in the javascript ecosystem a lot is that a lot of projects started off 00:06:34.270 --> 00:06:37.170 being written in javascript because that's what was familiar to people and then 00:06:37.170 --> 00:06:41.310 they realized past a certain point that a compiler is one of those use cases 00:06:41.310 --> 00:06:46.210 where just more performance is better it's not like you get down to this point 00:06:46.210 --> 00:06:49.470 you know in a lot of graphical applications it's kind of like well as long as 00:06:49.470 --> 00:06:51.790 you're not dropping frames as long as you're under the you know however many 00:06:51.790 --> 00:06:53.930 milliseconds you have within each frame Thank you. 00:06:54.420 --> 00:06:57.640 Humans can't perceive a difference it's like it's fast enough and 00:06:57.640 --> 00:07:00.420 if you make it faster nobody notices compilers are 00:07:00.420 --> 00:07:03.320 not like that faster is pretty much always better it's 00:07:03.320 --> 00:07:05.980 a it's just a big part of the ux is you know 00:07:05.980 --> 00:07:09.380 how long are you waiting for rebuilds and stuff like that and so 00:07:09.380 --> 00:07:12.200 my feeling was especially actually this this came 00:07:12.200 --> 00:07:15.000 up in elm when we were using element NoRedInk at some point we 00:07:15.000 --> 00:07:17.820 became the largest elm code base we had a couple hundred thousand lines 00:07:17.820 --> 00:07:22.020 i don't remember exactly how big it was at the time but elm 0.18 00:07:22.020 --> 00:07:24.900 we were really feeling the pain of compile 00:07:24.900 --> 00:07:28.080 times it's like we'd had a really positive experience and it was becoming a 00:07:28.080 --> 00:07:31.240 very negative experience just because we were waiting so long for rebuilds 00:07:31.240 --> 00:07:34.140 and then when elm 0.19 came out evan had rewritten 00:07:34.140 --> 00:07:37.600 a huge amount of the elm compiler which was written in haskell for 00:07:37.600 --> 00:07:40.860 performance and it took him a long time it's months and 00:07:40.860 --> 00:07:43.740 months and months but when it came out it was just this amazing 00:07:43.740 --> 00:07:46.720 breath of fresh air all of our builds were fast again like they used to be when 00:07:46.720 --> 00:07:50.200 our when our code base was small and that was a really important lesson for 00:07:50.200 --> 00:07:54.220 me was yeah take the stuff seriously like compile times are a really big deal 00:07:54.220 --> 00:07:58.400 and if you want to build a language that has a good end user experience you 00:07:58.400 --> 00:08:02.040 know fast friendly functional part of that friendliness and user friendliness. 00:08:02.820 --> 00:08:07.460 Is committing to having a compiler that is really really really fast and that's 00:08:07.460 --> 00:08:10.340 something that i've been completely unwilling to compromise on since the beginning 00:08:10.340 --> 00:08:12.540 of the project the compiler's always It's got to be really fast. 00:08:13.260 --> 00:08:17.420 Yeah. And that was in 2019. Correct me if I'm wrong here. 00:08:17.860 --> 00:08:22.660 What was your level of Rust experience when you started with implementing Roc? 00:08:22.780 --> 00:08:24.560 Was it your first big Rust project? 00:08:25.220 --> 00:08:31.440 It was my first big Rust project. So previously in 2017, I had dabbled in Rust, I would say. 00:08:31.640 --> 00:08:34.100 I'd written the Elm test runner originally in Node.js. 00:08:34.640 --> 00:08:38.320 And it was honestly out of frustration with the Node.js ecosystem that I was 00:08:38.320 --> 00:08:40.720 like, I just want to try something else. Why don't I try Rust? 00:08:41.100 --> 00:08:44.560 I never actually shipped anything out of that project It was like I just started 00:08:44.560 --> 00:08:48.260 rewriting it in Rust So I kind of got a feel for it And the experience that 00:08:48.260 --> 00:08:51.220 I had initially with Rust Was positive enough that I was like Yeah, this... 00:08:51.890 --> 00:08:54.650 This seems like something I'm willing to commit to for this compiler, 00:08:54.790 --> 00:08:57.550 even though I know this is going to be a very, very long, you know, 00:08:57.830 --> 00:09:01.350 project that I'm going to spend way more time on than this little sort of side 00:09:01.350 --> 00:09:03.290 project thing that was just kind of for fun. 00:09:03.290 --> 00:09:07.330 And I mean, my feeling going into this was that this is a language that I'm 00:09:07.330 --> 00:09:10.790 planning on putting multiple decades of my life into. 00:09:11.110 --> 00:09:16.490 And so committing to Rust with just that minimal level of experience was a bit 00:09:16.490 --> 00:09:20.770 of a leaf of faith in the sense that I didn't have enough Rust experience to 00:09:20.770 --> 00:09:23.070 know that I was going to like it that much long term. 00:09:23.430 --> 00:09:26.750 But at the same time, I had enough experience. 00:09:26.930 --> 00:09:30.170 It wasn't zero. It wasn't like I was sitting down and writing Hello World and Rust. 00:09:30.290 --> 00:09:32.050 And then I was like, that's what this compiler is going to be in. 00:09:32.050 --> 00:09:36.930 So I would say it was an informed decision, but my Rust experience at that point was pretty minimal. 00:09:37.850 --> 00:09:41.990 When you think in decades, how does it shape the decision-making process? 00:09:42.790 --> 00:09:49.390 I would say the main thing is that it gives me the comfort to make long-term investments. 00:09:50.310 --> 00:09:54.370 So a lot of projects that I've worked on in my career have been for startups. 00:09:54.710 --> 00:09:58.690 And startups are often like, yep, in 18 months, we're going to be out of money 00:09:58.690 --> 00:10:02.950 and disappeared off the face of the planet. So it's really important that we 00:10:02.950 --> 00:10:04.290 survive the next 18 months. 00:10:04.650 --> 00:10:08.230 And so making a long-term investment has to be balanced against, 00:10:08.490 --> 00:10:12.270 okay, if we make this long-term investment, is that investment going to cause 00:10:12.270 --> 00:10:16.010 us to not exist long enough to reap the benefits of the long-term investment? 00:10:16.290 --> 00:10:17.870 And there's always that constant tension. 00:10:18.510 --> 00:10:22.430 With this project, my feeling was the opposite. It's like, I'm very comfortable 00:10:22.430 --> 00:10:23.630 making long-term investments. 00:10:23.810 --> 00:10:26.830 The main thing I was actually thinking about was, and this is again, 00:10:27.010 --> 00:10:31.790 shaped by my early experiences with Elm and participating in having the good 00:10:31.790 --> 00:10:36.150 fortune to live in the same city as Evan Czaplicki who created Elm and being 00:10:36.150 --> 00:10:37.330 able to talk to him about these things. 00:10:37.550 --> 00:10:42.710 But basically understanding that if I'm going to be making a long-term investment in the language... 00:10:43.930 --> 00:10:48.050 It's important that I also communicate that clearly and set expectations clearly 00:10:48.050 --> 00:10:49.470 to people who are using the language. 00:10:49.910 --> 00:10:52.490 So from the very beginning, I've tried really hard to communicate, 00:10:52.730 --> 00:10:56.330 hey, things are not set in stone here. We're going to be making breaking changes 00:10:56.330 --> 00:10:57.290 to this language, et cetera. 00:10:57.570 --> 00:11:00.650 The strongest way that I've done that is we intentionally, even though, 00:11:00.990 --> 00:11:04.850 like you said, the first line of code was 2019. I actually started designing it in 2018. 00:11:05.610 --> 00:11:08.610 But ever since then, we still do not have a numbered release. 00:11:08.790 --> 00:11:12.230 We're planning on having our first numbered release in 2026 like 00:11:12.230 --> 00:11:14.970 0.1.0 but the whole reason we've been doing that 00:11:14.970 --> 00:11:18.630 is just to communicate you have to build from nightly expect things 00:11:18.630 --> 00:11:21.470 to break despite this we still do actually have one 00:11:21.470 --> 00:11:26.210 person who's been consistently using Roc in production at his job but that's 00:11:26.210 --> 00:11:30.070 to me an appropriate level of cautiousness where like we only have one person 00:11:30.070 --> 00:11:33.030 doing it even though lots of people have done Roc for hobby projects and stuff 00:11:33.030 --> 00:11:37.630 because we are making big changes and so those are all things that i see as 00:11:37.630 --> 00:11:40.090 long-term investments i think if i were thinking more short term, 00:11:40.270 --> 00:11:42.570 I might be like, okay, no, we already need to be backwards compatible. 00:11:42.930 --> 00:11:46.090 We can't, you know, new releases need to not break things. 00:11:46.630 --> 00:11:52.670 Rust and Gleam and Go are all languages that I think went 1.0 and had a strong 00:11:52.670 --> 00:11:56.830 backwards compatibility guarantee relatively early on. And I think that really 00:11:56.830 --> 00:11:57.750 helped them with adoption. 00:11:58.310 --> 00:12:02.730 But to me, my goal is not immediate term adoption. I'm more thinking about what 00:12:02.730 --> 00:12:04.510 we're trying to do is really ambitious. 00:12:04.890 --> 00:12:08.430 And I really, really, really want to get it right, or at least as close to right 00:12:08.430 --> 00:12:11.310 as we can get it before we make commitments to backwards compatibility. 00:12:11.990 --> 00:12:16.150 So that's the type of thing that I think thinking in decades has as a benefit. 00:12:16.430 --> 00:12:19.590 It's that I can say, yeah, we've been working on this for years, 00:12:19.630 --> 00:12:23.230 but we still don't have a numbered release because I really want to clearly 00:12:23.230 --> 00:12:25.750 communicate to people, things are going to break. 00:12:27.490 --> 00:12:30.510 Please don't expect that we're going to have backwards compatibility because 00:12:30.510 --> 00:12:31.550 we're not ready for that yet. 00:12:31.710 --> 00:12:34.230 But I think we're actually almost to the point where we are ready for that, 00:12:34.230 --> 00:12:37.850 which is pretty exciting milestone to be coming up on hopefully next year. 00:12:38.580 --> 00:12:40.440 I want to talk about Rust, the 00:12:40.440 --> 00:12:45.840 good parts, for a moment, because not everything was bad, I'm assuming. 00:12:46.900 --> 00:12:51.240 In your post, you already mentioned a couple of really sane reasons to move away from Rust. 00:12:51.380 --> 00:12:55.540 But can you talk to us a little bit about the good parts, the things that you 00:12:55.540 --> 00:13:00.780 like about Rust, working with larger codebases, and what does it really feel 00:13:00.780 --> 00:13:03.540 like to work in the trenches with such a language? 00:13:04.260 --> 00:13:06.080 Yeah, there are lots of good parts to Rust. And to be clear, 00:13:06.220 --> 00:13:07.740 I like Rust overall as a language. 00:13:07.940 --> 00:13:12.420 I'm not like a Rust hater. I'm not like, oh, Rust is old and busted and Zig 00:13:12.420 --> 00:13:14.660 is like the new hotness. It's very much the opposite. 00:13:14.860 --> 00:13:20.280 It's more that for this particular project, I ended up deciding that if we're 00:13:20.280 --> 00:13:23.920 going to do a rewrite anyway, then that rewrite should be in Zig rather than 00:13:23.920 --> 00:13:28.440 rewriting it again in Rust, which we'll get to. But yeah, Rust's the good part. 00:13:28.600 --> 00:13:31.900 So I mean, the first thing that I would mention is that, like I said, 00:13:32.000 --> 00:13:38.260 I work at Zed full time, and I don't think it would make any sense for Zed to move away from Rust. 00:13:38.560 --> 00:13:43.420 Like Rust seems like it just fits the way that Zed's codebase works like a glove. 00:13:43.620 --> 00:13:48.720 If you wanted to rewrite Zed in something other than Rust, first of all, 00:13:48.780 --> 00:13:52.360 that sounds like a really daunting proposition, not just because it's a lot 00:13:52.360 --> 00:13:56.200 of work, but because Zed's codebase very, very heavily works. 00:13:56.220 --> 00:13:59.560 Relies on a combination of features that Rust is really good at, 00:13:59.900 --> 00:14:05.640 such as you have the memory safety, which when you have a wide contributor base, 00:14:05.860 --> 00:14:07.200 we have Zed's open source. 00:14:07.340 --> 00:14:10.840 So it's not just that we have people at Zed working on Zed, but also we get 00:14:10.840 --> 00:14:12.120 all sorts of outside contributions. 00:14:12.740 --> 00:14:17.160 It's really helpful in that context to be able to look at someone's pull request 00:14:17.160 --> 00:14:22.140 and be able to say with a lot of confidence, okay, this is not introducing sneaky memory safety bugs. 00:14:22.140 --> 00:14:26.600 Now, granted, you can make the point that, you know, lots of non-memory safe 00:14:26.600 --> 00:14:29.520 languages have lots of contributors too, like Zig, for example. 00:14:30.020 --> 00:14:33.780 Also Ghosty, which Mitchell Hashimoto made in Zig, has lots of contributors. 00:14:34.440 --> 00:14:38.080 But I think it's definitely a selling point of Rust that when I look at a pull 00:14:38.080 --> 00:14:41.540 request coming into Zed, I can say with a lot of confidence, 00:14:41.540 --> 00:14:45.660 this is not going to introduce some very subtle memory safe debug that I'm going 00:14:45.660 --> 00:14:48.980 to have a really difficult time debugging later. 00:14:48.980 --> 00:14:53.800 Sort of the blast radius of what a new contribution can do in terms of mistakes 00:14:53.800 --> 00:14:58.040 is a lot smaller I do think that's something we benefited from in the Rust version 00:14:58.040 --> 00:14:59.180 of the Roc compiler as well. 00:15:00.410 --> 00:15:03.450 So outside contributors, but also, of course, you know, within the code base, 00:15:03.530 --> 00:15:07.570 it's the same thing. It's definitely a benefit to not have to worry about those things. 00:15:08.150 --> 00:15:12.410 I wouldn't say I've gotten zero segmentation faults or memory safety errors 00:15:12.410 --> 00:15:16.830 in either the original Rust compiler for Roc or in Zed. 00:15:16.950 --> 00:15:19.290 Actually, literally yesterday we had a seg fault in CI. 00:15:21.730 --> 00:15:26.950 And it was it was on well it was it was in our new Windows code base and some 00:15:26.950 --> 00:15:29.670 of the stuff that we're doing is very low level you know interacting directly 00:15:29.670 --> 00:15:33.310 with the operating system graphics APIs and drivers and stuff like that because 00:15:33.310 --> 00:15:37.170 we're it's a very high performance code base and you know, 00:15:38.090 --> 00:15:42.450 Zed is a good example of the classic Rust model of if you're going to have to 00:15:42.450 --> 00:15:45.690 have some unsafe code because you're doing just innately unsafe things, 00:15:45.890 --> 00:15:51.530 maybe for performance, maybe for FFI, whatever, just having it very small and contained is helpful. 00:15:51.790 --> 00:15:57.350 And so, you know, it is helpful to know that the surface area of that is smaller and more contained. 00:15:57.510 --> 00:16:01.590 And if you look at Zed's code base, I think you see what you want to see in 00:16:01.590 --> 00:16:04.390 a classic Rust code base, which is the amount of unsafe is a very, 00:16:04.470 --> 00:16:06.690 very small percentage of the overall code base. 00:16:07.930 --> 00:16:11.250 So yeah i mean i think all those things are great obviously the 00:16:11.250 --> 00:16:13.970 the cargo ecosystem is very large and there's lots 00:16:13.970 --> 00:16:16.830 of stuff you can get off the shelf which is nice there's this classic 00:16:16.830 --> 00:16:19.850 problem in a language where if you were to time travel back 00:16:19.850 --> 00:16:22.650 to when rust 1.0 came out or you know even before 00:16:22.650 --> 00:16:25.450 that everybody would say well ecosystem is 00:16:25.450 --> 00:16:28.230 a downside of rust where they would say like well there's no ecosystem you 00:16:28.230 --> 00:16:30.870 know how can you how can you ignore the gigantic c and c plus plus 00:16:30.870 --> 00:16:33.810 ecosystem whereas of course now ecosystem is the selling point 00:16:33.810 --> 00:16:36.790 i don't know how like people have amnesia about this but 00:16:36.790 --> 00:16:39.850 like it's like every language that has a big ecosystem 00:16:39.850 --> 00:16:42.970 today used to have no ecosystem it just 00:16:42.970 --> 00:16:47.490 grew over time that's just it's a normal part of a language growing so it's 00:16:47.490 --> 00:16:51.090 it's totally reasonable for people to say i don't want to use this language 00:16:51.090 --> 00:16:55.530 right now because right now the ecosystem is small but it's a little bit of 00:16:55.530 --> 00:16:58.850 a pet peeve of mine when people act like that's just this permanent state it's 00:16:58.850 --> 00:17:02.890 like no actually it's the opposite of that it always the ecosystem always grows. 00:17:03.150 --> 00:17:06.030 That's where all the ecosystems you think of as big came from. 00:17:07.060 --> 00:17:10.780 But certainly at this point, the crates.io ecosystem is just, 00:17:10.860 --> 00:17:13.780 you know, very large and you can pull all sorts of stuff off the shelf. 00:17:13.940 --> 00:17:18.060 And that's a selling point. There are some things in Zig that we use at Zed 00:17:18.060 --> 00:17:20.200 that we couldn't get off the shelf in Zig. 00:17:20.360 --> 00:17:24.480 We would have to do like FFI to a C library or a C++ and C++. 00:17:24.920 --> 00:17:27.780 If you're trying to pull stuff off the shelf in C++ and use that in Zig, 00:17:28.060 --> 00:17:32.800 that's a much bigger pain than trying to pull something off the shelf in C and use that. 00:17:32.800 --> 00:17:36.560 See it's a lot easier to interoperate with in Zig so 00:17:36.560 --> 00:17:39.540 yeah the ecosystem also a selling point and i 00:17:39.540 --> 00:17:42.300 think the biggest thing for zed's code base is just the fact 00:17:42.300 --> 00:17:47.160 that you have for lack of a better term drop and because you have drop you have 00:17:47.160 --> 00:17:51.500 reference counting automatic reference counting and we use arc all over the 00:17:51.500 --> 00:17:55.180 zed code base it's just everywhere and we rely on it very heavily we're constantly 00:17:55.180 --> 00:17:59.220 cloning arc things when i first got to the zed code base i was a little bit 00:17:59.220 --> 00:18:01.440 nervous because I would see these .clones everywhere. 00:18:02.140 --> 00:18:06.160 And my experience from writing the Rok compiler in Rust, which used very little 00:18:06.160 --> 00:18:11.520 Arc or RC, was that, oh, if I see a .clone, that's a hotspot. 00:18:11.620 --> 00:18:14.080 That's a big performance potential problem. 00:18:14.400 --> 00:18:17.340 And we had this convention of in the few places where we would use Arc, 00:18:17.440 --> 00:18:20.900 we would do the Arc colon colon clone. So it's really clear, 00:18:21.040 --> 00:18:21.920 like, don't worry, don't worry. It's okay. 00:18:22.180 --> 00:18:25.620 It's just a reference count bump. We're not deep cloning the whole thing. 00:18:26.480 --> 00:18:30.120 But in Zed's code base, if you did that, you would be writing arc colon colon 00:18:30.120 --> 00:18:34.740 clone so so many times it would just be everywhere so what happens instead is 00:18:34.740 --> 00:18:38.200 you just use dot clone because that's way more concise because that's the normal 00:18:38.200 --> 00:18:40.780 way that cloning is used in the Z code base, 00:18:41.520 --> 00:18:44.080 but to do that you do have to have that, 00:18:44.880 --> 00:18:50.580 drop, basically. You need to be able to have automatic, C++ people would call it RAII. 00:18:51.660 --> 00:18:55.560 Zigg, by design, does not have that. And so that's one of the examples of why 00:18:55.560 --> 00:18:59.700 the idea of rewriting Zed's code base in Zigg sounds totally ridiculous to me. 00:18:59.760 --> 00:19:00.760 It would just be a terrible choice. 00:19:01.540 --> 00:19:06.060 Because some projects, one language is a good fit for them, and then other projects, 00:19:06.200 --> 00:19:08.100 another language is a better fit for them. 00:19:08.580 --> 00:19:13.080 So I'm comfortable making the claim that I am happy writing rust at zed as my 00:19:13.080 --> 00:19:16.820 day job and i think that's the correct choice for zed and also outside of work 00:19:16.820 --> 00:19:21.960 having the Roc compiler be in Zig and i think that's the right choice for Roc 00:19:21.960 --> 00:19:26.760 compiler so different projects different needs that. 00:19:26.760 --> 00:19:30.880 Thing that you mentioned with arc clone and making that explicit really like 00:19:30.880 --> 00:19:35.060 that idea that's that's such a great idea because yeah you show that, 00:19:35.880 --> 00:19:38.880 Cost of cloning is really low. And of course, 00:19:39.000 --> 00:19:44.160 you couldn't do that in all places where you had a lot of usages of ARC, 00:19:44.240 --> 00:19:48.940 but I wondered if you could build a trade extension for that and you had a ARC 00:19:48.940 --> 00:19:52.680 underscore clone method on the type that was ARC, for example. 00:19:52.860 --> 00:19:57.900 And then it would be kind of, you know, explicit, but also weirdly strange. 00:19:57.980 --> 00:20:00.700 So I'm not 100% sure if you want to go down that route. 00:20:00.860 --> 00:20:05.140 But no, that's... I mean, we're probably not going to do that in Zed because 00:20:05.140 --> 00:20:08.660 I mean, the number of places we would have to switch to that is extremely high. 00:20:09.100 --> 00:20:12.340 But yeah, you can call it bump or something. Like you're just bumping the reference 00:20:12.340 --> 00:20:14.620 count. That's actually a really cool idea. I never thought of that. 00:20:14.980 --> 00:20:21.180 Yeah, nice. So you wrote a lot of Rust code, probably many tens of thousands, 00:20:21.380 --> 00:20:24.760 maybe hundreds of thousands, maybe millions of lines of code by now. I don't know. 00:20:25.020 --> 00:20:28.980 Probably hundreds of thousands. I don't think millions. I think I'm under 1 million probably. 00:20:29.600 --> 00:20:34.240 So yeah, the Roc compiler at the point where we decided to switch over and 00:20:34.240 --> 00:20:36.720 do the rewrite was at like 300,000 lines of Rust code. 00:20:36.820 --> 00:20:41.120 Now I did not write all 300,000 lines. There's a lot of other contributors involved in that for sure. 00:20:41.520 --> 00:20:45.040 But at the same time, I also wrote a lot of lines that ended up getting deleted 00:20:45.040 --> 00:20:46.400 or rewritten, et cetera. 00:20:46.700 --> 00:20:49.880 So I think between that and my work at Zed, I'm definitely sure it's multiple 00:20:49.880 --> 00:20:51.220 hundreds of thousands of Rust code. 00:20:51.360 --> 00:20:54.960 I also taught a course on Rust. I taught intro to Rust for frontendmasters.com. 00:20:55.200 --> 00:20:58.680 So that was like an eight hour course just teaching people Rust from scratch. 00:20:58.980 --> 00:21:02.800 I've not taught a Zig course there. I did teach a course but 00:21:02.800 --> 00:21:06.460 but yeah so i have a lot of experience hands-on 00:21:06.460 --> 00:21:09.620 in rust a lot a lot of hours with it and also i've taught 00:21:09.620 --> 00:21:13.640 it to beginners which always requires you know learning a little bit of extra 00:21:13.640 --> 00:21:16.600 detail about things where you sort of have these gaps and as soon as you have 00:21:16.600 --> 00:21:19.840 to explain it to someone in depth where they need to understand it you sort 00:21:19.840 --> 00:21:23.240 of immediately realize where the gaps are and kind of have to go fill some of 00:21:23.240 --> 00:21:27.820 them in so yeah i definitely feel comfortable saying i feel like a Rust expert, 00:21:28.060 --> 00:21:32.200 but not a Zig expert yet, I don't think. I've had a lot less time with Zig. 00:21:33.380 --> 00:21:36.400 Because that kind of leads me to the next question which is 00:21:36.400 --> 00:21:39.900 with that level of experience some 00:21:39.900 --> 00:21:43.540 patterns more or less naturally must have evolved and 00:21:43.540 --> 00:21:47.780 there are probably things that you would call idiomatic rust that maybe are 00:21:47.780 --> 00:21:52.280 not written down anywhere or maybe are not in the book what what would you say 00:21:52.280 --> 00:21:58.540 are some things that you would consider ergonomic or rustic code how does it 00:21:58.540 --> 00:22:00.560 look like what is it like in practice. 00:22:00.560 --> 00:22:04.520 Yeah well i mean the first thing is of course use unsafe as little as possible 00:22:04.520 --> 00:22:06.420 ideally not at all if you can avoid it, 00:22:08.040 --> 00:22:13.600 I guess there's a lot of using traits for things so for example if you can initialize 00:22:13.600 --> 00:22:18.640 something you probably want to use from and into like that's a kind of a standard 00:22:18.640 --> 00:22:22.220 practice in the ecosystem just so you can make the conversions a little bit more ergonomic, 00:22:22.740 --> 00:22:26.080 similarly if you're going to be formatting it as a string then okay maybe you 00:22:26.080 --> 00:22:30.480 want to give it display you probably want to give it debug I think there's a 00:22:30.480 --> 00:22:34.460 lot of trait centric thinking when I'm writing Rust code, like in terms of like 00:22:34.460 --> 00:22:36.820 what traits do I want to implement, even just the baseline. 00:22:38.050 --> 00:22:40.730 Don't write standalone functions in the top level of your 00:22:40.730 --> 00:22:43.490 module prefer to make an impl for the 00:22:43.490 --> 00:22:46.310 particular type and then you know add it 00:22:46.310 --> 00:22:49.410 to there unless you're writing some function that's really not tied 00:22:49.410 --> 00:22:52.510 to any one particular type kind of the default is 00:22:52.510 --> 00:22:55.310 to think in terms of types and in terms of traits and then in terms 00:22:55.310 --> 00:22:58.990 of impl and putting things on there um also like 00:22:58.990 --> 00:23:03.890 pretty straightforward you know to think about doing like 00:23:03.890 --> 00:23:07.090 taking references to things so like you know ampersand or 00:23:07.090 --> 00:23:09.910 ampersand mutt i say mutt people that said usually say mute 00:23:09.910 --> 00:23:13.050 but i don't know i've always said but so no i 00:23:13.050 --> 00:23:16.010 i since my first experience writing rust 00:23:16.010 --> 00:23:18.810 was with other people who you know were doing rust for the first time we 00:23:18.810 --> 00:23:21.750 kind of developed our own like terminology i guess 00:23:21.750 --> 00:23:24.370 or way of pronouncing things and when you're looking at 00:23:24.370 --> 00:23:27.050 other people's code you don't you don't see how they pronounce it but it said 00:23:27.050 --> 00:23:29.910 we pair program a lot i think i'm the only one who says mutt everybody else 00:23:29.910 --> 00:23:36.350 says mute but it's fine which makes sense it's mutable but anyway um so yeah 00:23:36.350 --> 00:23:41.090 So I think another sort of unwritten rule is that you really should try to avoid 00:23:41.090 --> 00:23:43.590 putting references in data structures, 00:23:43.830 --> 00:23:47.890 which is to say you should really try to avoid having lifetime type parameters 00:23:47.890 --> 00:23:49.910 in your structs or what have you. 00:23:50.290 --> 00:23:55.530 This is something that in the ROC code base, like the original one, we did not really do. 00:23:55.670 --> 00:24:00.130 So we kind of took the approach of, well, yeah, I mean, we don't want to have 00:24:00.130 --> 00:24:03.870 allocations for these things. So let's use Bumpalo for all of our arena allocations 00:24:03.870 --> 00:24:07.230 and then store references to either stuff on the arena or stuff... 00:24:07.230 --> 00:24:09.210 I guess, yeah, it always ended up being in the arena. 00:24:09.330 --> 00:24:11.510 It wasn't really on the stack because then the lifetimes wouldn't work out. 00:24:12.170 --> 00:24:14.250 But yeah, so that's another... 00:24:15.400 --> 00:24:18.040 I don't know unwritten rule i guess is and and it's it's not the 00:24:18.040 --> 00:24:20.960 type of thing where you necessarily need a rule because as we discovered 00:24:20.960 --> 00:24:23.900 if you do that the ergonomics end up being 00:24:23.900 --> 00:24:26.600 pretty annoying because you have this like tick a that's just following you 00:24:26.600 --> 00:24:30.240 around everything you write tick a tick a tick a tick a everywhere so 00:24:30.240 --> 00:24:32.980 i would say it's it's not that you can't do that 00:24:32.980 --> 00:24:36.380 in rust but rather that you know you're asking like what's idiomatic i 00:24:36.380 --> 00:24:39.420 think that's that's something that people tend to avoid is having 00:24:39.420 --> 00:24:42.060