WEBVTT 00:00:01.350 --> 00:00:06.290 Hello everyone, it's Rust in Production, a podcast about companies who use Rust 00:00:06.290 --> 00:00:07.970 to shape the future of infrastructure. 00:00:08.250 --> 00:00:14.630 I'm Matthias from corrode, and in this very special live episode from Rust Week 2025, 00:00:15.430 --> 00:00:20.810 we talk to Niko Matsiakis, Rust Core Team Member and Principal Engineer at AWS, 00:00:21.290 --> 00:00:24.110 about building foundational software with Rust. 00:00:26.670 --> 00:00:31.290 Niko, thanks for taking the time. This is a bit of a special episode today because 00:00:31.290 --> 00:00:36.810 we are at Rust Week in Utrecht, sponsored by RustNL. 00:00:37.390 --> 00:00:43.770 So thanks for the organizers. Can you talk a little bit about yourself and about your work? 00:00:44.070 --> 00:00:48.850 Yeah, so I have been working on Rust since 2011. 00:00:49.350 --> 00:00:54.570 I think I've been present and part of every Rust release. So I wasn't here from the very beginning. 00:00:54.970 --> 00:01:01.130 Only Graydon can say that. but I came in before 0.1 and I'm still here now and 00:01:01.130 --> 00:01:08.090 I mostly focus on the compiler and the language type system but I've also put 00:01:08.090 --> 00:01:12.930 a lot of time into thinking about how we run the project the kind of open source organization, 00:01:13.590 --> 00:01:15.770 and various other things over the years. 00:01:17.530 --> 00:01:19.270 What did you work on before Rust? 00:01:19.770 --> 00:01:25.150 So before I started working on Rust the most immediate thing I was doing was 00:01:25.150 --> 00:01:32.290 a PhD on, surprisingly, programming language design, which some of those ideas, 00:01:32.330 --> 00:01:34.050 I think, kind of made their way into Rust. 00:01:34.290 --> 00:01:38.110 But before that, I worked at a company writing a compiler. 00:01:38.630 --> 00:01:42.790 The company was called DataPower. We built an XSLT compiler, 00:01:42.990 --> 00:01:47.750 which is a functional programming language for transforming XML documents to other XML documents. 00:01:47.990 --> 00:01:52.250 And in the early aughts, you know, that XML was very hot. 00:01:52.590 --> 00:01:56.030 JSON didn't exist. Nobody cared. XML was going to be everything. 00:01:57.250 --> 00:02:02.210 And there it was. So it was kind of fun because this is a purely functional 00:02:02.210 --> 00:02:05.010 language. And so it had a lot of inefficiencies. 00:02:05.230 --> 00:02:08.970 Like, for example, if you want to have unique elements, you had to do something 00:02:08.970 --> 00:02:12.250 like for each element that doesn't appear earlier in the list. 00:02:12.370 --> 00:02:14.430 So that's like an on squared traversal. 00:02:14.770 --> 00:02:18.130 But our compiler would recognize that you were doing this. And we would, 00:02:18.490 --> 00:02:21.530 behind the scenes, insert a hash map, for example, so that it could be 01. 00:02:22.090 --> 00:02:25.970 So that way we could be like arbitrarily faster than everybody else's compilers. 00:02:26.110 --> 00:02:29.990 Just depending on how big I made the input essentially. You want a 10x win? No problem. 00:02:30.470 --> 00:02:32.510 100x? No problem. I'll give you what you want. 00:02:33.760 --> 00:02:36.560 Did you have any influence on the language design? 00:02:36.840 --> 00:02:37.440 No, no. 00:02:38.040 --> 00:02:43.639 Okay, so was it also your first experience with building a compiler or working on the compiler? 00:02:43.900 --> 00:02:49.419 Yeah, I was fresh out of college. I think I took a compiler course and thought, 00:02:49.620 --> 00:02:52.080 this is the best. So then I found a job doing that. 00:02:52.480 --> 00:02:56.260 I thought that I knew everything, pretty sure. Pretty sure I thought I was the 00:02:56.260 --> 00:02:58.460 best programmer that had ever walked the earth at that time. 00:02:58.660 --> 00:03:03.300 But I met in this job, I met some really smart compiler devs, 00:03:03.300 --> 00:03:05.120 people who have more experience than me. 00:03:05.240 --> 00:03:09.980 And I came to realize, oh, there are some things I haven't yet learned. 00:03:10.660 --> 00:03:13.800 And so that was actually why I wanted to do a PhD, was I thought, 00:03:13.880 --> 00:03:17.820 oh, maybe this would be a good way to get deeper and really understand more stuff. 00:03:18.420 --> 00:03:19.960 What was the compiler written in? 00:03:20.280 --> 00:03:21.020 In C++. 00:03:21.520 --> 00:03:24.200 Okay. And how did that feel on a day-to-day? 00:03:25.320 --> 00:03:31.480 I love C++. I had a great time. I mean, I definitely, I remember debugging some 00:03:31.480 --> 00:03:33.620 data races that were pretty fun. 00:03:33.820 --> 00:03:36.460 I remember watching The Lord of the Rings and it would be like, 00:03:36.560 --> 00:03:38.220 because it took like two hours to reproduce it. 00:03:38.340 --> 00:03:42.780 So I could watch like half of a movie while the thing would run and then I'd 00:03:42.780 --> 00:03:44.880 get one extra thing and I'd go, okay, that doesn't help. 00:03:44.960 --> 00:03:49.880 Let me add one more printline and then restart the test and go back to the movie. So it was good times. 00:03:51.540 --> 00:03:57.000 You know, C++ is a cool language that let you get super control and do all the 00:03:57.000 --> 00:03:58.720 things we wanted to do. So that was great. 00:03:58.880 --> 00:04:05.000 But yeah, definitely the debugging and in general correctness costs were significant. 00:04:06.250 --> 00:04:12.870 So you studied in Zurich at ETH, and then you started working at Mozilla. 00:04:13.350 --> 00:04:13.850 Yes. 00:04:14.190 --> 00:04:20.270 And by the time you arrived at Mozilla, was Rust already on your radar? Did you hear about it? 00:04:20.910 --> 00:04:26.250 Yeah, I came to work on Rust. I'd heard of it. I found the idea of a new systems 00:04:26.250 --> 00:04:28.010 programming language pretty exciting. 00:04:29.170 --> 00:04:34.850 And it had just transitioned. So I never used OCaml boot, which was the OCaml-based 00:04:34.850 --> 00:04:39.070 compiler for Rust. It had just gone self-hosting around when I started. 00:04:40.089 --> 00:04:44.190 But I was excited to see what it could be. I thought it was completely hopeless. 00:04:44.670 --> 00:04:49.250 I mean, it was like totally Quixotic. I don't know how you pronounce that word, but Don Quixote-esque. 00:04:49.890 --> 00:04:54.690 Essentially, like, but it would be fun while it lasted. That was sort of my take. 00:04:55.450 --> 00:04:56.910 Maybe we'll find some good ideas. 00:04:58.110 --> 00:05:03.770 Steve Klabnik once gave a talk at FOSDEM where he called that time the great in years. 00:05:04.570 --> 00:05:08.170 And not many people know a lot about Graydon. 00:05:08.330 --> 00:05:14.890 He's a bit of a mysterious figure. How was working with them back then and what 00:05:14.890 --> 00:05:20.010 was your experience back in the day? Can you talk a little bit about that? 00:05:20.870 --> 00:05:24.649 Yeah. Well, when I first got there, Graydon was on a bit of a temporary leave, 00:05:24.690 --> 00:05:29.770 but he came back and I really enjoyed working with him. I mean, he's a really smart guy. 00:05:29.970 --> 00:05:32.950 He's got an incredible knowledge of programming languages, 00:05:32.950 --> 00:05:35.649 like a encyclopedic one which you 00:05:35.649 --> 00:05:38.710 can see if you go back to the old language it has all 00:05:38.710 --> 00:05:41.410 these esoteric keywords that he 00:05:41.410 --> 00:05:45.110 chose out of like an homage to older languages i 00:05:45.110 --> 00:05:47.990 remember at some point he wrote a message that was like don't take my esoteric 00:05:47.990 --> 00:05:52.810 keywords away or something like this but like leave me one weird keyword but 00:05:52.810 --> 00:05:57.110 you know like it used to be that instead of enum we wrote tag and instead of 00:05:57.110 --> 00:06:03.370 match we wrote alt and instead of return we wrote ret instead of continue we wrote cont. 00:06:04.810 --> 00:06:08.250 I was like, I think that might get, I think we should pick another word because 00:06:08.250 --> 00:06:12.170 that might get mispronounced and it's going to sound bad to some English speakers. 00:06:12.430 --> 00:06:16.410 And so then we went to like loop and again, I always thought loop was kind of 00:06:16.410 --> 00:06:20.190 clever. That was one of his, it was like, how do you go back around the loop? You write loop. 00:06:20.690 --> 00:06:24.930 But anyway, eventually we decided, no, we should just, we should just pick more 00:06:24.930 --> 00:06:26.630 normal keywords and landed there. 00:06:26.770 --> 00:06:29.210 But by we, you mean you? 00:06:29.770 --> 00:06:34.190 No, this was, well, this was after Graydon left. It was really me and Brian 00:06:34.190 --> 00:06:38.810 Anderson and Patrick Walton, who at the time were kind of the core team, 00:06:38.990 --> 00:06:42.570 the first core team of Rust before we had any other teams. 00:06:43.070 --> 00:06:47.490 And back then there were also quite a few pointer types that don't exist anymore. 00:06:48.350 --> 00:06:51.450 Yes. Well, they do exist. They've just gotten different names. 00:06:51.870 --> 00:06:56.450 You mean like the ~T and the @T. Yeah. 00:06:57.450 --> 00:07:03.410 Now, I mean, we had, I think I would say in general, what Rust's big evolution went from, 00:07:04.440 --> 00:07:09.120 Everything, we took a bunch of patterns, and they were all built into the language in the beginning. 00:07:09.860 --> 00:07:15.180 And then over time, they got moved out into more libraries as we realized the 00:07:15.180 --> 00:07:19.020 power of the basic type system concepts we were adding, right? 00:07:19.240 --> 00:07:22.660 Like of unique types that you can move from place to place, of borrowing. 00:07:24.020 --> 00:07:28.280 And that eventually got us to where we are now, where I'd say the actual core 00:07:28.280 --> 00:07:31.060 language of Rust, I mean, Rust is a pretty complex language. 00:07:31.060 --> 00:07:35.120 I think that is true. it's got a lot of stuff to know and understand but there's 00:07:35.120 --> 00:07:39.080 a core that it all kind of de-sugars to that is actually very very simple and 00:07:39.080 --> 00:07:41.720 that took us a while to find and get to, 00:07:42.460 --> 00:07:47.640 so in the beginning you would have for example there was a green threading library 00:07:47.640 --> 00:07:53.360 and you would launch tasks and the counting between tasks was all built in and 00:07:53.360 --> 00:07:57.980 we had these built in pointer types that kind of mirrored RC and box what is today RC and box, 00:07:59.000 --> 00:08:02.400 and all that stuff moved out right now the threads are in the standard library, 00:08:02.920 --> 00:08:06.320 Now RC and ARC are in the standard library as is Box. 00:08:06.700 --> 00:08:10.800 Box is still a little special. It's secretly the compiler knows things about 00:08:10.800 --> 00:08:15.600 Box it really shouldn't to make some stuff work. But it feels like it's in the library. 00:08:16.960 --> 00:08:20.840 And I think what that enabled is two things. 00:08:21.080 --> 00:08:25.060 It felt simpler, even though it's just a change of name. 00:08:25.280 --> 00:08:29.940 The fact that it's not a built-in character made it feel like applying a concept 00:08:29.940 --> 00:08:32.120 you already knew rather than a whole new thing. 00:08:32.500 --> 00:08:34.960 So Rcfeels simpler than @T. 00:08:35.600 --> 00:08:39.580 But also it meant we could secretly explode the number of pointer types. 00:08:39.700 --> 00:08:43.000 So I would say Rust has a lot more pointer types now than it used to, 00:08:43.160 --> 00:08:45.540 because now we have, I mean, if nothing else, we have RC and ARC. 00:08:45.880 --> 00:08:51.520 But we have pointer types out in the libraries. We have PyO3 and C++ Interop. 00:08:51.520 --> 00:08:55.780 I think each have their own sort of Py wrapper type and stuff like that, 00:08:55.860 --> 00:08:57.520 right? And so we've been able to... 00:08:59.690 --> 00:09:03.490 Adapt Rust into a lot more scenarios by focusing more on the core capabilities 00:09:03.490 --> 00:09:07.630 that you can use to build abstractions and not only to build abstractions, 00:09:07.750 --> 00:09:12.270 but to build safe abstractions and letting people in the ecosystem build their 00:09:12.270 --> 00:09:14.990 own libraries that create those abstractions. 00:09:14.990 --> 00:09:18.470 I would say that's a pretty C++-inspired thing in my view. 00:09:18.630 --> 00:09:23.730 I think C++ is like one of the original library languages. They may even have 00:09:23.730 --> 00:09:25.370 coined that term. Probably they did. 00:09:26.070 --> 00:09:30.410 Where they really aim to make you able to write everything in a library that 00:09:30.410 --> 00:09:32.030 you could do in the language. 00:09:32.330 --> 00:09:35.290 They just don't have the safety part of it, which I think is pretty important. 00:09:37.190 --> 00:09:41.070 So back then Rust looked very different than it does now. 00:09:41.230 --> 00:09:45.549 I can still remember the pre-1.0 days. People used the nightly Rust compiler. 00:09:46.330 --> 00:09:50.870 Things would change on a more or less regular basis, maybe weekly basis even. 00:09:50.870 --> 00:09:52.390 There were breaking changes. 00:09:53.270 --> 00:09:58.750 You touched on that when you said we had a green threading ecosystem or runtime 00:09:58.750 --> 00:10:01.590 and we had a garbage collector and that sort of thing. 00:10:01.809 --> 00:10:06.010 It was a totally different language by then, but there was a simple core. 00:10:06.590 --> 00:10:10.470 And if you had to explain that simple core to someone who's technical but doesn't 00:10:10.470 --> 00:10:12.950 know Rust yet, what would be the simple core of Rust? 00:10:15.390 --> 00:10:16.950 You set that one up for yourself. 00:10:17.049 --> 00:10:25.070 I did. That was dumb. The simple core of Rust, in my view, is you have ownership 00:10:25.070 --> 00:10:31.770 and borrowing, and you have trait dispatch, as well as regular functions. 00:10:32.750 --> 00:10:36.790 Ownership and borrowing, that's the main way we do our memory management. 00:10:37.070 --> 00:10:42.030 The idea that a given value has a single owner, and when it goes out of scope, 00:10:42.190 --> 00:10:43.170 it's going to run a destructor. 00:10:43.530 --> 00:10:47.850 That simple concept, on top of that you can build Rc, you know, 00:10:47.910 --> 00:10:52.410 ref counting is just decrementing and incrementing the ref count at the right times and so on. 00:10:52.970 --> 00:10:56.549 Borrowing is just getting temporary access to something and knowing that it 00:10:56.549 --> 00:11:02.250 won't be dropped or mutated while you're accessing it, 00:11:02.610 --> 00:11:07.309 which then turns out to translate to kind of, that's the key property you need 00:11:07.309 --> 00:11:10.710 for an awful lot of things where you want to say, I need to give access to my 00:11:10.710 --> 00:11:15.710 internals but I need to make sure that that access as long as you're using my internals. 00:11:17.140 --> 00:11:20.960 I don't break you, essentially. And other languages don't have a way to do that, 00:11:21.160 --> 00:11:24.299 at least not to enforce it. So we have the ownership and the borrowing. 00:11:25.020 --> 00:11:30.780 The trait-based dispatch is the way to say, for a given, here's a given operation 00:11:30.780 --> 00:11:33.380 that can be implemented differently for a lot of different types. 00:11:34.400 --> 00:11:40.700 And so to have the same concept, like adding a number or adding things that can be applied. 00:11:40.900 --> 00:11:43.480 You can add numbers, you can add strings, you can add whatever. 00:11:44.320 --> 00:11:47.960 That's a key concept. And we use that then as a building block for a whole bunch 00:11:47.960 --> 00:11:52.320 of stuff, including things like marker traits, where there isn't even a method. 00:11:52.480 --> 00:11:54.080 It's really just like a set of types. 00:11:54.360 --> 00:12:00.620 So send and sync saying the set of types that are thread safe and that can be 00:12:00.620 --> 00:12:02.040 safely shared across threads. 00:12:02.320 --> 00:12:09.140 Those just are built on that simple core of types that implement traits. 00:12:09.820 --> 00:12:15.059 And then the last part is just kind of the standard C procedural programming. 00:12:15.340 --> 00:12:20.100 You know, we have structs and enums and functions and all that stuff. 00:12:20.620 --> 00:12:25.500 Yeah. But when you cooked it down to these essentials, and that happened, 00:12:25.500 --> 00:12:30.799 I guess, after the Graydon years when you were preparing for Rust 1.0, 00:12:30.940 --> 00:12:32.420 you had to remove certain things. 00:12:32.420 --> 00:12:36.040 You had to cut down the scope of the language. Was there a time when you realized, 00:12:36.160 --> 00:12:40.280 wow, there's really something novel there that hasn't been done before? 00:12:40.440 --> 00:12:43.160 Was there a moment when you realized, wow, this is something, 00:12:43.300 --> 00:12:46.820 all of these concepts that you mentioned, ownership, borrowing, trades. 00:12:48.140 --> 00:12:50.960 These form this really robust system? 00:12:51.540 --> 00:12:56.460 No. I think it came gradually over time. 00:12:56.760 --> 00:12:59.180 And of course, me being me, I'm the more thinking of it like, 00:12:59.460 --> 00:13:02.860 oh, all these concepts, they're so limited. There's still stuff we can't do. 00:13:03.660 --> 00:13:06.960 But that is to say, I think there really are a really robust system and they 00:13:06.960 --> 00:13:11.580 can do an awful lot. But I'm also aware that there's some areas where I wish we could do more. 00:13:12.260 --> 00:13:17.240 Like we can enforce that a reference to, we can enforce that as long as you 00:13:17.240 --> 00:13:20.080 hold a reference, you won't drop or you won't mutate the data inside. 00:13:20.360 --> 00:13:24.380 But sometimes you need more rich predicates. And I hope we get there someday 00:13:24.380 --> 00:13:28.020 of maybe even, in other words, I think there's still another generalization down. 00:13:28.820 --> 00:13:32.740 And I have secret wishes that we can find a way to get there and give just a 00:13:32.740 --> 00:13:34.400 little more power to build safe abstractions. 00:13:34.540 --> 00:13:38.660 But the question will be, can we do that while keeping the language lightweight 00:13:38.660 --> 00:13:40.680 and easy to use? I don't know. 00:13:41.200 --> 00:13:43.700 But yeah, I think it's something that we came at very gradually. 00:13:44.320 --> 00:13:49.200 And I don't know exactly when it, I can't recall exactly when it became clear 00:13:49.200 --> 00:13:51.500 that we had kind of landed on it. 00:13:51.580 --> 00:13:55.620 But I think it was, I guess I would say, at the point where we started seeing 00:13:55.620 --> 00:14:00.540 people come in with their own libraries doing surprisingly cool things based 00:14:00.540 --> 00:14:05.720 on the same set of type system concepts is when it became clear that, 00:14:05.800 --> 00:14:06.800 oh, this actually has legs. 00:14:06.800 --> 00:14:11.260 You can scale this up past the original stuff that we wanted to do and off into 00:14:11.260 --> 00:14:12.500 stuff we never even thought about. 00:14:14.140 --> 00:14:19.340 Why did it take so long? Because you couldn't have enforced these concepts in 00:14:19.340 --> 00:14:21.700 other languages that came before Rust. 00:14:22.000 --> 00:14:27.500 We have a long history of systems programming languages and none of them introduced 00:14:27.500 --> 00:14:32.520 ownership and borrowing as like a compile time guarantee enforced by the compiler. 00:14:32.680 --> 00:14:34.180 Why did that take so long? 00:14:35.340 --> 00:14:43.580 I mean, I think we were building on a pretty long history, both in industry and in research. 00:14:44.220 --> 00:14:48.440 It took a long time. Like when I wrote, the C++ that I wrote in the early aughts 00:14:48.440 --> 00:14:50.440 is not the C++ people right now. 00:14:50.860 --> 00:14:55.980 We used lots of pointers. Well, okay, it's debatable. It's not what they would call modern C++. 00:14:57.180 --> 00:14:59.840 We used lots of pointers. We used new and delete and all that stuff. 00:14:59.840 --> 00:15:04.620 And it took a while to develop and recognize the best practices and start to 00:15:04.620 --> 00:15:06.600 encapsulate them on the C++ side. 00:15:06.780 --> 00:15:11.960 But meanwhile, in research, there was ongoing work developing out linear types, 00:15:12.260 --> 00:15:15.060 which is to say unique types, borrowing. 00:15:15.260 --> 00:15:19.220 Those kind of concepts were also being explored, both in the context of systems 00:15:19.220 --> 00:15:22.620 programming and in terms of higher-level languages like Java, 00:15:22.800 --> 00:15:23.780 where they're still valuable. 00:15:24.180 --> 00:15:28.280 And so I kind of feel like the answer is because it wasn't obvious. 00:15:28.280 --> 00:15:32.860 And it took a while to get, you know, all the ingredients in the right place 00:15:32.860 --> 00:15:37.120 that you could kind of assemble the right stew out of them. 00:15:37.260 --> 00:15:42.520 Man, I'm not sure if that's the best metaphor, but in my view, 00:15:42.580 --> 00:15:48.540 like research and new things are always, almost always a combination of stuff 00:15:48.540 --> 00:15:51.740 that came before with a few tweaks and fit together in a new way. 00:15:52.200 --> 00:15:56.320 And I think that's the same here in Rust. We found a pretty good mix. 00:15:56.320 --> 00:16:00.700 But a lot of the stuff that we built on wasn't available like people hadn't 00:16:00.700 --> 00:16:03.140 thought of it five years before, ten years before. 00:16:04.620 --> 00:16:11.820 It was kind of nice when you said people can build really interesting things 00:16:11.820 --> 00:16:16.400 as libraries and they don't have to touch the core of the language and I guess 00:16:16.400 --> 00:16:22.200 that's also thanks in part to the trade ecosystem and enabling composition over 00:16:22.200 --> 00:16:23.040 inheritance for example. 00:16:23.040 --> 00:16:28.100 So can you maybe talk about some of the libraries that you saw that really astonished 00:16:28.100 --> 00:16:31.360 you that fit that description? 00:16:33.080 --> 00:16:34.160 I mean... 00:16:35.690 --> 00:16:39.010 Well, I don't know if I'd say that the regex crate astonished me, 00:16:39.270 --> 00:16:44.870 but it impressed me with the fact that it was able to be so complete and also so fast. 00:16:45.010 --> 00:16:48.230 It was like one of the very first crates where they came out for Rust, 00:16:48.410 --> 00:16:51.470 where suddenly you had this robust capability you didn't have before. 00:16:51.550 --> 00:16:53.990 And it was like, oh, it feels like using a real language. 00:16:55.350 --> 00:16:59.910 And if you look at it, it uses all these properties, like the ability to, 00:17:00.090 --> 00:17:03.870 when you match a regular expression against a string. 00:17:04.550 --> 00:17:08.310 You get back these match objects that are holding references into the string 00:17:08.310 --> 00:17:11.849 so they make sure that the original data doesn't go away while you're using 00:17:11.849 --> 00:17:13.590 the results of the regular expression match. 00:17:14.230 --> 00:17:18.849 And then you can cast them into ampersand stirs so you get out just a regular 00:17:18.849 --> 00:17:24.130 string data type that you can pass anywhere but it's tied all the way to your original string. 00:17:24.450 --> 00:17:29.170 And so actually even that simple interface winds up leveraging those concepts. 00:17:29.390 --> 00:17:32.150 I think that was one of the first where I looked at it and thought 00:17:32.150 --> 00:17:36.070 people are building like real stuff that's like 00:17:36.070 --> 00:17:39.130 i said feels like a real language and a competitive one faster 00:17:39.130 --> 00:17:42.450 than most of their competitors than the other regex implementations 00:17:42.450 --> 00:17:46.050 out there i mean rayon was another 00:17:46.050 --> 00:17:48.810 moment now that's one of my crates that's a little like to 00:17:48.810 --> 00:17:51.650 my own horn but nonetheless it was the 00:17:51.650 --> 00:17:54.609 result of a lot of iteration to get to the rayon interface 00:17:54.609 --> 00:17:57.369 and once we realized once it was like oh 00:17:57.369 --> 00:18:00.070 actually this this just works you know you can 00:18:00.070 --> 00:18:03.310 just make any iterator not any but most iterators parallel 00:18:03.310 --> 00:18:05.990 and they'll hold all the 00:18:05.990 --> 00:18:09.609 references they need and keep the stack frame alive and that was 00:18:09.609 --> 00:18:12.290 pretty cool that was i felt like oh we 00:18:12.290 --> 00:18:15.250 finally got it and and actually if you go back i 00:18:15.250 --> 00:18:18.190 guess maybe that was the moment to your earlier question at least 00:18:18.190 --> 00:18:22.150 as at least a moment because i remember i have 00:18:22.150 --> 00:18:24.790 notes somewhere i have to go back and find them but you know 00:18:24.790 --> 00:18:27.830 if different i had in mind something like rayon 00:18:27.830 --> 00:18:31.190 right and over it was evolving as the language evolved and it was much messier 00:18:31.190 --> 00:18:35.210 before and there was a point where I remember realizing oh I can take away like 00:18:35.210 --> 00:18:39.290 all that stuff that I used to have around at types and how to deal with them 00:18:39.290 --> 00:18:42.910 in the compiler and so on none of that's necessary because it all it's actually 00:18:42.910 --> 00:18:46.970 all just send and sync traits now that capture everything you need, 00:18:48.450 --> 00:18:51.190 I'm trying to think of others I mean. 00:18:52.750 --> 00:18:56.890 Tokio crates there's just so many good crates out there now it's like actually really hard to pick. 00:18:57.650 --> 00:19:04.390 But the Tokio grade is a great example honestly because for me it wasn't clear 00:19:04.390 --> 00:19:07.970 that you could build an entire async ecosystem as a library. 00:19:07.970 --> 00:19:13.310 Yeah and that i mean and a really performant one also right because. 00:19:13.310 --> 00:19:20.190 No other language has pulled it off before and i'm not even sure if any has pulled it up until now, 00:19:21.840 --> 00:19:25.840 You don't have to write the library itself, but also the trade system that goes 00:19:25.840 --> 00:19:27.359 with it, the futurist trade and so on. 00:19:28.040 --> 00:19:31.580 Were you involved in some of the discussions? Did people ask you for advice 00:19:31.580 --> 00:19:34.240 in that area, or did they completely build it independently? 00:19:34.720 --> 00:19:39.859 I wasn't very involved in the design of the future trade. I mostly followed along. 00:19:40.380 --> 00:19:44.200 Where I got more involved was really the last mile. 00:19:46.340 --> 00:19:49.080 Basically, should we write a weight X or X dot a weight? 00:19:50.140 --> 00:19:53.720 The hardest of all decisions that had to be made in that discussion, 00:19:53.720 --> 00:19:59.220 at least based on amount of time and a strong feeling that went into it. 00:19:59.320 --> 00:20:04.119 But I wasn't involved in the actual design of the async system itself. 00:20:04.520 --> 00:20:09.740 I have since become much more involved, more building on the foundations that 00:20:09.740 --> 00:20:13.300 I would say Alex Crichton, cramertj, 00:20:14.260 --> 00:20:19.099 withoutboats, Carl Lerch, Those are the names I mainly remember going around 00:20:19.099 --> 00:20:21.099 at the time. I'm sure there are a bunch I've left out. 00:20:21.280 --> 00:20:24.280 It's due to my ignorance, not their lack of contribution. 00:20:24.800 --> 00:20:27.340 Well, Aaron Turon, of course. I shouldn't overlook him. 00:20:28.740 --> 00:20:32.700 Correct. Do you think we made the right call? Dot await? 00:20:33.170 --> 00:20:33.410 Oh, 00:20:33.520 --> 00:20:33.700 definitely. 00:20:34.950 --> 00:20:35.820 Why do you think so? 00:20:36.840 --> 00:20:42.340 I mean, well, reason number one, every time I use a language that goes the other 00:20:42.340 --> 00:20:44.760 way, I'm like, oh, my God, this is so annoying. 00:20:45.800 --> 00:20:48.640 But also it's just it fits 00:20:48.640 --> 00:20:51.780 in with everything else it's you you want 00:20:51.780 --> 00:20:56.619 to be able to put a question mark after it you want to be able to do awaits 00:20:56.880 --> 00:21:01.920 in a row to say hey i take this thing which gives me a future i dot await it 00:21:01.920 --> 00:21:06.140 i do something else which gives me a future i dot await that basically the more 00:21:06.140 --> 00:21:10.560 we can shift towards towards post fix the more smoothly the language operates. 00:21:10.880 --> 00:21:15.980 I feel like it's kind of a thing we inherited from, I don't know, 00:21:16.119 --> 00:21:20.880 ALGOL or whomever's, I mean, we inherited from C, but people usually say ALGOL-like for some reason. 00:21:21.560 --> 00:21:25.200 Because I looked at ALGOL and it does not look like C. So I don't know what they're talking about. 00:21:25.400 --> 00:21:29.680 But anyway, it's this sort of mix of prefix and postfix operators, 00:21:29.780 --> 00:21:32.220 and they just kind of make everything a mess. 00:21:32.580 --> 00:21:36.200 So overall, I think, yes, we definitely made the right call. 00:21:36.380 --> 00:21:40.480 And I wouldn't mind if we moved a few other things post-fix as well. 00:21:41.660 --> 00:21:42.160 For example? 00:21:42.840 --> 00:21:44.380 Oh, man. I walked right into that one 00:21:44.380 --> 00:21:44.560 too. 00:21:46.240 --> 00:21:49.700 Let's put it this way. I think the arguments in favor of postfix deref, 00:21:49.840 --> 00:21:55.640 so foo.star, even postfix borrowing, foo.ampersand, I mean, no one's proposed 00:21:55.640 --> 00:21:58.440 it, but I think it makes more sense. 00:21:59.099 --> 00:22:02.920 But the one one thing i would really like to see is match like 00:22:02.920 --> 00:22:05.900 being able to say something something dot match 00:22:05.900 --> 00:22:09.820 and the pattern so that you can say call a function and then 00:22:09.820 --> 00:22:16.220 match on the thing that it gives back to you without having to move the match 00:22:16.220 --> 00:22:21.800 in front i mean usually that's fine but it's not always especially like we've 00:22:21.800 --> 00:22:25.820 like with a try catch kind of scenario where you might which we don't yet have 00:22:25.820 --> 00:22:29.160 as a language feature, but we've talked about try-blocks, 00:22:29.320 --> 00:22:31.800 which would take the question mark and sort of intercept it. 00:22:32.000 --> 00:22:35.580 So you could write a try-block and have a bunch of things in there which may 00:22:35.580 --> 00:22:37.359 have results and have question marks on them. 00:22:37.599 --> 00:22:41.660 And then that entire contents of that would have type result. 00:22:43.060 --> 00:22:46.700 And if you do that, that's great. That's super useful. 00:22:46.880 --> 00:22:51.300 But now maybe you want to match on that result to decide if, 00:22:51.420 --> 00:22:55.180 hey, if the result was okay, I'm going to do one thing. And if there was an 00:22:55.180 --> 00:22:57.760 error somewhere in that computation, I'm going to do something else. 00:22:58.260 --> 00:23:01.340 And right now you have two choices. You can either write like match, 00:23:01.599 --> 00:23:08.119 try, open thing, lots of code, close, curly, open curly, which is very awkward. 00:23:08.680 --> 00:23:12.520 And it just seems weird. You've got this match that by the time you see the 00:23:12.520 --> 00:23:14.800 arms of the match, you kind of forgot the match was even happening. 00:23:15.180 --> 00:23:18.440 Or you can store it into a variable, which just looks dorky. 00:23:18.640 --> 00:23:22.180 So I don't know. It feels like a clear case where it would be useful. 00:23:22.180 --> 00:23:29.020 I guess one main argument against the postfix notation was not necessarily about 00:23:29.020 --> 00:23:33.300 the postfix notation in and of itself, but the fact that await was not a method, 00:23:33.440 --> 00:23:36.420 but it looked a bit like a method without the parentheses. 00:23:37.410 --> 00:23:42.310 But then it wasn't clear if that was confusing or not. So there was some pushback there. 00:23:42.570 --> 00:23:46.230 Can you remember what was your standpoint on this? 00:23:46.550 --> 00:23:50.790 I mean, people were concerned that it would look like a field or look like a method. 00:23:51.849 --> 00:23:55.770 I think it doesn't. I think everyone knows what it means. 00:23:56.030 --> 00:24:00.930 I think the most interesting part of that discussion, there were two interesting parts. 00:24:01.609 --> 00:24:04.390 One was or one is a thing that 00:24:04.390 --> 00:24:07.130 comes up a lot which is how important is it that 00:24:07.130 --> 00:24:10.230 you have like should we be looking at the experience when 00:24:10.230 --> 00:24:13.130 you're in an ide where you have syntax coloring and syntax 00:24:13.130 --> 00:24:15.849 highlighting available to you or should we be looking at 00:24:15.849 --> 00:24:19.849 the experience where you don't and it's all plain text because it's pretty different 00:24:19.849 --> 00:24:24.650 than if the thing is bright red versus gray like that's very noticeable but 00:24:24.650 --> 00:24:30.790 the other thing the other related thing is can we can we put ourselves in the 00:24:30.790 --> 00:24:35.230 shoes of how we're going to feel about this feature two years from now three years from now 00:24:35.670 --> 00:24:38.710 versus how we feel about it now and that's 00:24:38.710 --> 00:24:41.670 often pretty different and i think a lot of times we over rotate 00:24:41.670 --> 00:24:46.250 on how we feel about it now so a lot of times i do ask myself when we're facing 00:24:46.250 --> 00:24:51.810 a tough question like basically just think of think of what's going to feel 00:24:51.810 --> 00:24:57.849 the best when you're used to it and and optimize for that more than what makes 00:24:57.849 --> 00:24:59.849 the easiest transition from what i already know. 00:25:00.570 --> 00:25:04.270 And it's not to say I don't think we should worry about how you learn things, 00:25:04.410 --> 00:25:08.930 but in the long run, I spend a lot more time using the language over time. 00:25:09.190 --> 00:25:10.930 So you want it all to feel nice when it's done. 00:25:11.310 --> 00:25:15.869 The other interesting thing about that debate was I remember there was so many 00:25:15.869 --> 00:25:17.950 threads with so many comments. 00:25:18.170 --> 00:25:21.670 And at some point, I opened another thread and said, okay, only comment on this 00:25:21.670 --> 00:25:23.170 if you've actually used the feature. 00:25:23.650 --> 00:25:27.330 And that was like crickets. There was like three people commented there. 00:25:27.950 --> 00:25:32.690 And I thought, okay, that's kind of what I thought. It's very easy to jump in 00:25:32.690 --> 00:25:38.330 and give an opinion, but it's so often not really informed by real experience. 00:25:38.490 --> 00:25:45.350 And I found like just using a thing, usually within just even a minute of using 00:25:45.350 --> 00:25:47.170 it, kind of clarifies a lot of these things. 00:25:47.310 --> 00:25:50.250 You thought you had a whole bunch of questions and they get wrapped up very 00:25:50.250 --> 00:25:52.530 quickly as soon as you've used it, just for a few minutes. 00:25:52.890 --> 00:25:53.330 Yeah. 00:25:54.740 --> 00:25:57.640 A lot of things are obvious in hindsight. Hindsight is always 20-20. 00:25:57.880 --> 00:26:03.320 I do remember that I also found it a bit weird, but now I see it as a keyword. 00:26:03.460 --> 00:26:08.420 I see await as a keyword. I don't even read it as anything else by now. 00:26:08.660 --> 00:26:18.260 But we are in between 2015 where we had Rust 1.0 and 2018 where people started to use Rust for real. 00:26:18.520 --> 00:26:21.380 And in the meantime, a lot of things happened because a lot 00:26:21.380 --> 00:26:24.160 of embedded developers and people that wanted to play around 00:26:24.160 --> 00:26:29.980 with async rust were still on nightly so things were not as smooth yet and it's 00:26:29.980 --> 00:26:34.840 very hard to make such decisions under pressure because 2018 was a bit of a 00:26:34.840 --> 00:26:40.280 crunch to get everything ready take us back to that time how was that making 00:26:40.280 --> 00:26:42.960 decisions on the pressure and keeping the team together. 00:26:42.960 --> 00:26:45.720 So well 00:26:45.720 --> 00:26:48.660 first thing await wasn't await wasn't technically gated 00:26:48.660 --> 00:26:51.700 on the rust 2018 edition so we 00:26:51.700 --> 00:26:54.400 decided that kind of independently which is good there was 00:26:54.400 --> 00:26:58.300 enough pressure on that edition as it was i think that was 00:26:58.300 --> 00:27:01.520 a bit of a tough time i mean i think it was the right well i'm 00:27:01.520 --> 00:27:04.900 happy that we did the 2018 edition and i think it was a watershed 00:27:04.900 --> 00:27:08.220 moment for rust where we really it wasn't 00:27:08.220 --> 00:27:11.120 just the work we did on the ergonomics initiative which for 00:27:11.120 --> 00:27:13.920 those of you who weren't paying attention at the time was an effort to like 00:27:13.920 --> 00:27:16.680 reduce basically reduce foot 00:27:16.680 --> 00:27:19.840 guns reduce paper cuts and in 00:27:19.840 --> 00:27:23.180 general make rust simpler to use right and that was controversial 00:27:23.180 --> 00:27:26.260 like the decision to do that was fairly controversial 00:27:26.260 --> 00:27:29.400 because in a in a way it's going 00:27:29.400 --> 00:27:32.300 against the rule that i said of focus on 00:27:32.300 --> 00:27:35.520 what you're gonna want at the end because a 00:27:35.520 --> 00:27:38.240 lot of the more experienced users were saying hey i've learned 00:27:38.240 --> 00:27:40.920 that stuff already like you know we should be 00:27:40.920 --> 00:27:43.880 doing whatever we should go deeper into this area or 00:27:43.880 --> 00:27:46.700 do that and and we were saying no 00:27:46.700 --> 00:27:49.540 right and we pivoted back and i think that was the right move 00:27:49.540 --> 00:27:52.560 both because yes it was still important to learn rust 00:27:52.560 --> 00:27:57.800 that was not good enough yet but also because actually i think even for those 00:27:57.800 --> 00:28:02.340 users and i hope many of them would agree now they still had a lot of rust left 00:28:02.340 --> 00:28:05.840 to write and like that paper cuts are still been adding up all this time right 00:28:05.840 --> 00:28:09.800 like it just made rust much nicer to use overall And that was important for 00:28:09.800 --> 00:28:12.040 experienced users more than they may have realized. 00:28:12.400 --> 00:28:16.820 I think sometimes you don't realize how much of a toll the little ergonomic 00:28:16.820 --> 00:28:20.220 hits take on you as your writing code. So we were working on that. 00:28:20.520 --> 00:28:25.280 And I think the things we did were important. But the fact that we chose to 00:28:25.280 --> 00:28:29.220 focus on that was also really important. And I'm really glad we did it. 00:28:29.720 --> 00:28:32.780 And I feel like for me it helped. Because... 00:28:33.440 --> 00:28:37.520 I remember coming out of 1.0. 1.0 was a really clarifying moment, 00:28:37.880 --> 00:28:41.040 right? Because you could say, we have to reach stability. 00:28:41.640 --> 00:28:45.420 Here's a feature list. Let's work down our list of stuff we got to do. 00:28:46.020 --> 00:28:48.920 And all right, maybe you could punt something to make it unstable. 00:28:49.140 --> 00:28:54.720 But we could really focus our effort and really know, what is the right next 00:28:54.720 --> 00:28:56.720 step to take at any moment? It was fairly easy to answer. 00:28:57.000 --> 00:29:00.740 And after 1.0, it got more complicated again. Because now all those questions 00:29:00.740 --> 00:29:03.420 that you kicked down the road, You said, well, we don't really need to stabilize 00:29:03.420 --> 00:29:06.140 this in order to have a sensible, usable product. 00:29:06.460 --> 00:29:10.020 Now, all of a sudden, you look over this huge field of priorities and you say, 00:29:10.100 --> 00:29:11.640 which ones am I going to do? 00:29:12.080 --> 00:29:16.260 And that becomes hard again. And I think the ergonomics initiative, 00:29:16.260 --> 00:29:22.180 I think, was our first effort to sort of actually point in a direction and try to walk there. 00:29:22.440 --> 00:29:24.860 Saying, yes, we know there's a ton of important things to do. 00:29:25.600 --> 00:29:30.100 We're going to pick this one because to us, it seems like the right place to focus our effort. 00:29:30.260 --> 00:29:33.260 And we're going to go there. and then we'll come in and do some of those other 00:29:33.260 --> 00:29:35.340 things and that i think that's something that. 00:29:36.240 --> 00:29:39.020 Is really important to do as a leader 00:29:39.020 --> 00:29:41.920 in a community to be able to put yourself 00:29:41.920 --> 00:29:44.620 on the line to some extent to be brave enough to say this is 00:29:44.620 --> 00:29:47.560 what i think we should do and stand behind it versus trying 00:29:47.560 --> 00:29:50.560 to embrace every possible route so that 00:29:50.560 --> 00:29:53.300 nobody gets irritated and if you go back 00:29:53.300 --> 00:29:58.140 and look at like i have this blog post that Aaron Turon like liked or likes to 00:29:58.140 --> 00:30:02.300 make fun of a blog post an internals post but you'll see one where i summarized 00:30:02.300 --> 00:30:05.360 all the things that we could do after 1.0 and it was basically like a laundry 00:30:05.360 --> 00:30:09.280 list it was like 6 000 features thing here's our next set of priorities we're 00:30:09.280 --> 00:30:13.060 probably still working on half of those i think being able to focus on, 00:30:13.580 --> 00:30:15.320 a small number is really important. 00:30:15.320 --> 00:30:22.180 And especially the ergonomics part because those small little wrinkles they 00:30:22.180 --> 00:30:27.080 make people trip up over time and since this is a live podcast i'm curious is 00:30:27.080 --> 00:30:30.020 how many of you, raise your hand, even the one sleeping, 00:30:31.100 --> 00:30:35.080 Know about non-lexical lifetimes. Who has heard of non-lexical lifetimes? 00:30:35.300 --> 00:30:37.680 Raise your hand. It's like half the room, I would say. 00:30:38.220 --> 00:30:41.680 I guess that's a win because the other half doesn't have to deal with that. 00:30:42.420 --> 00:30:47.440 That was back in the day when Santiago Pastorino worked with you on non-lexical lifetimes. 00:30:47.680 --> 00:30:51.840 That was a really good lesson for me. For your listeners who don't know, 00:30:51.980 --> 00:30:55.760 non-lexical lifetimes was a change in how we did borrowing in Rust that made 00:30:55.760 --> 00:30:59.400 it not have to be tied to the lexical structure of your program. 00:31:00.080 --> 00:31:04.860 So it used to be that many times we would consider things borrowed for way too 00:31:04.860 --> 00:31:10.800 long because we were very simplistic about, like, you couldn't borrow for just the if. 00:31:10.980 --> 00:31:15.340 If you had an if and you used the pointer in the then part of the if but not 00:31:15.340 --> 00:31:18.280 the else, it would sort of expand to the entire if-then-else. 00:31:18.400 --> 00:31:19.680 It couldn't be just one half. 00:31:20.000 --> 00:31:27.140 And to be honest, that was by design because I thought, oh, it'll be easier 00:31:27.140 --> 00:31:30.800 to learn. Like, yes, you'll have more errors, but it'll be easier to learn if 00:31:30.800 --> 00:31:32.580 the formalism is simpler. 00:31:32.900 --> 00:31:36.680 You know, because I was a PhD student coming into language design or whatever, 00:31:36.900 --> 00:31:40.400 like I was looking at the AST structure and thinking this is good. 00:31:40.880 --> 00:31:45.760 I wasn't thinking about it from the point of view of a programmer using Rust 00:31:45.760 --> 00:31:49.700 who has not authored compilers or studied type theory and so on. 00:31:49.700 --> 00:31:56.120 And so it was kind of an aha moment for me to realize that what seems simpler 00:31:56.120 --> 00:32:03.500 to the compiler author doesn't necessarily feel simpler to the language user. And... 00:32:04.860 --> 00:32:10.560 That's shifted my thinking in several cases where I'm really asking myself, 00:32:10.760 --> 00:32:13.480 all right, I think there's a balancing act. 00:32:14.020 --> 00:32:17.860 You want them ideally both to be simple. I think you can go too far on either side. 00:32:17.960 --> 00:32:20.960 If you just say it doesn't matter at all how complex the compiler is, 00:32:21.260 --> 00:32:23.880 then it can be really hard. 00:32:24.200 --> 00:32:28.080 That ends up leaking into complexity for the user in the end because they really 00:32:28.080 --> 00:32:29.840 can't wrap their head around the algorithm. 00:32:30.400 --> 00:32:35.180 But on the other side, you really have to think about how are they going to 00:32:35.180 --> 00:32:38.180 experience it and feel it and try to put yourself in those shoes. 00:32:39.160 --> 00:32:46.260 And that was also right around the time when this first notion of epochs was 00:32:46.260 --> 00:32:48.320 introduced, which are now called editions. 00:32:49.100 --> 00:32:53.540 This promise of robustness and the guarantee to the industry to say we won't 00:32:53.540 --> 00:32:55.380 break things so you can depend on it. 00:32:55.500 --> 00:32:59.920 It was, I think, another very striking moment in Rost's history. 00:33:00.040 --> 00:33:03.540 Can you talk a little bit about that and what was the reasoning behind this 00:33:03.540 --> 00:33:05.480 and how Rust is tested as well. 00:33:06.160 --> 00:33:13.580 Well, the reason behind the stability promise, which was the 2015 Rust 1.0 release, was very simple. 00:33:14.880 --> 00:33:17.940 We had been changing Rust on a, as you say, weekly, daily basis. 00:33:18.220 --> 00:33:22.000 And we knew that we'd been working on it for a long time. 00:33:22.700 --> 00:33:27.380 To be frank, we knew we had to show some results if we were going to continue funding this project. 00:33:28.500 --> 00:33:31.320 And we also knew, we had a sense that, like, 00:33:32.580 --> 00:33:35.680 the world was being patient with us there was a lot of enthusiasm 00:33:35.680 --> 00:33:38.420 about rust people liked hearing about it rust news 00:33:38.420 --> 00:33:41.160 would go to the top of hacker news but how long could 00:33:41.160 --> 00:33:44.080 that stay we had to start seeing some production results and 00:33:44.080 --> 00:33:47.620 really getting out there and seeing it be in use before it becomes kind of vaporware 00:33:47.620 --> 00:33:52.400 so it seemed like the biggest blocking thing was stability and so that's what 00:33:52.400 --> 00:33:58.440 we focused on but yeah i think around 2017 i don't remember exactly when there 00:33:58.440 --> 00:34:02.680 were definitely some decisions where we started looking and saying, you know, in hindsight. 00:34:05.360 --> 00:34:08.060 That may not have been the best call, right? And I think there are lots of, 00:34:08.180 --> 00:34:12.199 particularly the module system was one where syntactically, the older module 00:34:12.199 --> 00:34:14.260 system was really tripping a lot of people up. 00:34:14.800 --> 00:34:19.219 And it was like, well, we made a promise for stability, but we know that the 00:34:19.219 --> 00:34:21.080 future is way bigger than the past. 00:34:21.480 --> 00:34:28.199 And these changes are sort of, yes, everybody has to make changes, 00:34:28.340 --> 00:34:30.100 but they're so, so programmatic. 00:34:30.280 --> 00:34:33.940 Like the compiler could literally change it for you. It seems like a real shame 00:34:33.940 --> 00:34:39.380 to get stuck in this suboptimal design that we see causing problems just because 00:34:39.380 --> 00:34:41.340 we said we don't want to break people's code, 00:34:42.380 --> 00:34:45.600 oh, maybe there's a way we could do neither, right? 00:34:45.620 --> 00:34:48.260 We could make the change and not break people's code. 00:34:48.480 --> 00:34:52.540 And in fact, I did not do this on purpose, but now that you mention it, 00:34:52.780 --> 00:34:56.080 the inspiration for additions came from XSLT. I forgot that. 00:34:57.600 --> 00:35:01.820 Because XSLT, that XML transformation language, if you go look at it, 00:35:02.020 --> 00:35:06.040 the very first thing you do in every XSLT program is you write version equals one. 00:35:06.699 --> 00:35:12.680 And they have an XSLT 2.0, which can run XSLT 1.0 programs. 00:35:12.960 --> 00:35:16.219 And it knows that they're not the same because it sees the version equals one. 00:35:16.420 --> 00:35:21.340 It doesn't quite work like our additions. If I recall, it runs them almost the 00:35:21.340 --> 00:35:23.600 same, but not quite the same as they used to run. 00:35:23.760 --> 00:35:25.960 It has like a compatibility semantics. 00:35:26.160 --> 00:35:31.640 But still, I remember thinking that that was a really clever idea to just a 00:35:31.640 --> 00:35:35.020 little bit of foresight to just declare the version number in your program. 00:35:36.199 --> 00:35:40.780 Thanks, XSLT, the contribution to this language. 00:35:41.560 --> 00:35:46.500 Yeah, I think we could talk about the history of the Rust compiler for a very long time, 00:35:46.500 --> 00:35:54.020 but I also wanted to change gears and maybe talk about some of the things that 00:35:54.020 --> 00:35:58.620 changed during that time where people started to use Rust for things that were 00:35:58.620 --> 00:36:01.280 not necessarily systems programming tasks. 00:36:01.280 --> 00:36:07.180 So suddenly people started to use Rust for backends and other endeavors. 00:36:07.719 --> 00:36:09.620 Was that a surprise to you? 00:36:11.660 --> 00:36:18.060 I'll tell you it was the biggest surprise. The biggest surprise to me was realizing 00:36:18.060 --> 00:36:23.180 was not so much the tasks that people were using Rust for, it was who was using Rust. 00:36:23.540 --> 00:36:27.940 Because I thought that Rust was targeting C++ users. 00:36:28.300 --> 00:36:31.280 But actually, I think that's more true now. 00:36:31.500 --> 00:36:35.980 But I think at the time, where the biggest initial adoption came from was people 00:36:35.980 --> 00:36:42.660 who would have liked to use C++, but for the lack of memory safety right folks 00:36:42.660 --> 00:36:46.120 who were using ruby were using java were using python, 00:36:46.760 --> 00:36:49.520 because they needed the productivity that it had to offer but they 00:36:49.520 --> 00:36:52.520 had these hot spots that were a pain in the ass to optimize and they 00:36:52.520 --> 00:36:55.300 couldn't they either couldn't get the performance they want or 00:36:55.300 --> 00:36:58.820 they had to work really hard to get the performance they want and this 00:36:58.820 --> 00:37:01.940 gave them a third option and so that that's that i think 00:37:01.940 --> 00:37:04.739 that was a great thing for rust also because they were coming from 00:37:04.739 --> 00:37:08.199 modern ecosystems and they were less forgiving like i 00:37:08.199 --> 00:37:13.080 remember i was like we don't need cargo make is fine that's 00:37:13.080 --> 00:37:17.800 true confessions because i don't know i just mostly wrote c and c++ code and 00:37:17.800 --> 00:37:20.880 make seemed okay kind of did the job but luckily there were people there who 00:37:20.880 --> 00:37:24.920 had used npm and they were like no Niko you are you're an old you're showing 00:37:24.920 --> 00:37:29.100 your age we need cargo and they were right and. 00:37:30.199 --> 00:37:32.960 So so i think it's it brought us like a whole audience of 00:37:32.960 --> 00:37:35.900 people who had very different who experienced modern tooling 00:37:35.900 --> 00:37:39.140 and were not willing to accept what was 00:37:39.140 --> 00:37:42.160 cool in the 70s so that was 00:37:42.160 --> 00:37:45.460 good in terms of systems programming 00:37:45.460 --> 00:37:48.360 i mean back-end systems i guess it's kind of debatable if it's a systems 00:37:48.360 --> 00:37:51.340 program or not but i think i don't 00:37:51.340 --> 00:37:53.880 remember thinking actively about it one way or the other to be honest because 00:37:53.880 --> 00:38:00.260 i'm a compiler person and networking is like a little over my head but but it 00:38:00.260 --> 00:38:04.900 doesn't surprise me now but what does surprise me is actually how good rust 00:38:04.900 --> 00:38:10.940 is at like scripting like i've had python scripts that i port to rust and it's like oh it's, 00:38:12.000 --> 00:38:14.840 either 20 longer or not even longer at all it actually 00:38:14.840 --> 00:38:18.160 feels better in some ways and worse and i don't know it's it's competitive at 00:38:18.160 --> 00:38:21.320 least if you know rust well and you know what how to use it right i think if 00:38:21.320 --> 00:38:27.239 you came in fresh you would not think that but so the fact that rust is versatile 00:38:27.239 --> 00:38:34.300 enough to be optimized for those foundational low-level applications and yet 00:38:34.300 --> 00:38:37.199 be usable all the way up is pretty important. 00:38:37.880 --> 00:38:41.480 And a little surprising. I think a cool outcome. 00:38:42.460 --> 00:38:47.739 And then during that time, let's say... 00:38:48.520 --> 00:38:52.680 Fundamentals of Rust also changed because Mozilla was struggling a bit with 00:38:52.680 --> 00:38:57.260 providing funding for Rust on a broader scale, just like many other companies. 00:38:58.020 --> 00:39:04.160 And then eventually some of the core contributors moved to other ventures. 00:39:04.420 --> 00:39:05.940 Some of them moved to big tech. 00:39:06.219 --> 00:39:08.600 How did that change the language? 00:39:08.980 --> 00:39:12.680 And that was also around the time when the Rust Foundation was founded. 00:39:12.680 --> 00:39:16.680 Yeah you know i think that mozilla gave rust 00:39:16.680 --> 00:39:20.120 a parting gift actually in deciding 00:39:20.120 --> 00:39:22.860 not to fund it anymore and i know 00:39:22.860 --> 00:39:25.680 that sounds maybe a little odd but like the truth 00:39:25.680 --> 00:39:28.480 was they had it didn't make that 00:39:28.480 --> 00:39:31.560 much sense for them and they had been slowly you know 00:39:31.560 --> 00:39:35.960 reckoning with their own financial difficulties for some time and like the team 00:39:35.960 --> 00:39:39.800 had been getting smaller but it was like they didn't want to i think i guess 00:39:39.800 --> 00:39:42.960 it's an interesting lesson right we're not admitting when the time has come 00:39:42.960 --> 00:39:46.420 can sometimes be worse than just admitting it and cutting off and i think the 00:39:46.420 --> 00:39:49.600 fact that they said we're not going to be able to fund this anymore was both 00:39:49.600 --> 00:39:51.260 obvious to everyone but also. 00:39:51.719 --> 00:39:54.580 Well not to everyone it was obvious to everyone who was close in but it 00:39:54.580 --> 00:39:57.580 wasn't obvious to all the companies that had been building on rust 00:39:57.580 --> 00:40:00.980 including my current employer at amazon and so 00:40:00.980 --> 00:40:03.840 it was a it was helpful for them to get a real like get 00:40:03.840 --> 00:40:06.580 a reality check of oh hey we're building all of this 00:40:06.580 --> 00:40:09.440 kind of foundational infrastructure in this 00:40:09.440 --> 00:40:12.580 programming language who's going to support it well i 00:40:12.580 --> 00:40:15.640 guess we have to and so i think that it it gave rise to 00:40:15.640 --> 00:40:18.480 a lot of rust teams across 00:40:18.480 --> 00:40:21.180 the industry that might never have come to be 00:40:21.180 --> 00:40:23.960 and that's meant a lot more people working on rust and a lot more 00:40:23.960 --> 00:40:27.020 investment in rust right and of course the most like 00:40:27.020 --> 00:40:29.719 visible sign of that was kicking off the rust 00:40:29.719 --> 00:40:32.800 foundation but i think in some 00:40:32.800 --> 00:40:36.640 ways i mean that's been really impactful but also the hiring of developers and 00:40:36.640 --> 00:40:40.060 the investment in the project side and the open source building maintenance 00:40:40.060 --> 00:40:42.580 side has been very important too 00:40:42.580 --> 00:40:45.460 did anything changed when you started working 00:40:45.460 --> 00:40:48.780 at aws or did you do more or less the same as you did? 00:40:48.790 --> 00:40:50.199 No it's been the same. 00:40:50.880 --> 00:40:53.680 I remember like i started at amazon and 00:40:53.680 --> 00:40:57.520 there's like this two week long like set of videos you're supposed to watch 00:40:57.520 --> 00:41:00.320 or whatever for onboarding and i was like i i can't watch these guys i have 00:41:00.320 --> 00:41:04.820 like four bus meetings like tomorrow i i don't know i already have a job so 00:41:04.820 --> 00:41:10.900 so yeah i pretty much have I just have had no real difference between working 00:41:10.900 --> 00:41:12.900 at Mozilla and Amazon, except for one thing, 00:41:13.320 --> 00:41:18.360 which I think is good, which is that Amazon's a lot bigger, doing a lot more things. 00:41:18.600 --> 00:41:24.140 And so I have a lot more contact with teams using Rust at Amazon than I did 00:41:24.140 --> 00:41:27.060 at Mozilla, if for no other reason than there are many more of them. 00:41:27.940 --> 00:41:31.600 But also in many different domains. So we have people using it in consumer devices, 00:41:31.860 --> 00:41:34.480 people using it in embedded, people using it in web services. 00:41:35.000 --> 00:41:39.320 And that lets me get a lot more hands-on knowledge about how those teams, 00:41:39.620 --> 00:41:40.860 like what their problems are. 00:41:41.020 --> 00:41:46.100 And there's something about being at the same company that gives you, like I can go deeper. 00:41:46.500 --> 00:41:50.300 I can get more and I can push them a little harder. 00:41:50.760 --> 00:41:53.760 I can be like, just stop being whiny. 00:41:53.920 --> 00:41:56.340 You can deal with that problem. That's not a real one. I'm like, 00:41:56.460 --> 00:41:59.280 let's go to the next thing on your wish list and talk that one through because 00:41:59.280 --> 00:42:00.460 I think you can handle that. 00:42:01.080 --> 00:42:06.080 And so I've found it personally that it's helped me get more perspective. 00:42:06.699 --> 00:42:10.140 But it hasn't really impacted my ability to work in the open in any way. 00:42:10.699 --> 00:42:17.040 Are you involved into any architecture discussions at AWS regarding Rust or 00:42:17.040 --> 00:42:20.040 is it completely running by itself? 00:42:20.480 --> 00:42:23.960 Well, I don't know what you mean by architecture. Do you mean like systems using Rust? 00:42:23.960 --> 00:42:28.500 Do people book meetings with you to talk through systems design problems? 00:42:28.860 --> 00:42:34.219 No, I wouldn't take that meeting anyway. No, they don't. 00:42:35.180 --> 00:42:38.219 Maybe a little bit, but not really. 00:42:39.400 --> 00:42:43.440 And the truth is, I'm not a domain expert in what they're doing. 00:42:44.300 --> 00:42:50.140 So it wouldn't really make sense to get my opinion on how to build a distributed system. 00:42:50.360 --> 00:42:52.780 I would rather go listen and learn from them. 00:42:53.480 --> 00:42:57.960 They will occasionally come to me with like here we have a it's usually around 00:42:57.960 --> 00:43:02.080 FFI or interop or some very narrow problem where we're seeing some overhead 00:43:02.080 --> 00:43:03.340 do you have any thoughts on how we might, 00:43:04.199 --> 00:43:07.960 optimize this case and usually I'll say yeah go talk to the much more qualified 00:43:07.960 --> 00:43:10.960 people on my team who can help you with that but. 00:43:11.680 --> 00:43:16.300 A sort of naive take on this would be what's in it for Amazon to hire you. 00:43:18.320 --> 00:43:21.300 Well I think that's a 00:43:21.300 --> 00:43:24.420 good question actually it's one i should have a good answer to because uh 00:43:24.420 --> 00:43:28.300 performance assessment time i think i 00:43:28.300 --> 00:43:31.239 don't i don't you know i don't provide that sort of leverage right what 00:43:31.239 --> 00:43:36.760 i do do is well to a certain extent help shape overall language usage strategy 00:43:36.760 --> 00:43:42.420 but more importantly find the places where people are getting stuck and figure 00:43:42.420 --> 00:43:47.699 out the best place to fix them right and that could be internal to amazon sometimes 00:43:47.699 --> 00:43:50.640 it's like we're missing a library but a lot of times it's like no, 00:43:50.739 --> 00:43:54.540 that's an indication of a problem in the language and drive that fix. 00:43:54.739 --> 00:43:57.340 That's the sort of short-term benefit. But I think the long-term, 00:43:57.560 --> 00:44:00.820 what Amazon really is interested in is knowing that. 00:44:02.870 --> 00:44:08.510 Investing heavily in a language which they know will continue to succeed in the industry. 00:44:09.449 --> 00:44:14.310 No one wants to write a bunch of code and then find out that there's nobody 00:44:14.310 --> 00:44:18.670 to hire who knows the language or there's no ecosystem around it so nothing's being developed. 00:44:19.030 --> 00:44:25.170 You want to be kind of sharing in, this isn't a competitive advantage, so to speak, to use Rust. 00:44:25.550 --> 00:44:27.670 That's not the way I want to say it. It is a competitive advantage, 00:44:27.790 --> 00:44:32.130 in my opinion, to use Rust, but it's not a thing that you want to keep to yourself. 00:44:32.130 --> 00:44:35.550 It's not the thing you're selling to users and customers, right? 00:44:35.690 --> 00:44:39.590 And so really what you're mostly interested in is having it be as good as possible. 00:44:39.750 --> 00:44:43.570 And that means benefiting from all the rest of the work that the rest of the 00:44:43.570 --> 00:44:47.469 industry is doing while contributing in and helping do your share, right? 00:44:47.570 --> 00:44:50.730 And I think these both are really important. And it's kind of the blend. 00:44:51.410 --> 00:44:55.969 Like I wouldn't want, I think if everyone who worked on Rust came from Amazon, 00:44:56.330 --> 00:45:00.070 even if we had the same number of people, you wouldn't get the same quality 00:45:00.070 --> 00:45:05.969 work out. because we would be overly rotating on the constraints and the concerns of Amazon builders. 00:45:06.190 --> 00:45:10.170 And so as happy as I am to go talk to those teams and get that detailed look, 00:45:10.370 --> 00:45:12.370 I think that on its own, it's not enough. 00:45:12.489 --> 00:45:17.310 What's really great is that I can do that and then hear from like Tyler Mandry 00:45:17.310 --> 00:45:22.910 and who works at Google and hear from Josh Triplett and all these other people in the Lang team, 00:45:23.090 --> 00:45:27.230 but also around the community who have insights, similar insights, 00:45:27.370 --> 00:45:28.190 but to different groups. 00:45:28.350 --> 00:45:32.170 And often they have pretty different problems even when doing a similar thing. 00:45:32.469 --> 00:45:36.150 And so when you cut them together, you wind up with a really good overall solution. 00:45:36.750 --> 00:45:40.230 So that's kind of, I think Amazon recognizes that. 00:45:40.350 --> 00:45:44.270 And I certainly like to tell them that as well whenever I get a chance, 00:45:44.530 --> 00:45:49.010 I advocate for this point of view, that the goal is to pick foundational technologies 00:45:49.010 --> 00:45:53.989 that you can really invest in and really get involved in and be a sort of well-respected participant. 00:45:55.219 --> 00:45:55.780 That's the goal. 00:45:56.500 --> 00:46:02.800 And yet AWS builds a lot of really critical pieces of infrastructure with Rust nowadays. 00:46:03.100 --> 00:46:07.040 I'm not sure if you can talk about a project that you particularly liked or 00:46:07.040 --> 00:46:11.580 maybe something that shows how Rust adoption can work successfully. 00:46:11.960 --> 00:46:16.960 Yeah. Most people I talk to are not aware of how much Rust is in production at Amazon. 00:46:17.260 --> 00:46:24.560 Like every S3 request, every EC2 VPC, you can tell my ignorance of even our own product line, 00:46:26.540 --> 00:46:29.360 every Lambda invocation these things 00:46:29.360 --> 00:46:32.900 all go through Rust they also go through other languages I'm not saying that 00:46:32.900 --> 00:46:37.320 they're exclusively written in Rust by any means but more and more the hot path 00:46:37.320 --> 00:46:43.520 of a lot of these big services that you know is being rewritten in Rust or re-architected 00:46:43.520 --> 00:46:47.520 in Rust and there are some services that are 100% so the new, 00:46:48.340 --> 00:46:53.360 S3 Express One Zone which is like a really low latency add-on to S3 that was 00:46:53.360 --> 00:46:58.380 added for various super low latency use cases, that's 100% Rust, for example. 00:46:58.780 --> 00:47:04.620 And the new serverless SQL is also 100% Rust, which came out at reInvent and 00:47:04.620 --> 00:47:06.460 is going to be hopefully GA very soon. 00:47:07.040 --> 00:47:14.320 So there are things coming up that are newer services or newer side add-ons 00:47:14.320 --> 00:47:20.940 to existing services that are 100% Rust, but also we're seeing a lot of Rust just here and there, 00:47:21.100 --> 00:47:25.020 scattered in and out the data flow, the hot path usually of other things. 00:47:26.040 --> 00:47:31.900 Were these services always established to be in Rust from the get-go or were 00:47:31.900 --> 00:47:34.719 they written in different languages and then migrated to Rust? 00:47:35.520 --> 00:47:37.540 Do you mean the existing ones? 00:47:37.920 --> 00:47:41.000 Like, for example, the SQL, the serverless SQL part. 00:47:41.360 --> 00:47:44.699 Oh, this one. Yeah, that's an interesting one. That one was not originally, 00:47:44.900 --> 00:47:46.440 that's been a long time in the making. 00:47:46.719 --> 00:47:50.360 And it started out, I think, in Kotlin. 00:47:50.980 --> 00:47:54.860 And they found that for various reasons they weren't able to get the latency 00:47:54.860 --> 00:47:57.140 that they needed in certain parts of the system. 00:47:57.280 --> 00:48:03.460 And so they migrated over just those parts into Rust initially as a kind of experiment. 00:48:03.699 --> 00:48:07.460 And when that went really well, what they realized is, oh, 00:48:07.760 --> 00:48:13.560 actually when we take these Rust parts and we combine them with the stuff that 00:48:13.560 --> 00:48:17.840 we wrote in Kotlin, we're having a lot of duplicated logic and we're getting 00:48:17.840 --> 00:48:21.680 a lot of integration failures just because we haven't been able to test them together. 00:48:22.260 --> 00:48:26.100 Like the Rust stuff was tested with Turmoil, which is that, this is a really 00:48:26.100 --> 00:48:27.900 cool Tokyo library. Some of you may have seen that. 00:48:29.030 --> 00:48:33.890 They can't use that library on the testing they were doing in the other service. 00:48:33.989 --> 00:48:36.510 In their Kotlin, they had a different thing that did different patterns. 00:48:36.690 --> 00:48:39.449 And so these kind of integrations were causing more failures. 00:48:39.770 --> 00:48:44.050 And in the meantime, they realized, actually, they originally thought using 00:48:44.050 --> 00:48:49.469 Rust was going to be kind of slower but worth it for the results. 00:48:49.630 --> 00:48:52.050 But what they found is, no, once you get past the learning curve, 00:48:52.090 --> 00:48:53.290 it's really quite productive. 00:48:53.650 --> 00:48:57.350 It's just the initial learning curve bump is the biggest problem. 00:48:57.350 --> 00:49:02.330 And so they ended up rewriting the whole thing in Rust so that it all works together smoothly. 00:49:02.610 --> 00:49:06.770 And I thought that was a really cool and interesting story in a number of ways. 00:49:09.370 --> 00:49:12.449 I'm happy with the outcome. I wish that Rust integrated better. 00:49:12.590 --> 00:49:17.030 I think it would be really cool if you could go back and forth between Kotlin and Rust more smoothly. 00:49:18.190 --> 00:49:21.910 But also the biggest takeaway I had is this point that I made earlier. 00:49:22.090 --> 00:49:26.050 It's really important for Rust. If Rust is to succeed, it has to be able to 00:49:26.050 --> 00:49:30.489 scale, not just with the hardest problems, but with the simpler and all the 00:49:30.489 --> 00:49:33.370 way up and be productive also in the easy problems. 00:49:34.510 --> 00:49:37.410 And I think this brings us sort of to the end. 00:49:37.550 --> 00:49:43.969 I wanted to get back to this notion of systems programming, maybe not capturing what Rust is today. 00:49:44.270 --> 00:49:49.830 And I guess you proposed a different term for it, which is foundational software. 00:49:49.830 --> 00:49:55.270 What is foundational software to you and why is Rust a great fit for this? 00:49:55.930 --> 00:50:00.989 Yeah, so to me, foundational software, it's the software that everybody else builds on. 00:50:01.690 --> 00:50:07.810 And that could be many different things, right? I think sometimes that's like the kernel. 00:50:08.310 --> 00:50:11.670 That's very literally the thing that everyone else runs on. But other times 00:50:11.670 --> 00:50:16.230 it's a CLI tool that's super widely used and it's part of the scripting setup you use. 00:50:16.230 --> 00:50:21.610 Or I don't know, your WordPress blogging platform could be seen in a certain 00:50:21.610 --> 00:50:24.590 way as foundational software. And I think. 00:50:25.280 --> 00:50:28.060 That's what I think Rust is optimized for, right? 00:50:28.199 --> 00:50:33.800 Is this kind of software that is making the world run, in some sense, our digital world. 00:50:34.140 --> 00:50:38.199 And that kind of software has particular characteristics. It needs to be really 00:50:38.199 --> 00:50:41.500 reliable because if it breaks, everybody else's stuff breaks. 00:50:41.640 --> 00:50:45.340 It needs to be fast because everyone's building on it. And so whatever performance 00:50:45.340 --> 00:50:48.220 hits you take there, everybody has to work with. 00:50:48.680 --> 00:50:51.800 And it has this long-term maintenance story. 00:50:52.100 --> 00:50:56.480 So you sort of stitch in time saves nine. is this English expression that often 00:50:56.480 --> 00:51:00.160 comes to my mind where it's like you would rather take the time to make sure 00:51:00.160 --> 00:51:04.380 that your match statement covers every case even if some of them just say panic, 00:51:04.900 --> 00:51:08.680 than not because you know you really don't want to miss a case. 00:51:09.040 --> 00:51:12.320 You're going to be maintaining this over the long term or you know that when 00:51:12.320 --> 00:51:17.000 new match when new variants are added to your enum if you have an exhaustive 00:51:17.000 --> 00:51:20.800 match you'll be able to find where they might need to be handled and you will 00:51:20.800 --> 00:51:22.440 be more likely to have a reliable outcome. 00:51:22.700 --> 00:51:26.160 So in those cases where you really would prefer to take the care, 00:51:26.360 --> 00:51:28.460 to check for the exception, to handle those things. 00:51:28.600 --> 00:51:32.120 That's what Rust is optimized for, and I think that's what shows up in foundational software. 00:51:32.340 --> 00:51:36.040 So I don't mean that all foundational software should be written in Rust. 00:51:36.740 --> 00:51:40.260 Like probably WordPress. Well, I don't know. I've never read WordPress's source 00:51:40.260 --> 00:51:42.140 code, but probably would be great in Rust. 00:51:42.280 --> 00:51:46.380 But I guess also it's working pretty okay in whatever it's PHP or whatever they wrote it in now. 00:51:46.540 --> 00:51:54.180 But I think that it probably all should be writable in Rust. 00:51:54.300 --> 00:51:56.980 And it probably would be a nice experience. That should be our goal. 00:51:57.580 --> 00:52:02.580 And also that similarly, I don't mean the rush should only be used for that 00:52:02.580 --> 00:52:05.620 kind of software, but that is what we optimize for. That's our sweet spot. 00:52:06.440 --> 00:52:10.140 Everything else should be good. We don't have to be, it may not be the best. 00:52:11.220 --> 00:52:16.640 It's a very profound insight to say the software that a business depends on, 00:52:16.840 --> 00:52:18.500 that is the foundational part. 00:52:18.640 --> 00:52:22.860 And then you can add, let's say, TypeScript or Kotlin or Python code on top 00:52:22.860 --> 00:52:26.500 of it. but seeing it as the runtime of the business, the core of the business. 00:52:26.640 --> 00:52:31.840 That's also one of the first users of Rust in production did. Dropbox. 00:52:31.860 --> 00:52:36.560 That's true. That's a good point. Yeah. Our very first production. 00:52:36.840 --> 00:52:39.020 Now, the very first production customer, I think, was Tilda, 00:52:39.180 --> 00:52:43.720 which is a smaller company. But Dropbox was like our first name band. 00:52:44.120 --> 00:52:48.120 Something I can say to my parents and they know what I'm talking about. That was cool. 00:52:48.420 --> 00:52:56.300 So what's next? what is mission of enabling foundational software in Rust for the next three years? 00:52:57.380 --> 00:52:59.060 Well, alright. What I'm, 00:53:00.100 --> 00:53:04.020 I have a lot of answers to that question, but the one that I'm most focused 00:53:04.020 --> 00:53:11.200 on right now, especially here at this conference, is laying out this vision doc project. 00:53:11.480 --> 00:53:16.040 And the idea is to take a look at where we are and say, hey, we're 10 years old. 00:53:16.980 --> 00:53:20.060 What's going to happen in our teenage years? And in particular, 00:53:20.340 --> 00:53:23.900 I think with all the growth of different companies investing in Rust, 00:53:24.420 --> 00:53:26.740 the number of Rust maintainers has gotten up. 00:53:26.740 --> 00:53:29.560 I don't know what the number is off the top of my head, but I'm sure it's in 00:53:29.560 --> 00:53:33.240 the hundreds, if not, well, probably not thousands, so hundreds somewhere in there. 00:53:33.540 --> 00:53:37.940 That's a lot of people to coordinate, right? That's a lot of work going on constantly. 00:53:37.940 --> 00:53:43.620 And I feel like we, I would like us to all be, if not on the same page, 00:53:43.820 --> 00:53:48.140 at least all sharing the same understanding of what Rust's users are experiencing, 00:53:48.380 --> 00:53:52.700 which things, where Rust is working really well and where it could use improvement and so on. 00:53:52.900 --> 00:53:56.400 And then using that to make decisions about what the next big initiative should be. 00:53:56.740 --> 00:54:02.380 So really in some sort of meta way, what I see as our top priority is building 00:54:02.380 --> 00:54:04.840 that shared understanding of what 00:54:04.840 --> 00:54:08.860 problems we want to solve more than the individual problems themselves. 00:54:10.340 --> 00:54:14.240 And as a final question, what's your statement to the Rust community? 00:54:15.680 --> 00:54:21.000 Yeah, be excellent to each other. I think Bill and Ted put it best and I can't do better than that. 00:54:22.720 --> 00:54:28.160 Niko, thanks so much for taking the time and thanks for all your work on the Rust compiler. 00:54:28.440 --> 00:54:29.740 Thank you for having me. 00:54:38.200 --> 00:54:43.900 This was a very special episode recorded at Rust Week in Utrecht. 00:54:44.100 --> 00:54:48.880 Thanks to Eric Jonkers, Hugo van de Pol and the other organizers and volunteers 00:54:48.880 --> 00:54:54.540 at Rust NL for providing the space and the opportunity to record this live episode. 00:54:54.540 --> 00:54:58.900 We had a blast at the event and we hope to be back next year for a full week 00:54:58.900 --> 00:55:01.240 of talks and events around Rust. 00:55:01.560 --> 00:55:05.100 If you want to learn more, head over to rustweek.org. 00:55:05.540 --> 00:55:09.040 Rust in Production is a podcast by corrode. It's hosted by me, 00:55:09.260 --> 00:55:11.840 Matthias Endler, and produced by Simon Brüggen. 00:55:12.100 --> 00:55:16.540 For show notes, transcripts, and to learn more about how we can help your company 00:55:16.540 --> 00:55:19.440 make the most of Rust, visit corrode.dev. 00:55:19.980 --> 00:55:22.220 Thanks for listening to Rust in Production.