 Hi folks, welcome to another stream and yet again I've decided to do something different. This seems to be my new thing is to do a new thing each time. I promise it's not going to stay like this forever, I'm experimenting with a couple of different kinds of things that would be interesting to stream. This one in particular, I honestly have no idea how it's going to work as a stream. It might be a complete waste of everyone's time, it might be super interesting, I honestly can't tell you. You're about to find out alongside me. The premise for this is that I've been asked to give a talk at Rust Nation, so Rust Nation is a new conference, a Rust conference that's going to spin up in London. It's happening in February and I was asked to give one of the keynote talks there and was sort of asked, well, what would you want to give a talk about? And I had a couple of different pitches, but ultimately the one that I went with is this one, Living with Rust Long-Term and here's the abstract I ended up writing and I figured it might be interesting to do a stream on making the presentation for that talk. And the reason why is because when making a presentation there's a decent amount of stuff that goes into the planning of the presentation or the motivation for why I made this presentation or how I chose the subset of stuff that should actually go on the slides that I think might be useful and interesting, not just for people who want to know more things about Rust, but also for people who want to get better at making presentations. I think seeing other people's process, not that my process necessarily is the right one, but seeing other people's process is often I think useful for improving your own just because it gives you a different perspective that hopefully you can take from going forward. And so this is my attempt at streaming the first steps of making a presentation like this. The other thing I'll say here at the head and I mentioned this to stream before I started recording is that I've done a bunch of changes to my streaming setup, in particular I now have a second monitor and streaming in 1440p instead of just HD. That all means that it could be that there's some weird artifacts or glitches with my screen setup or potentially that the stream can't quite keep up and they're stuttering and stuff. If that happens, please do let me know in chat so I can try to fix it. And this is another reason why I wanted a stream that's less important or one where I think it's less crucial that everything goes right, because this is going to be a very back and forth stream where it's more me exploring how to present these ideas than it is a watch it, start to finish, I'm going to teach you about a topic kind of thing. So definitely put questions in chat, we're in no rush here and we'll just see how far we get through it. You'll see that unlike many of my other streams here, I actually have a decent amount of tabs open already for stuff that I know I want to maybe talk about in the context of the presentation. So I have done a little bit of preparation here just by virtue of thinking about what this talk should be and writing the abstract and such. And so this is going to be a more of a let's structure all the thinking I've done into a presentation. I think it's useful here to actually give a read through of the abstract to sort of set the stage for what this talk is going to be. I guess I could tell everyone to read it, but in the interest of making things easier for people and also in the interest of me actually reading this carefully, I'm going to read it out loud and we'll see how that goes. So the talk title is living with Rust long term and the abstract goes as follows. Rust and its ecosystem are seemingly in constant flux and this appearance of perpetual motion can be scary, especially when you're building an application with stability and long term project sustainability in mind. New Rust versions bring ever higher additions must have new features and lint and tool changes to keep on top of. And as new features get adopted, new crates and major versions emerge, leaving once vibrant ecosystems to fade into oblivion. All this happens while the software ecosystem surrounding and underpinning Rust continues its relentless march forward. In this talk, we'll take a look at the kinds of changes that may happen under you when working with Rust and how to live with them. We'll talk about Rust and crate versioning, but also backwards compatibility, unstable features, minimum supported Rust versions and 1.0 releases. This talk is geared towards those using Rust to build applications and services, not those building Rust libraries. It won't tell you the right way to set up CI for your library crate or how to decide whether a change is backwards compatible or not. Instead, we'll dig into the kinds of stability challenges that can arise in Rust, what to do when they crop up and some promising avenues for making the stable life easier in the future. One important bit to highlight here is the part about this talk. That's the end of the abstract. One important thing to highlight here is that the intended audience for the talk here is not people who know Rust super well, you've written like four crates and you're maintaining them and setting up CI for them and deciding what their versioning policy should be. Those people aren't the audience for this. I think there are a couple of other sets of people that aren't the audience for this either. The reason I highlight this is because for many talks and especially technical talks, oftentimes there are multiple potential audiences and when that happens, there's sort of a subset of people who make talks and try to cater to every audience. They try to include stuff that's going to be interesting or useful or helpful to everyone involved, everyone who might see the talk. I don't want to do that because it tends to water out the presentation a little bit and make it less useful to the particular audience you had in mind. If anything, I'd arguably want to make two versions of this talk, one for the people who consume Rust, who primarily consume Rust, and one for the people who help make Rust or make crates in the Rust ecosystem. In this case, the Rust Nation Conference is, at least my impression, the idea is that it's going to be more for those who are interested in Rust, who are relatively early in their adoption of Rust. That's not to say that people with more Rust experience won't be there. I think they very much will or give talks there and such, but rather that the intention is to bring more people into the fold. That means that a lot of the people who I assume will be in the audience for this talk are going to be people who have these kinds of questions around Rust. They've heard the Rust is cool, but they've also heard that the ecosystem is constantly moving and there's all these new versions and new crates, and there's a lot of uncertainty and instability, and it's those people I want to talk to and try to give some advice. With that out of the way, I'm trying to figure out how I want to do this. I think I want to make a slide deck first so that we have somewhere to put all the notes we have. Now, there are obviously a lot of ways to make slides. I have tried most of them. I've used Keynote. I've used PowerPoint. I've used Google Slides. I've used LaTeX. I've used various HTML templates. Ultimately, I don't think it really matters, actually, what you use. I think the high order bit for me, at least, is that I want something where I can iterate on the slides fairly rapidly. For me, Google Slides works fairly well. It's also relatively easy to stream and it works on Linux, so that's what we're going to use. None of these, but instead, blank presentation. I probably did not want blank presentation today. Okay, first and most important bit, theme. What theme do I want? I like simple material. For example, it's nice. This beach day theme I actually used for my demystifying unsafe talk because I like the contrast between it's a very serious topic, but I wanted to highlight that it's approachable, so I wanted something that was fairly casual in appearance, which beach day very much is. I don't really know which one I want here. Modern writer, I've also used that for my Noria presentation. There's also certainly a, I want to try things I haven't tried before, game day, pop. Pop is cool. No light theme. Yeah, I mean, you're not wrong, but then again, white text on black background is much harder to read. And when it comes to presentations, actually, bright presentations tend to look a little better. How about we try pop? You can always change it later. Very colorful. Living. So here's the other thing, the decision we have to make. Do we, what kind of capitalization do we use? So there are two schools of thoughts here, primarily. There's this one, and then there is this one. For headlines, that is. You don't use this throughout the text, right? Do you highlight every word that's not a stop word? Do you capitalize every word that's not a stop word, or do you only capitalize starts of the start and proper nouns? I'm going to go with, I'm going to capitalize and be wild today. Subtitle. So I feel like in the Rust community, at least subtitles are often used for a fun take. What's the fun take going to be here? Let me run long term. For example, it could be how to not die a pre 1.0 death. But I'm going to run term finding inner peace. Sure, let's go with finding inner snake case for the headline. That'd be funny. So it could be something about stable and nightly. So it could be, although, so we'll get to this a little bit later too, but stable versus nightly is only a subset of the kind of things that I want to talk about here. But stability is pretty important without losing your hair. That's funny. How about stability and chaos? Let's go with stability and chaos for now. All right, news slide. Okay, so there are a couple of schools of thoughts here as well on when you do a presentation, where do you start? And one of the reasons why there's a lot of, you know, not debate necessarily, but there are a couple of ways to start. One is establish yourself as the speaker. Like, who are you and why are you telling me these things? Or not just why are you telling me these things, but why are you telling me these things as opposed to someone else? The other one is to start with a story. So make it something that people can relate to straight, limit the topic something people can relate to. And it doesn't really matter who you are, what matters is that you're conveying something that's interesting and that the audience sort of buys into and cares about. And then there's a third path, which is just get to the good stuff. Like you have a limited amount of time, and so you should just go straight to what's the problem? I don't think there's a right solution in general here. I think it depends on your audience, how much time you have and the talk you're giving. In this case, I think telling people who I am doesn't really matter, partially because I think I am decently well known in the Russ community now, so people don't generally need to be told, but also partially because this isn't about me. It's not as though I have some substantial experience here that makes me particularly well suited to giving this talk. I do have some experience working on top of Russ and through my work at AWS too. I see a lot of how people adopt Russ and the challenges they run into, but I don't think it's that important. A story hook works really well if you have a good story. One challenge we're going to have in this talk is that I'm actually trying to talk about multiple fairly different, but still intertwined issues. Think about things like the kind of things that are going to come up in this talk are nightly, 1.0 and breaking changes more broadly, deny warnings, and minimum supported Rust versions, and cargo lock. I don't know that I have one story. We could make one. One way to make a story is to say, meet the hypothetical person Alice. Here's what Alice would like to do. Alice would like to build the thing with Rust and then just continue to have it work. That is the storyline throughout the talk. As we get to, in fact, maybe this is a cool way to do it. When we get to something like unstable features, we can say, if Alice chooses to use an unstable feature, here's where things go wrong for Alice. That way, at least, it becomes a, we're telling a story about a hypothetical character that people can maybe empathize with or they can project themselves onto said character. The other way to go about these is to say, if you are taking a dependency on an unstable feature, I like this character that people can feel bad for. The other thing that's nice is what we can do is have this hypothetical character be essentially a representative of the audience. We can outline this person as someone who wants to build something cool and real. When I say real, I mean they're going to deploy something. It's going to be a production thing in Rust. That way, we're setting up the audience expectations for what the talk will be about. We're going to have to come up with a name for said character. I wonder if I can draw the character. It's going to be a stick figure. I'm great at drawing stick figures. What made you think about this topic in particular? Do you have any examples? It's a good question. For me, this is a combination of a continuous stream of questions and observations both within AWS and outside of AWS of just people who are working with Rust for the first time or sometimes for the nth time, and they keep running into similar kinds of issues, whether that is our new Rust version was released, and they don't know that it's generally safe to upgrade because they're used to other languages where that's not true, where a point release in Python might mean your code is broken, or suddenly code that built just fine no longer builds fine because they didn't upgrade their Rust version, but a crate moved its minimum supported Rust version. What do they do? Or they want to run deny warnings in CI, and suddenly now every six weeks their CI breaks because there are new warnings. It's not as though there's like one thing, but it's rather a... I've seen this pattern over time of people don't know how to think about living with Rust, like thinking about how Rust changes over time and how their code changes in relation to Rust over time, and what to do if something goes wrong. And that's why in this talk, I both want to tell them about things that can go wrong, but also what do you do if they go wrong in this way? Or how can you prevent them from going wrong? Or how can you basically proactively mitigate a particular set of problems? Can you just call them Alice programmers? They're used to Alice as a proxy and it's kind of fun. That's true, although Alice is usually used more in the cryptography space. That doesn't mean we can't use Alice. It's a good question. How do I choose this? How do I choose his name? It would be kind of fun to choose a... Okay, so one option is to choose, for example, Steve, right, as in Clabnick, or to choose, you know, Graydon, because Graydon Horror. We could also just use Ferris. Ferris is not bad. Or here's an even funnier one. We could do like a variation of Ferris. So we could say something like meet Fer, F-E-R. Fer is a crab and is looking to deploy some software to the sea at large. Harris is also good. All right. How about we do... I want to do like Ferris to make it like... Although I don't know whether I can keep a straight face and say... pronounce the name that way throughout the talk, but I feel like that would be pretty funny. Meet Ferris. Ferris is like you. I don't know whether I can keep a straight face through that, but it would be pretty funny. All right. Arky, Rick, Moody, Revdcel, that's funny. I like Ferris. I like Ferris. Although, so here's a question to those of you who know... I'm going to say French. Is the apostrophe the right direction? Or the... it's not the accent? Because there's like that one and then this one. Oh, that's funny. I could also do which is the Norwegian word for crab. I don't know if your audience will appreciate being called crabs. That's true. Or Clou, which means claw in Norwegian. Yeah, let's do... that's also easier for me to pronounce without laughing. Ferris. What have you done now? All right. Okay. So here's my other general objection with all slides. It's that the font size is always too small. Always make your font size a little larger than you think it needs to be. This also needs to be way bigger. 30... actually it's like click there and then 36. It's not going to fit with 36. Find 34. Clou is toilet in German. Okay, that's unfortunate. That is unfortunate. Although that kind of also makes it funnier as a name. All right, fine, furry. Okay. The point was to not make me laugh, although at the same time makes the the presentation more casual, which is always a good thing. Okay, furry wants to make... so I'm trying to set this up as a... we want to make the audience both like furry because they're going to occur throughout the presentation, but also identify with furry. And people tend to have a good view of themselves as in they think what they are themselves doing is generally good, is generally... they're generally thoughtful and have good motives. And so we want to make furry a likable character that they can identify with. It has to be a hat, really? I mean, I can make it be a hat like that. It is also pretty close to furry, I know. Why not write a script and then make a slide deck? Okay, so this is another good point. I don't ever have scripts for my talks. I sometimes have speaker notes, but often not. I want the slides to basically be my guide, and then I want to speak from my heart as I talk. I find that having a script tends to make the talk a little too rigid and static. It also means that if you mess up, like if you forget a part of the script or something, then you lose your place and then you try to find your way back to the script because you need to continue from where you had written. And that tends to make you stutter and move back and forth and get sort of confused. Whereas if you have these milestones that you know you're going to hit, which are the points in the slides, then you can talk in between them. This only works if you're relatively comfortable with improvising and sort of speaking... I don't want to say out of your ass, but if you're relatively comfortable constructing a path from one thing to another on the fly in an argument or a discussion, which I'm generally pretty comfortable with doing, so that process works for me, but it doesn't work for everyone. The other reason why I like it is sometimes I think of additional things I want to say during the talk, and then I want the ability to just say them. And with a script that's a little bit harder, it's not impossible. And yes, we'll see this when we go through that I tend to have my slides be a sort of a sequence of like pegs to hang the red thread of the presentation on, if you will. And so if I lose my place, I just need to look for the next peg. 3 wants to make good software. So they write it in Rust. Oh, this should really be a haiku given how it started. So I want something like this, right? It doesn't have to be... I don't know whether it's going to be exactly like this, but the thinking here is that I want a setup that is very simple, but it also like gives a sense of both the character and the sort of setting for the talk, right? So the thinking here is that, okay, we have free and free wants to make good software. They have already written it in Rust, right? So this is not about writing things in Rust. This is about you've already chosen Rust, you've already written software, and that's what happens next. And then the future comes along is intended at least as a, okay, so you've written software in Rust, now what? What hits you next? So it could be something like comes knocking. The problem here is comes knocking is a, you know, it's an expression that has a particular meaning, but you need to know about that meaning for the sentence to make sense. Like comes knocking is a sort of not slightly scary version of just arrives, right? Comes knocking implies that there's like problems ahead, but then the future arrives. We don't have to get this perfect the first time around. Well, one of the things that I end up doing is usually I write a first draft of basically the whole presentation, like all of the slides, and don't try to make them perfect the first time around. And then I do the presentation, like I time myself, I do the whole thing. And because I'm improvising as I go through it, as I improvise, I notice the places where a peg is missing, or a peg feels wrong, or in the wrong order, or I'm just like, this doesn't flow right, that the order of the presentation is wrong somehow. It becomes very apparent because when you're trying to improvise through this, if you notice that like the gap between one peg and the next is too far, or they don't connect well, it's going to make it basically impossible to improvise your way between them. So you really just like feel as though it's wrong. And oftentimes, as you improvise, you come up with better wording for what should be on the slide by virtue of your improvisation. And so you can then replace the text on the slides. Okay, so here's what I want next. So now we've set up who Phuri is, and we might want a picture of Phuri or something here, but we can do that later. This is not, you know, art direction. So the next sort of point of contention here now amongst, you know, people who make presentations is do you have a table of contents? And when I say table of contents, it's not so much, you know, list out what every slide is going to be, but rather, do you tell the audience ahead of time the kind of things that you're going to talk about? And conventional wisdom is that, yes, you should have a sort of road map for the audience so that they know what's coming, because it means that they can start to sort of leap ahead in their, in their heads that they know where the conversation is going. So they can interpret the things that you say towards where they know the presentation will go. The downside is that you're spending time on telling people what you're going to tell them, which is it feels a little bureaucratic, but there is certainly value in it. The question is, how do we want to present that value? So one option we have here is to do a section header. And actually, let me here. So we have two options. One is something like problems, furry, well, encounter. This is not necessarily a slide that we're going to include, but it might be useful just for our own sake to have a sort of reference point for the kind of things that we know we want to touch on. Okay, so for our own sakes, let's come up with this list. And then we can always adjust that later. So, and this is where we get to my tabs. Actually, this reminds me of this first one. I kind of want to talk about stability as a deliverable first. This blog post, I'll link it in chat. This is one of the first blog posts that was put out on the Rust blog. And it's a really good write up of what stability means in Rust. Like, why is there 1.0? Why is the compiler called stable? What is the stability thing in the first place? Because it sets the tone for what the Rust ecosystem, what the goals of Rust are in the department of stability. And because it sort of sets that tone, I think it might be useful to tell people about this expectation, too, because it's something that we can then build upon for the rest of the conversations. Because this one talks about, you know, Rust stable. But I think it's a kind of thinking a mental model, a principle, if you will, of Rust development that hits most parts of the Rust base. And it wouldn't really be a problem that Free would encounter. It's almost like we want to slide before here, actually. So, meet free, free is like you. Free wants stability. This is like a thing for update in theme. Yes, that's what I want. And here, too, I think maybe 28. One of the reasons why I make the font so large is also because it forces me to not use too many words. Update in theme, because that way it'll affect all of these. So I think at the very least, if I now apply, no, if I delete the slide, and then I make a new slide over here, why doesn't it unclear? This is supposed to update the theme so that have I accidentally selected some text in here. I want it to automatically apply to all the other slides, but apparently it doesn't let me do that. But what I want here is because this is what 34. So I want this to be 34. And this one stayed at 48. Okay, so if I now do here, can I save it here? I need the option that's down there. Why won't it let me scroll? It's very sad. Well, too bad. What I was thinking here is something like free wants stability. And then I kind of actually want us to have a sort of reference box that we can use near the bottom of the slides. Because I think this is going to be a general theme here that I want to provide people with like more info if they care. And arguably, given that this title was capitalized, these should also be capitalized, even though this is a sentence, but like this should be like wants stability. I don't like that. So we're going to be consistent and change this to be this. I want more sentences. This is another thing that actually one of my advisors during my master's taught me that the title of the slide should be the takeaway from the slide. It should be the conclusion of the slide. Because people might only catch the title because they're listening to you or they forgot to look at the slide just before you're about to change it. So the title is the first thing they'll see. But also it helps them tie together all the other stuff that's in the slide. So here, for example, free wants stability is the conclusion of the things that we're going to list here. And I think what we want here is to outline what does stability mean? So, oh, is there a, if I go here maybe format changed the pretty not weird. It's fine. I'll just change it as we go. Free wants stability. I don't know if free wants stability actually free wants. Okay, so my thinking here goes something like they want to keep their code at high quality. This is poorly written sentences, but I just want to get something down. I'll explain a little bit in a second. Not fix what isn't broken. They want to get updates. And they want to avoid toil. So all of these are all of these are ways to think about stability, right? So keep their keep their code at high quality is a poor way to phrase this. I want to phrase this as the thing I'm getting at here is like imagine that a new lint comes along in the compiler or in clippy that catches a case where your code is way less performant than it could be, for example. So fairy would want to know about that change that they should make to their code. This does not really keep their code at high quality as much as it is. It's like keep their code good. They want to learn if their code is bad. I almost put they want to follow best practices. But I don't think in general people care so much about that. After you've written your software, if you used split.next.unwrap instead of split once, for example, is the kind of thing that clippy will lint about. You probably don't care. It doesn't mean your code is better now. But the move from like, for example, before we had slice split at mute, you would have to write this one with unsafe code and a clippy could recognize whether what you were writing was really just the same as split at mute and you can replace that with completely safe code. And that I think is something that there's definitely benefit in even if you've already written your software. Or in cases where you, what's a good example of this, there are definitely lints where clippy does things around raw pointers, for example, where clippy is like, hey, you could just use this pattern, which is actually safer. And it might be that the thing that you're doing is actually wrong and dangerous for subtle reasons. And so a new clippy lint basically comes along and says, the code that you had kind of sort of just works on accident. Like it's essentially not necessarily vulnerable, but it's problematic or error prone. And then there are also things like performance improvements where like you wrote a thing that ends up, you know, walking an entire array, when in reality you could have just done a binary search over it, like whatever, just a lint that looks for performance improvements that you could do in your code. Imagine, for example, there was a clippy lint. I don't think such as a clint exists at the moment, but that could detect whether it's safe to use swap remove instead of remove on a vector. Swap remove is way faster because it doesn't have to shift all the other elements. And so if such a lint came along and it triggered on your code, you would want to know because it's a place where the new lint is telling you that your code could be better. Are you talking about code that devolves or deteriorates by itself because interface has changed or just new lints? This one in particular, I'm talking about there is a better way, there's like an objectively better way to write this particular piece of code in terms of correctness, safety, or performance. And you would want to know if that's the case. And the question is, how do you say that concisely? Because remember, I can say this with words when I present the slide, but I would like to have a bullet point here that both reminds me what I'm supposed to say, but also for the audience that they can look back on this and go, oh, right, this is that thing. So it doesn't have to be complete, but it does have to have all the clues in it. I'm hesitant to write like learn if their code could be better. So I kind of want to say they want to keep, well, this is I guess what I originally wrote, keep their code high quality, keep their code. Let's stick with keep their code high quality for now. Remember, this is so keep Clippy happy, sort of, but that's that gets into the second bullet point here around stability, right, which is they don't want to have to fix things that aren't broken. So if Clippy tells them, hey, did you know it's more idiomatic for you to not have the ampersand here because there's an auto D ref happening or an auto ref happening? That doesn't matter, right? Like I understand why Clippy tells you because it's more idiomatic. You don't need the extra symbol in your code. That's nice. It makes the code more readable. But if you have a stable code base, that's mostly noise, right? You could choose to deal with that on sort of batch basis, but it's very different from, hey, in this place, you're using like a you're using a dangerous code pattern or your code could be like O of n instead of O of n squared if you change to use this method instead. They want to get updates. This one is like they want to get updates to the standard library because things might get better. They want to get updates to dependencies because things might have been optimized or, you know, security issues might have been fixed. Yeah, maybe they want to learn if their code could be better. That's not really about stability, saying high quality code. This is not really about new features. Remember, we're not talking about staying up to date because you want new features. Stability here is I've already written my software. It already works. What do I want from Rust in the ecosystem? And then I don't care about new features. I might care, right? If I'm doing new feature development, for example, I might care about this new feature. But what I really want the sort of core, think of like the, what's it called, like the hierarchy of needs or something, right? Where the thing I really want is stability for the most of my development workflow because if there's a new cool feature in Rust and I already have my software working that's working fine, I don't care about that new feature. It might be cool for new development, but it's not important to me. When I say get updates, for example, it's not get updates in order to get cool new features. It gets updates for security reasons. It's get updates that give me automatic performance improvements. And this gets back to that fourth point, which is avoid toil. So maybe toil is a bad word here because it's a little bit of a weird word that not everyone will necessarily know, but I think it's an important word for people to know. So toil is like unnecessary work, like work for the sake of work. So Clippy lints, for example, could be an example of this for some lints, or even just lints from the Rust compiler where, for example, there's a lint that detects whether you have unnecessary parentheses around expressions. And imagine that I have deny warnings turned on and suddenly that lint is added. Well, the code is totally fine. There's nothing wrong with it. But there's still now a lint and deny warnings is going to cause that lint to trigger. So I have to go in to fix my CI. I have to go in and remove those parentheses, even though it did not matter. So I'm doing work only for the sake of work. And when you're in a stable mode, you don't care about those things. Yeah. So someone put in chat here, write once build always, which is sort of what this gets on. But again, it's not always going to be like that. Sometimes, you know, your build might break and the code might be the same, but it breaks for a really good reason. Like an example of this might be in CI, you're running Miri and on your test suite and Miri gets better and finds an actual case of unsoundness in your code. Well, now your code didn't change, but the testing infrastructure got good enough to catch a bug in that existing code. And then I do want my build to fail. So it's not actually write once build always. It's write once and then build unless it's important. And that's what I'm trying to capture in this list, right? There's essentially this tension between these different things that Furry wants. And in fact, I want to add that as a sort of reminder to myself. But these are in tension with one another, right? So they want to maintain high quality code, but they don't want to fix what isn't broken. They want to get updates, but they want to avoid toil. So I guess we can say here avoid unnecessary work. Avoid unnecessary short work is fine. So I think these two slides set up really well where we're getting at, right? So there is a character called Furry. We're going to refer to them throughout this. Furry is probably a little like you. They want to make good software. They write it in Rust, but then the future comes along and messes everything up. And what Furry ultimately really wants, given that they've already built the Rust thing, is they want stability, right? Now that they've written their thing, they've written, you know, hundreds of thousands of lines of Rust code, what they now want is, A, they want to maintain the high quality of that code. Let's assume that Furry is a good programmer. So they've written high quality code and they want to maintain that high quality, you know, in the face of, you know, the Miri getting better, for example. They also, because there's so much code there, they want to not fix what isn't broken. So if they get, if there's like a new fancy feature where maybe they could do something in a different way, they don't necessarily care. It's not broken, works just fine. There's no significant improvement that they could pick up by changing. Maybe it'll be a little more ergonomic, but they've already written the unergonomic code. So like it's not, doesn't really matter. They do want to get updates because there might be performance improvements or safety improvements to, to those updates and those they do want to take advantage of, but they want to avoid unnecessary work. So if those changes cause them to have to do work that doesn't matter, right? Like changing the name of a function from one thing to another is unnecessary work or having to remove parentheses where previously they were required is unnecessary work. And so Furry has this sort of set of requirements, but unfortunately they're all intentioned with one another, right? Because getting an update might imply that now you have to fix something that wasn't broken. But at the same time, you wanted the update. So what are you going to do? And in this talk, what we're going to do is essentially explore some of the ways in which these things manifest in Rust and what you can do to deal with them both proactively and retroactively. Okay. So that's the setup for the talk. I think these, you know, what I did now is essentially improvise those two slides and what I would say. I'd probably be a little bit more verbose, but like this is the kind of stuff that, that I would say here. And I think the slides fit that decently well. So they want to take advantage of better tooling, not necessarily language features. Yeah. I mean, you can think of it that way, although it's not necessarily tooling, right? Like they want to take advantage, for example, of, you know, the work that Mara did on making the standard library mutex is better, like more performant, basically, you would definitely want to take, like Furry would want to take advantage of this by virtue of updating to a newer version of Rust. That's not tooling, right? It's, but it's also not a new feature. Like it's not like it's const generics where, you know, it's a language level feature that you wouldn't use, but it is an update that they have to actively consume in order to take advantage of. But it's something you can think of this maybe as they want to passively take advantage, as opposed to actively take advantage. And that's a good point, actually, wants to take advantage of improvements passively. Okay, so now we get to the problems, the specific list of problems that Furry will encounter. I don't, this is the sort of, should we have a roadmap for the talk or not, but let's go through the kinds of things that we get up. And this is where the these tabs are going to come in handy. So one of them is new Rust versions, which bring additions, which bring new lints, which may bring deprecations, which may mean new minimal requirements. This is I'm sort of a dumping ground now, the slide is not actually going to look like this new crate versions, which might mean major version changes. It might mean minimum supported Rust version bumps. It might mean accidental breaking changes. Actually, another thing here is changes to unstable features. New performance characteristics. Yeah, so that's an interesting one, although I think it's relatively rare that a new crate version makes an existing call slower, more commonly what happens is they add an API that is higher performance, but the old API stays the same performance as it was dependency and compatibility. So that should come in the form of major version changes. Would security fit as well? I don't know if security is the thing that free will encounter, or maybe that's sort of a different point here, which is sort of disclosures, but not really even disclosures, but just like new information. So that might be security risks. That might be best practices. Arguably deprecations comes in this category too, but this is like, so this is new stuff in Rust, new stuff in the Rust ecosystem, and new stuff outside the Rust ecosystem, which if you look at sort of N diagrams, I think we've then covered everything, because it's Rust things. If this is the space of Rust things, there's Rust itself, and then there's not Rust itself, and then there's not Rust. One thing here might be tooling. I don't really know where that would go, because it's not necessarily a crate. It's like, I guess it's externalities. It's a fancy word. Security risks, big practices changes, tooling changes, this might also, this might include CVEs, but it also might include abandoned crates. Other externalities would be big changes to underlying tooling, or to underlying dependencies. So this might be things like open SSL going from 1.1 to 3.0. Externalities here means things that are external to the things that you normally care about, or know about, things outside the realm of your control. G-Lib C is up here, although I guess there could be big changes to G-Lib C, although usually you would only be exposed to that through new Rust versions. Okay. So let's cap it there for now. I think we could probably find more, but let's start with that. Keep in mind that, so I think this talks intended to be about 40 minutes long. Let me double check that I'm not lying to you. Yeah, around 40 minutes. So this is a lot of stuff to cover in 40 minutes. 40 minutes might seem like a very long time, but in practice, there's enough to say about each of these that we might not be able to get to all of them. But let's try. So the question is, how do we want to present this in terms of a roadmap, if at all? Yeah, one minute per slide on average is about right. If you're running out of time to say life's a mess, I'm sorry. Usually I'm pretty good to sticking on time, even though I improvise. And I think one of the reasons is because I usually time myself when I improvise and make sure that that, like when I practice, make sure that time fits the allotted time. And then in practice, when I actually give the presentation, I tend to talk faster than I do when I practice, just part of the adrenaline of the situation and stuff. And so even if I say more, I do it in time. And that's that on that. I wonder if the way we want to set this up is maybe we have these three top level bullet points. So maybe we make use of those. Maybe here we say, maybe here we say ways in which the world changes around free. This is a little bit long as a title. New versions of rust, new versions of crates, and changes beyond the rust ecosystem. Now, this is a pretty boring slide. It's a little bit helpful to me. It's not super helpful to the audience. How about just the world changes around free? And how about we do new versions of rust, new versions of crates. And it's not just new versions of crates either. It's also new crates. So I'm thinking of stuff like, you know, back in the day before CERTI, we had rust sea serialize. And everything that was doing serialization was working through rust sea serialize. And then sort of one day CERTI came along and rust sea serialize was just like not the thing people did anymore. Like that ecosystem sort of just died and the CERTI ecosystem came in instead. And or in error handling is another example of this where, you know, it used to be that there was error chain, and then there was failure. And then there was, I feel like there was another one in between there. And, you know, then we got anyhow and error and this error and there are a couple others in the space too. And it's not clear. Those are the end of the line either, right? For example, as we get the context trait into the standard library, that might be the thing that a lot of people rely on. We might see a new instance of crates that build on top of that API instead. Changes within the rust ecosystem. Yeah. Although it becomes a little too vague maybe. Well, one thing we could say is changes to rust itself changes to the changes to the rust crates and tooling and changes beyond the rust ecosystem changes to free is actually not a bad thought. It might be over time free changes what they care about. I think that's maybe beyond the scope here. But like the kind of things I'm thinking of here is like if free is not a person but a business, then one of the things that free might care about is to what extent can the people working on that rust project change over time, right? As people find new jobs or retire or get hired. That part of the process is something that's changing too. Like the people who are working on the software might change and their opinions on what good software is my change. I think that's beyond the scope of the talk. Like I just don't think we're going to have enough time to cover it. Changes to free. Though free pretends those don't happen. Claims. Changes to free. The second half is just a joke, but I want it to fit on one line. So we could do the world changes around free and I guess the way I would improvise this is something like. So one thing that's weird here is this slide ends with those who are intentioned with one another and that feels like a great way to start talking about how their intention with each other. But maybe I'll do that on that slide. I'll say something, but these are intentioned with one another. For example, getting new updates might mean that there's now work you have to do to get those updates which might be seen as unnecessary work because things already already worked the way that they were. In essence, the problem is that the world changes around free. There are changes to rust itself. There are changes to rust crates and tooling like new rust crates new versions come out or or even entirely new crates and create ecosystems develop or new tools come out that are the best in the business and the old ones end up getting abandoned. And there are changes beyond the rust ecosystem too. And all of those end up impacting free and in this talk we're going to go through some of the major points that occur in each of these categories and what free can do in response. Yeah, I think I like that. And then this slide we're not actually going to talk about. This is more for us to know the kinds of things that are coming up later. Okay, so now we have our obvious section things right changes to rust itself. New slide, new slide. This is changes to rust crates and tooling. And this is changes beyond the rust ecosystem. I don't love that these end up on multiple lines. I also don't really want to make the font smaller. How much smaller would it have to be rust ecosystem is a little shorter? How much smaller does it have to be to fit on one line? I can go to 41. So if we make this also 41. Why doesn't need the word rust in there? Because crates are already rust specific tooling feels like it's sort of separate. Maybe maybe this should just be changes to rust crates, or it could just be changes in the rust ecosystem. Because here, you know, this is just a sort of transition slide into the section. So it's okay if it's a little broad and vague, because we're about to talk about the specifics in there. This just has to be a milestone or a sort of yardstick almost for now we've gotten to the point in the talk, we're going to talk about these sorts of things. And then for oops, just for consistency, these are now the same. Okay, great. So within here, this is going to be big number, main point. I like that main point slide. We're definitely have some main point slides. But I don't know what they're going to be at. So we're going to delete it. All right, new slides. So in here, I do generally like slides like this. And the reason I like slides like this is because they force you to be very mindful of what words you put on the slide because you can fit so few. Also, they look cool. Okay, so what do we have up here? So for changes to rust itself, we have additions. And so what do I want to talk about for additions? So the reason I want to bring up additions is that again, keep in mind the audience here, right? The audience is people who are they may have written a decent amount of rust, but they haven't necessarily lived with rust for a long time. So they might be experienced programmers, but they're relatively young as far as rust goes. So they might actually not really know what additions are. In fact, many rust programmers don't really know what additions are, what their limitations are, what they're used for. And so I want to talk here about what are additions and how do they affect you? So this isn't so much a, you know, how do you guard against addition changes, but essentially telling people, you don't really need to worry about additions, right? This is one of those negative points in a sense, like as in negative, not as in the opposite of positive, but negative as in a negative space where this is a thing you might have thought you had to worry about, but you don't. And I think it's important to highlight those two because, you know, when someone comes into this talk, they might have their own preconceived notions about difficulties around rustability. And I don't just want to tell them about the things that are problems they might have to think about, but also the things that they might be concerned about that they don't need to be concerned about. And I think additions are one of those where, you know, the whole point of additions is that you don't need to think about them unless you very specifically want the things that come with the addition. Don't worry about them. It's sort of the message there. I don't know if the slide is actually going to end up saying that, but that's sort of where I want to get at with that. And here, like one of the reasons why I made this this kind of slide is because I don't actually want to go super deep on additions. That's not what this talk is about. I want to mention additions and essentially explain why you don't have to worry about them. Okay. New lints. So here, we come to the first point where, you know, in the abstract, one of the things I talk about is, I won't tell you the right way to set up the CI for your library crate. And this is one of those spaces where like new lints, I could talk for ages about things like deny warnings, but I don't really want to do that. Like, if you think of this as in terms of I have 40 minutes of budget, I don't want to spend, you know, 20 minutes of that, but like half my budget on talking about deny warnings is not worth it. Instead, I want to give people a sufficient warning of what happens if they deny warnings so that they're aware of the challenge involved. But it is one of those tensions, right? Where on the one hand, you kind of want to deny warnings, but on the other, there's a cost to doing so. Yeah. So for additions, what I want is a proof by contradiction, if you will. Yeah. It's not actually going to be as formal as a proof, but why additions are not important for for for free, right? For free when when when they're thinking about stability. So new lints, maybe it's not even lints. Maybe it's not even new lints. It's just lints, changes to lints, lints, lints. So here, you know, there's this tension between do you want to be told when there may be problems with your existing code or do you want your existing or do you want to be able to easily adopt new versions and not have the the friction, right? So maybe this is a it's like self-inflicted friction almost. Yeah, lints is a funny word. It's true. It's like it is sort of pick your poison, right? Where it's either let me upgrade automatically. And here I actually I need to establish a way to do this. Oh, I wonder, do they have clip art? I want clip art. I want no word art shape. I want, okay, here's what I'm after. I want a slide that tells a that looks like it's a sort of whisper from the sidelines from behind the curtain, like maybe there's hope. And so I almost want like a little like, you know, like faster than limes cool bear kind of like that, except a little less attitude and a little more sneaky. And I want to do it with as little work as possible, which is why I was looking for a shape. John barrier arguably should be a J. It should be like a a J in a trench coat that like lowers her glasses and goes like like a J that just like sneaks in from this from the side. I wish there was a clip art gallery. I don't want I guess search the web. What happens if I do sneaky or maybe maybe what I want is like, wow, those are awful. Well, how is this? Okay, that one's pretty good. Although ideally would be like a crab like a whispering crab. That's I don't even know what's going on here. Oh, you can't see it because of behind my face. It's whatever this is. But that's not that's not the picture I want. AI image generator isn't a bad idea, but I don't want to fiddle with one now. Whispering crab is what I'm going to search for and see what I can find. What about stealthy crab? That's disturbing. Or it could be like, no, like this one with like a little speech bubble. Hidden crab. These aren't very well hidden. These aren't hiding at all. These crabs are terrible at hiding. Okay, I guess hiding crab. That one's kind of stealthy, but it's not it's not clearly hiding enough. That's also pretty stealthy. Uh, you're right. AI generation would probably be able to make exactly what I wanted here. Hermit crab is actually not a bad idea here. Because they sort of they always just seem sneaky. Someone sent me this in chat. Which like, I mean, it's not entirely wrong, but I want it to be like sneaky rather than cool. Mmm. That is a pretty great picture of a crab though. Just has a lot of attitude. Ooh, with rusty colors. Mmm. Like I want something where this is like a crab that just like barely sticks out of its shell. Like maybe that one. The reason I'm actually looking for this is because um, I have a feeling there's going to be multiple of this throughout the presentation. As I want to just like establish the one I'm going to use. How about this? Commercial use with modification. Pixabay. Uh, free pictures to download and use in your next project. Okay, but how do I like what I was thinking here is actually almost like one that that looks towards the future. Kabutops is a pretty good recommendation too. But I think I like this one actually. Can I Arguably I want this as the background almost. Yeah, I think that's actually what I want instead. So undo that and then I want to do change background image. Google images. I heard crab kind of wanted to face the other way, but it was a little bit more context here actually. So one, one thing that we haven't really touched upon yet is even though for you want stability, that doesn't mean that their code is done, right? They're probably still doing some, some implementation work on it. And so they might want deny warnings to make sure that new code they write don't trigger lints, right? Because they might not want to go back and change all their old code, but for new code they write, they want to make sure at the very least it meets the lints that they already have, which is something that arguably we've failed at in the setup here. So there's arguably another point that's missing here, which is to like incrementally add to their code. Their code is still changing, but only small parts of it. So arguably there's a point here of like for ease code is changing. But I think we can do that in the setup. The reason this matters is because not so much for additions, but for lints. It means that you might actually want deny warnings regardless. So it's not just let me know if my code is bad. Well, I guess it is sort of that. But so it's not just like new lints that might tell you things that are broken about your old code, but it's also to catch known problems with new code. So here it's both new lints on existing code and old lints on new code. Or I guess existing lints on new code particular rust version. So this is one of the things that I think would be really cool is if you have the ability to I want this to be a little more padded. If you have the ability to say not just deny warnings, but actually say deny warnings as of rust 166, right? Because it would mean that you can continue to write new code. And if a new version of rust comes along and gets released, then you can automatically adopt it because even though it might have new lints, those lints won't apply to you until you choose to apply them. So this is one of the things that I hope that rust will get. And that's sort of what this kind of slide I'm intending to be used for, right? And you can, you can see the picture sort of works here, right? Where you can sort of imagine that this crab is thinking this. This crab is sitting there in a shell looking out of the beach and going, what if, right? I think that works. I think that works. I think I'm happy with that. Okay. So a new slide is going to be back to this one. What else do we have for new rust versions? Deprecations. I'm not sure yet whether I want to talk about deprecations. It might not be worth the time because it is true that deprecations are things you will see, but at least for the standard library, so like new rust versions, deprecations aren't going to hit you except when you change additions. That's when they actually get removed and additions, as we've already talked about, don't matter. So maybe this is just like a PS also means deprecations are fine. New minimal requirements. So this one is going to be what's the short version of this? It's like platform, but what's a better way to frame that? I'm thinking of things like this blog post from earlier, I guess it's last year. It was the end of last year where rust increased its minimal supported version of the Linux kernel and of G-Lib C, which means that if imagine you were running on something that was using an older kernel than this, then trying to upgrade to 164 would break not because there was a breaking change in the language, but because it just no longer supports the thing you run on. And so this is an example of a new rust version messing you up without it being because of the stability of the language. So maybe this is requirements. And the way we've used the subtitle here is as a guide for how to think about it, right? So for additions, don't worry about them. For lints, pick your poison. For requirements, this is almost like, okay, so there's a part of me here that goes, I don't feel sorry for you. In at least the cases we've seen so far, so this is stuff like for, there's recently been talk of bumping the rust supported Android version, they're probably going to do the same for iOS. They're probably going to do the same for Windows if they haven't already of just like, you know, something like Windows XP. It's just very old, right? Like the support matrix for versions that Rust supports, you can't just support like Windows 95 forever. It would mean that Rust has to stick to such a, it basically means you can't take advantage of new features as they come out or it becomes a lot harder and you keep growing the complexity of the internals of the language to a point where it's not reasonable anymore. And it gets harder and harder to do things like test on. So they're good reasons why Rust bumps these requirements, but they tend to bump them fairly conservatively. So for this G-Lib C and Linux kernel, I think the change here was something like things that were last released like 10 years ago or something. I forget, I think they listed this somewhere in the article, but I can't remember now. So it's not as though you need to update every year, but it's rather you can't stagnate. And there are other reasons why you shouldn't stagnate, right? Like you don't want to be running on operating systems that aren't supported anymore because you're going to run into problems that are not even related to Rust. Like you're going to have very old outdated software completely independently of Rust. At the same time, there are cases where you don't really have a choice, right? Like if you're writing software in Rust for let's say like a hardware switch or a router, then that might just be running like Linux kernel version 2.6 and you can't upgrade it. Like it's not software you control. Like you would need an update from the vendor and the vendor might be like, sorry, we don't update for that anymore, but you have physical hardware you're working with. So you want to develop new stuff. And so you don't have the option to upgrade because you don't control the software. And in that case, you know, you just can't upgrade your Rust version. So here, the advice is in some sense upgrade if you can. But what's the advice if you can't upgrade? I guess there isn't really one, right? So I guess this is a, it's not really keep up as much as it is don't fall behind LTS. And so LTS here is long-term support. And one of the arguments for why it was okay to bump G-Lipsy and Linux, the Linux kernel was because the versions were previously targeted were at that point no longer supported by the vendors of those platforms. So I think one of the oldest ones here is Red Hat Linux or Red Hat Enterprise Linux where RHEL 6 is just no longer support. Well, I guess out of the distributions on the list like Ubuntu 12 would no longer be supported Debian 6. I forget what SL secure Linux. Those are no longer under LTS even. They're no longer supported platforms by their vendors. RHEL 6 I think technically is, but it's under like a limited vendor support program. So it's basically on live support and is going away. So that's why I always argued that it's okay for us to cut them because even the vendors of those platforms have cut them. So why should we commit to a longer support cycle than the owners of the platforms? And so that's why the requirement here is basically don't fall behind LTS for your platforms. So as long as that's the case, you should be fine with the requirements of Rust because in general they're not going to bump things beyond what that LTS is. But there is debate here too, right? Like for Android, for example, for the NDK and SDK, I forget exactly what the support policy is, but I think it's basically we only support the latest version. And so there is no LTS to not fall behind. You have to not fall behind the latest version, which means you always have to stay on the latest version, which is clearly also not sustainable. So maybe this is the thing to point out, not always easy. Some platforms have no LTS. Rust included, right? So there is no long-term support version of Rust, at least for the time being. And it's funny, I looked back at the stability as the deliverable article, which was written before Rust 1.0. So back in 2014. And one of the points here was, oh, maybe I'm lying. Maybe it was Rust 2018? Yeah, when they announced Rust 2018. So I'm lying. It's not back for 1.0. But when they first started talking about having Rust editions, the blog post they wrote about it says, the Rust project currently only supports the most recent version of the stable compiler. Some have wondered if the concept of an edition ties into some form of long-term support. It does not. However, we've been talking about introducing some sort of LTS policy and may do so in the future. As far as I'm aware, that's not a thing that's currently being debated. Part of the challenge is it's not that no one wants it, right? I think there's desire from people using Rust to have a long-term support version of Rust. The challenge is Rust as a language is maintained by essentially volunteers. You know, there are some people who are being paid to work either part-time or full-time on Rust, but on the whole, the project scales with volunteer time. And long-term support is sort of the opposite of volunteering. It is saying someone needs to be paid to get things to continue to work even after like just for a very long period of time where it's not exciting work. It is just like backporting and making sure some old thing continues. So it's a thing that most people wouldn't do for the fun of it. Android and Rust itself. I'm not writing the bullet points for these yet because I want to get the sort of whole structure first. Other than regressions, why aren't people using newer Rust versions? There are a couple of them. I think requirements is one. Lynx is probably another. Sometimes it's actually, they use whatever is installed on their platform. So like they do, they don't use Rust up. They use like apt-get install Rust. And that doesn't give you Rust 166. Right? Depending on your platform, that gives you, I forget what Debian is now, but like on Ubuntu, I think it currently gives you 164 or something. So it's more a matter of you're using what your platform provides because you know that works with everything else your platform provides. And you don't go out of your way to get a new version. So that's the reason. Like you know it's very easy as an individual developer to just run Rust up update locally. But you know if you're an enterprise deploying Rust software, that's not how you use any programming language or any piece of tooling is not update on the day. It is there's a whole supply chain that has to get you a new version and it doesn't move super quickly. And this also gets back to you know who's the audience for this talk. Where as I mentioned, I think there is a separate talk here to give to people who maintain Rust libraries and other kinds of crates to try to explain to them look, these are the reasons why the minimal Rust version you support matters and why people might be behind, but that's not this talk. This talk is focused on the people who are using Rust in stable environments, what kind of things they might run into from Rust on the ecosystem. Python two to three required a lot of work that should not be desirable in software upgrades. That's true. That was a big lift at the same time. You know, I wonder actually if you know it's very easy for us to say you know right now we're not going to do another major version. The question is 10 years from now are we going to feel the same way? Are we going to have to have built up so many things that we really just want to like we need a clean break? I don't think that's going to be the case. And the reason for that is partially because of the sort of how cemented that opinion is in the ecosystem. A part of it is that Rust is never runtime, which means that the space in which you might want to break guarantees is a little smaller. And the other is additions. Like additions lets us do many of the things that you might want to do a breaking language change for anyway in a way that isn't breaking. And so I think that helps as well. How does that work at AWS if you can talk about it? So this is the bringing in versions of Rust. How much can I say about this? At AWS in general, Rust is just built from source as any other package in the like giant internal build system that we have. And so as new versions of Rust come out, we build those new versions in like we import and build that version of Rust. And then we deploy it throughout the company. So in general, AWS is fairly up to date. And the question is just like, how long does it take everyone to adopt the changes as they get pushed out and deploy things and stuff? But in general, it's pretty up to date. Okay, what else do we have? Changes to unstable features. Ah, yes, this is its own. So this is, I guess, this is arguably about nightly. Inherently unstable is really the takeaway here, right? So if you choose to use nightly, and this is where the thing I want to talk about on this slide is stuff like, you know, why are unstable features marked as unstable features? Why can you only use them on nightly? Well, it's because they might change. That's the whole point. There's also the fact that they might be incomplete or incorrect, right? But the primary reason why they're on nightly and why their mark does, why they're named unstable features is because they're not done. And so they might change. And as a result, if you put them in stable rust, that would mean that you're not allowed to change them because it would break the stability guarantees of rust and people wouldn't be able to upgrade. So by virtue of using an unstable feature, you're saying, I'm willing for this thing to change under me. And if it changes, your code is not going to build anymore. So there's just like a fundamental choice here. And you can argue about, well, some features have been around for long enough that we think it's unlikely that they're going to change and therefore we're willing to depend on them. But like, it's a risky proposition to say that this thing has been around for a long time, so it's probably not going to change. Yeah, it's like you're on your own is sort of the take here. But what I want to communicate in the talk about use of nightly and use of unstable features is you're making an active choice that you don't want stability or at least in some subset, right? Of using an unstable feature, you're saying that you're willing to be broken. Sometimes you don't have a choice. Sometimes you just have to use an unstable feature. It should be very rare. Usually you can work around it by writing a bit more code or changing your design slightly or using some unsafe and you don't actually have to. It's just you want to and so therefore you make it out in your brain to I have to. But really, you didn't have to. It was just less work, less pain. Okay, so nightly is inherently unstable. So we'll write some points about that. That's easy enough. And I think that's all under a new Rust version. So let's now move this guide down to here and then stick in a new slide here. That's going to be one of these folks. So for new crate versions, it's not a very furry thing to do. It's true. Choosing nightly is not a very furry thing to do. Furry would not choose nightly. Let's be honest. Furry likes stability too much. Okay, so here it's there are a couple of different things I want to touch on here. The first one is new versions. Then I want to talk about major versions. Because again, you know, if if you're very well versed in Rust, then you know the difference between a new release of a crate and a new major version of a crate. But if you're coming from other languages, if you're coming from no JS or from Python, where semantic versioning is not as ingrained in developers and in the package manager and such, you might not know that there's a pretty serious distinction between these. You know, if you're in the Python ecosystem or the Node.js ecosystem, then upgrading a dependency is actually kind of risky because they might have a breaking change in there, even though only a minor version changed. Or there might be a change to a new major version. There are no breaking changes. It was just, they just seemed that seemed the right at the time or they have the major version is just the current date like year month day. And so the major version changes every time. That's just how they do releases. And so for people who are in that category where they're not intimately familiar with just how ingrained semantic versioning is and how we think about Rust crates actually explaining the fact that new versions not a problem. And there's a caveat here around accidental breaking changes and semantic changes in particular. But in general, new versions are not a problem. There's also you'll get them automatically automatically modulo cargo.lock checked in. Major versions though, require intentional or require manual effort. And here, you know, we can mention things like cargo outdated and we can mention dependabot. We can mention changelog files. And here too, you know, if this were a talk geared at crate authors, the kind of things I would talk about would be very different. It's like, how do you choose whether to cut a new major version? Whether it's worth the effort? How do you decide when something needs to be a major version, even though it feels like a minor version, I might talk about things like private versus public dependencies, which might mean that what feel what seems like it should be a minor version upgrade is actually a major version upgrade because you upgraded the major version of a dependency that happens to appear in your public API. But in this, you know, this angle of the, the, the topic, those aren't important because all that matters is what you observe. And here, another thing that I actually want to touch on is when breaking changes, don't break you, which is basically if you can rebuild the world. So my thinking here is if you can rebuild the world, like for, you know, many of the big tech companies, for example, have this property of if you're bringing in, if you're bringing in a new version of something, you can actually just rebuild all of the software at that company or at least some substantial portion of it. And you can just see whether it breaks. It doesn't matter whether something is labeled as a major version upgrade. If all of your software still builds and all the tests still run and all the performance profiles still work, then it's not a breaking change. Even if it might have technically been a breaking change, it didn't break you. And I think this is, you know, from Faris standpoint, this is important to know because it means that if you have that capability, it means you can ignore this problem. They might still hit you. It might be that there's a major change that or major version bump that does actually, you know, break your build or break your build or break your tests, in which case you have to go deal with it. But it means you can worry a little bit less about things like major version upgrades. Basically crater, yeah, it's the equivalent to having an internal version of crater, except that you're not doing crater runs to see whether you're bringing in new version. You just do it and see if, and if it works, it's done. And tests are important bit here, right? Because, because sometimes a crate cuts a new major version, not because the API changed, but because the semantics of the API changed. And when that happens, builds might work just fine because the code, the API, the shape of the API didn't change. So everything still compiles just fine, everything type checks. But when you run it, you actually get slightly different semantics than when you got before. And this is where rebuilding the world might not be sufficient. It's only sufficient if you actually have a decent amount of infrastructure for doing unit tests, integration tests, and ideally like beta, you know, deploy to beta and have something that tests there so that it's, it's like a full test of your entire system. Because otherwise, it just building isn't good enough. So that's something we're going to want to touch on here. New versions here is a little misleading. It should say new minor versions. Maybe cargo update, actually. What else did we have for this? Ah, MSRV. How am I going to, I guess I can write it out. Minimum supported rust version. So the challenge here is sometimes crates decide to make use of, and this happens pretty aggressively in the Rust community, crates decide to make use of new language features as new versions of Rust come out with the general expectation that people tend to upgrade their Rust compiler over time. And the challenge here for Pharee is that if a crate that they use now requires Rust 164, but Pharee was building their software with 163, Pharee's build stops working even though nothing in Pharee's code changed. But it's because they wanted to update their dependencies. The minor update should be fine. But then it breaks because they don't have a new enough version of Rust. And, you know, there's an interesting observation here on, is it lib.rs or is it libs.rs, lib.rs, under stats at the bottom here. It's a pretty cool graph of Rust C compatibility, which looks at for all crates and for the 4,000 most recently updated crates, which versions of Rust do they still work with? If you look at the most recently updated crates, and we look at only things that are okay, you know, 50%, somewhere around here. So if you want to work with 50% of the most recently updated crates, you need Rust 163 or higher, which is a very recent version of Rust. You know, down here you're at, what, 46%. So only a third of the most recently updated crates support versions as old as 159. And what's interesting here, too, is you can see these like jumps around addition boundaries and particular features stabilizing. For all crates, you know, the numbers are slightly better, but even so, you know, 50% compatible is somewhere around Rust 146. I forget what Debian is, but I think it's like 148. So here, too, it's like, you can't really be that out of date. You're going to have a bad time because crate authors tend to adopt new Rust language features, which is understandable, too, right? Like they want to make their code better, which means they want to take advantage of new features in the language. But it doesn't, it's problematic. Oh, as a, yeah, you're not wrong, MSRB. So there's a, this is really just saying, like update your Rust version, right? That, that's really the advice here. And, and I'm not claiming that that's easy, but I'm claiming that if Farid wants to update their dependencies, they must also update their Rust version, which means that they should do what they can to make sure that they can update their Rust version, which ties back to things like what do you do about lints, right? If you choose to have deny warnings, then you don't get to automatically update your Rust version, which means your Rust version will fall behind, which means you won't be able to run cargo update because you'll be broken by MSRB. So, so all of these things sort of tie together, right? And this is, let's see, so automate updating Rust. And maybe this is automate updating Rust. So this is going to be, if you fall behind, you can't cargo update. Even by, you know, based on this, even if you fall behind by five versions. So what's five versions times six weeks, right? Six weeks release cadence. Let's say four versions, right? Why am I doing six times? Well, 24 weeks, which is like half a year, right? There are 52 weeks in a year. So even by four versions, so six months, you often can't cargo update ties into deny warnings, which may prevent automatic updates. And here, too, again, talking about, you know, who is the audience for, we could talk a lot about how crates should choose, which MSRB they should use, how they should enforce it over time, should you run your tests, should you not, should you just check that it compiles. But also things like what prevents people from upgrading. But from the point of view of this talk, it doesn't matter. What matters is that for free, who has these wants and needs, this is the thing that they have to think about. And they have to take actions like automatically updating in order to maintain the level of stability that they want. There's also stuff around, you know, there's been proposals to add awareness of MSRB to cargo's resolver. One challenge there is that doesn't actually solve the problem, right? Because what that would mean is cargo would choose an older version in order to stay compatible with the version of Rust that you're using. But that means you don't get updates, because it's going to choose an old version. And it's not going to choose the newer versions, which means you don't get the updates. So it doesn't actually solve the problem. It just means that you don't have to manage lock files. So I guess here, another thing to point out is, if you don't update, need to need to check in cargo.lock. And where the MSRB aware cargo resolver comes in is, if you didn't check in your cargo.lock, when you had a machine that an old version of Rust, then it becomes really annoying to try to construct a cargo.lock after the fact that works with your MSRB. That's where the problems come in. But that's a narrow thing to solve. Generating MSRB compatible cargo.lock after the fact is hard. So here we could put the thinking crab and be like, you know, wouldn't it be nice if cargo was MSRB aware? But again, it doesn't actually solve any of the problems that free might have. Is it possible to change compilation depending on the Rust C version? Not at the moment. So there's a proposal to add two features to the Rust compiler. One of them is the ability to conditionally compile based on the Rust version. And the other is to conditionally compile based on whether a given path as in path to a type or a method is available. So you can say something like if the method foo on the type bar in the standard library is available, then compile this code, otherwise compile this code. Which is more like feature detection. If you compare this to the web world, this is the difference between browser sniffing and feature detection. Where version detecting Rust C versus detecting whether the feature you actually needed was available are two different ways to go at it. And in general, the accessible conditional compilation feature is the thing we're looking for here, is the preferred way to go. But it's also quite complicated to get right, which is one of the reasons we don't have it yet. Of course, you can do this with build scripts. So there are a bunch of crates that do this already where you have like a build.rs that runs Rust C to see which version of Rust you're using and then emits conditional compilation flags based on which version of Rust you used so that you conditionally compile code based on that version. You can specifically call out the Rust itself is still major version one and tie that somewhat back to the discussion between major and minor version for create dependencies. So that would probably be, where would that even be though, additions maybe? I guess I can just mention it here, right to say Rust is major version one and will for now always be. I love that phrasing and will for now always be. And then accidental breaking changes. So this is going to be about, I suppose, it could be regressions arguably, but it's more like human error. And I think realistically, this is test, don't just compile, sort of. I'm trying to figure out prevents updates. I'm torn about what I want to talk about here because there's sort of two areas to mention here. One is what happens if a breaking change happened in a minor version update. And the second is how do you detect that there was a breaking change that wasn't visible in whether or not something built. And for the latter, it's like, you got to test and not just compile. But I think the more important one is when something is a breaking change, but wasn't the major version upgrade, like what do you do? What do you do? You tell the maintainer and then you specify in cargo tumble, you know, less than the affected version. So human error is like a weird way to phrase this, right? It's really accidental breakage. And I think test, don't just compile is more of a side note I want to make. And the main takeaway is breakage. And I think the main takeaway instead is I guess it's like this is a retroactive kind of thing where you don't really want to guard yourself against accidental breakage proactively, right? So the way you would do that proactively is you would say, you know, if I take a dependency on clap, you know, 4.0, instead of specifying clap equals 4.0, I would do like 4 comma less than or equal to 4.0.22, right? That's the way I would proactively prevent this, which is to say, I know the 4022 works and I'm not willing to take any newer version because there might be accidental breakage. So that is one way to go about things, but we don't want to recommend that people do this because in general, they're not, there's not going to be accidental breakage and you want to keep updating. And you would rather do this by checking in your log file and then periodically running cargo update. Definitely automate cargo dot update. So instead, I think rare and a bug. So what I want to stress here is that if there is accidental breakage, like if you detect that that's accidental breakage, you should treat that as a bug. Like that is a bug in the crate adherence to semantic versioning and therefore you should file it as a bug upstream and then it should get fixed. It's not something that you should patch your way around, especially not long term. If you do have to patch it in the short term, then you do that by specifying in cargo to Tamil. But but I want to instill into into free that it's a bug if this happens and you should treat it as such. And like bugs can happen, treat it as a bug changes beyond the rust ecosystem. This is going to go back to this layout. All right, by a break time. We're back in a second. All right, let's see. Oh, why does it says that YouTube disconnected? Why can I not see YouTube chat anymore? That makes me sad. YouTube live chat not found. Let me see if I can hum hum hum. Claims that it's working on YouTube. Oh, yeah, there's been lots of stuff in YouTube chat that I haven't seen. For some reason, my chat synchronization thing seems to have broken with YouTube. Let me read through what people have written. Let's see. This is contained spoilers. Yeah, this definitely has spoilers for the talk. I'm from a town called Linz and it's super funny when you say Linz all the time. That is funny. I can see that. Can a new minimal version be seen as maturing? Is that question for minimum supported rust versions? It is true that, well, not really. I think picking up new minimum supported rust versions is a pretty natural thing as a crate evolves. I think it's totally reasonable for crate authors to want to make use of newer versions of rust. It's more that as a consumer of rust and of the rust ecosystem, it's something you need to be aware of because otherwise it's going to hit you out of left field. Oh, SLES is SUSE Linux Enterprise Server. The version of rust in Debian 10 is 1.41.1. That's way older than the LibrarS. So 1.41.1, so it's down here. Then you get compatibility with about 40% of rust crates. I don't know why it cut off. I wonder if I do this, what happens now? Interesting. Poor YouTube. Is it still streaming, though? It's the next question. It claims that it's still streaming, but I can't see it still streaming. Interesting. Well, YouTubers, okay, it claims the word live. So YouTube can still see me. It's just that the chat doesn't show up. So if I say hello here, it's going to not go to YouTube because the connection is in an error state. Well, so for YouTube chat, I'll try to Ah, that's not where I wanted that. I want to move this over here. Okay, I now have two chat windows open on my other monitor. So I'll, I guess that means I can keep up with both of them. That does mean YouTube chat. You're also not seeing Twitch chat and and vice versa. So you can all be sad about that. I wonder, wish there was a way for me to just tell it to like retry establishing the connection, but it just seems like it doesn't want to. Oh, well. Okay, so let's continue. Changes beyond Rust ecosystem. Okay, so this is going to be things like security disclosures. And I guess we could shorten that by CVs. And the question becomes, what's the recommended action here? Because obviously, there are a couple of different ones. There's stuff like, you know, just make sure you keep automatic updates. So this ties back to the cargo update bit. There's also make sure you regularly run tools like, you know, cargo audit or whatever that that check your dependency closures against known problems. But I feel like there are other issues here too, like, you know, there might be a CV against the Rust standard library for the version that you're using as you need some way to be notified of that. There might be CVs in non-Rust dependencies of your Rust dependencies. So for example, imagine that there's a CV in curl, you know, like the C library curl, then the Rust crate curl arguably needs to be updated to make sure it reflects the newest version of curl that it binds against. And that might include breaking changes. It could be things like with, you know, Libgit 2 where then you have to cut a new, like potentially major version of that crate, which means everyone transitively has to update. But what's the advice here? It could be that this is just like a not a good point. Like, these aren't things that cause instability for free, really. And maybe this is just not a point about stability and when we can ignore. But abandoned crates, I think it is. So this would be, although abandonment is arguably something that falls under changes in Rust ecosystem, right? Abandonment is just a severe word, right? So this is free, took a dependency on the failure crate back in the day. And now failure is no longer maintained. It's no longer recommended. It's a thing you shouldn't use anymore. And I think there's a combination of things here, right? So there's both the proactive step of don't take dependencies that seem at risk for abandonment, such as few maintainers and contributors. Oh, actually, for major versions here, I also want to talk about the proactive steps of this, which is take 1.0 dependencies, or maybe phrasing it differently, avoid 0.x dependencies. And also avoid dependencies that require unstable features. So the reactive part of this, right, is to sort of evaluate importance of said crate. It could be that a dependency used has been abandoned, but it's such a simple dependency that doesn't really matter. It's okay for it to be abandoned. It's not a thing that you expect to really require any ongoing maintenance. And so if it's abandoned, it's not worth going through the effort of trying to get rid of your use of it. In other cases, it's like you actually do want to move because the entire ecosystem is moving. The move from rusty serialized to sturdy is an example of that, where you almost certainly will want to take on the work, even if it's substantial, to move along with that abandonment or abandon along with the rest of the ecosystem. And one challenge here, right, is that unlike accidental breakage, which is relatively rare, abandonment is less rare and also more subtle. It's a little harder to detect that something has been abandoned or is effectively un-maintained because you can't necessarily tell, right? You can't necessarily tell the difference between that and a crate that's just very stable. And so it doesn't really need changes. It doesn't need new versions. Look at our crate like Autoconfig. This is the auto CFG crate. I think it only has two versions. It has 1.0.0 and 1.0.1, and it's just a very stable crate because it doesn't do that much, but it's very widely dependent on and it's maintained by Josh Stone by CU Viper. So it is maintained, but it's hard to tell that it is because it doesn't really see a lot of motion, which would otherwise indicate that the crate is otherwise healthy and active. So this is a question of like, how do you detect that this happened? Are you really cargo audit as part of this? I believe there's a way to file like rusts like advisories for crates being un-maintained. I'm trying to figure out what the recommendation here is. And to be clear, and I wanted to stress this in the, arguably this is something I want to stress like very early on in the talk, or maybe it's actually a conclusion kind of thing, where if I do like new slide down at the bottom and I make that be this one. And so for this final point, I do want to make sure that I clarify, well, I don't, what I want to say, right, is that some of these don't have correct answers, advice, but not necessarily correct answers. I want to make sure that that's clear to the audience, because for some of these, the answer is you just got to choose. It sucks, but you got to choose. And for things like abandonment, it might be that the advice is do what you can proactively to ensure that this doesn't happen. And if it does happen, evaluate the impact and decide what to do. And that there isn't really a piece of like, you know, you don't have to worry about this kind of thing. So maybe be selective, first be selective, later do the work. So the reason I write it this way is because it's very easy to decide that you're not going to care about something being abandoned. And you're just, your thing works, you're just going to keep working on it. You're going to keep the code the way it is. And I think that's usually a mistake. There are cases where it isn't, but usually it's worth investing the time to get out of of abandoned dependencies. But it's not necessarily work that you need to prioritize highly, but it is work that you should do. I think would be my advice here, because otherwise you run into things like, you know, down the line, a CVE is discovered for this particular crate. And so now what do you do? It's not going to get fixed. So now you need to quickly move to something else. And that's not great. And decide priority for moving. Remember, CVs may require quick motion, quick movement, quick migration. Okay, so then back to changes beyond Rust ecosystem. So I think CVs were not really going to talk about here. Abandoned crates we talked about before. Other security risks, you know, they do affect your stability in that you have to, basically, you have to keep updating whether that's Rust or crate. So I guess there is a sort of security as a process. Security is not a goal, it's a process. And then we could say automate updates. Like that is the, by far, the best advice I can give there, right? Where there is risk to automatic updating too, because it could be that the update is what induces a security risk. But at the same time, in general, having automated processes for keeping yourself up to date is going to make everything a lot nicer. Best practice changes. Oh, I guess I should name this. Living in the Rust long term. Yeah, great. Thanks. I'm trying to think what best practice changes would mean in practice. So, you know, what kind of best practice changes would actually require or would be convincing enough that for we would argue for we should go through all our 100,000 lines of code and update them. There aren't many, right? Usually if there's a best practice change, it's not worth going back and changing all of that stuff. Are there any where it would be worth it? I'm trying to think of things like NLL, like non-lexical lifetimes. Now, that was a thing where it could, it would probably let you remove a bunch of fairly ugly hacks in your code. And often those hacks would include unsafe. And so it's, it would be worth going back and fixing them. But, and arguably, you know, Rust best practices aren't beyond the Rust ecosystem either. Maybe this isn't changes beyond Rust ecosystem. Maybe this is changes beyond the code. It's a little bit of a weird category. Right? Because it is an interesting point that I think somewhere we'll want to mention the fact that if new features can let you remove unsafe from your code base, it's worth doing. It's true. It is more about dealing with technical debt more broadly. But at the same time, I think, you know, I think that is part of wanting stability is managing technical debt. And I think what we're, what I'm trying to get out with this part of the presentation is, are there, is there Rust specific advice that we can give around technical debt? That's sort of what this gets at, right? As an example, in Rust, technical debt that involves on safe is more worthwhile to address than other technical debt, right? If, if, you know, let's say when the module system changes landed in Rust in the 2018 edition, right? So it's a change how you could arrange modules with, or what file names modules were allowed to have. That's a change where, you know, you might have technical debt in that your module hierarchy might have been a little more convoluted than it needed to be because you didn't have those changes, but it's probably not worth going back and fixing. But if a, if a new change in the Rust, in Rust allows you to get rid of some unsafe from your code base, it is probably actually worth doing, or rather it's more worthwhile doing the many other kinds of retroactive changes. Safe transmute is another good example. Yeah. So maybe actually this is a, maybe this goes here, maybe this goes under changes to Rust itself. So maybe this is something like unsafe is costly. But also remember, it's not, it's not really technical debt, right? It's not, you made a poor choice at the time. And now you're sort of paying interest on that poor choice constantly, and you should go back and clean it up. This is, you did things in the only way you could at the time, but now there's a better way to do it, which is not, you know, the traditional meaning of technical debt. And I think unsafe is actually a, is actually the specific thing I want to call out here because I do think it's special. So how do I want to frame this? Maybe eagerly adopt unsafe reduction. And rather than unsafe is costly, this is new features. So I almost want to say this, right? That new features that come as part of new Rust releases, you can generally ignore, right? Like you can make advantage, you can take advantage of them. That's fine, but you can generally ignore the fact that there are new Rust versions. The improvements you're going to see are going to be automatic, hopefully, but you should eagerly adopt unsafe reductions, I think is worth calling out here. But this changes beyond Rust's ecosystem is still pretty weird because even security is a process, right? It is really more about Rust than about crates than it is about stuff beyond Rust. Like this is an important and valid point, but it's sort of independent of everything that we've talked about. So I think I want to delete this. And maybe we end up deleting the section. I'm not sure yet. See what the next point here is. Tooling changes. So here I was thinking of things like improvements to cargo audit improvements to cargo deny, improvements to clippy improvement, well, less so improvements to clippy, but improvements to myri, improvements to loom improvements to address sanitizer and thread sanitizer, improvements to Valgrind, potentially, or Valgrind. Also not really necessarily beyond Rust ecosystem, right? Because some of those are Rust things. They're really tooling specific. And I also don't even really know what the advice is there, right? Like, you know, if if myri gets better and catches a bug in your code, then you go fix that bug. Like, it's not, the advice here is not particularly interesting or unintuitive. So maybe there's not really much to say. Big changes to underlying dependencies like open SSL. There is a category here of things where I've seen this. It doesn't happen very often, but it does happen somewhat regularly is that there are changes to usually libraries, sometimes command line tools, but usually libraries outside of Rust, like open SSL, for example, or like Libgit 2 or Libs H2, and the Rust crates that bind to those libraries need to be updated in order to work with the newer versions. But A, it's pretty rare. And B, if it happens, it's sort of clear what you have to do, right? Like that crate just needs to be updated, and then you need to take that update. So maybe, maybe we actually don't even want the section in which case, you know, that sort of pulls into question, well, should this point even be here? I guess, you know, changes beyond the Rust ecosystem is also stuff like new versions of the kernel keep coming out and, you know, OS distros stop or go out of long-term support and stuff. And when that happens, you know, that's, that's one of the reasons why the Rust project increases the requirements. So it's okay for this list to talk about things that don't map directly to the later list. The way it's currently structured, it feels like there should be a third section. So we sort of need to break that symmetry between the items in this list and the sections, or we need to get rid of this one because we're not going to talk about it. And if we do remove this point, then the slide is sort of pointless, right? Or rather, it makes a very, very minor point. If we look through, is there another categorizations of these, you know, requirements could go into that, the world outside Rust changes. But the way it manifests is you try to upgrade Rust and that new version of Rust doesn't run for you anymore. Change the Rust ecosystem. Hmm, I'm torn here. Basically, I don't feel like there is meaningful advice we could give in this category. Or rather, there's not meaningful advice. There's not meaningful Rust specific advice we could give in this category. So I think this should then go away. And if that goes away, then this has to change. And it could change, you know, this is the roadmap. So one way in which this could change is that we do something like this and say instead of a percentage number say, basically say that this talk is going to be split in two. Soft remains as usual. Yeah. It could be that instead of trying to outline a roadmap, we're just going to say this, this talk has two parts. It's about what Rust itself changes. And it's when the stuff that built on top of Rust changes. So we could do like two areas of concern. But it feels a little hollow. Does for me, this slide just feels weird, man. I don't know how to structure this. Because I do think I want a slide that transitions from this to, you know, diving straight into here. The question is what is that transition? Oh, hey, teach. Maybe you know, maybe it's just something like this, right? Of what is free to do? And then I could even say something like, well, free needs to free needs to think through. It's like think through different cases and decide what their, what their plan is. But that feels weird for that to have a slide or even for me to say anything. I guess let's see. So the end of the slide is that these are in tension with one another. Ultimately, maybe actually maybe this is just, uh, so let's look, let's look into those tensions and just get rid of this slide entirely. Look into those tensions sounds weird, but, but that's sort of what I'm getting at, right? Is that these are in tension with one another. That's sort of the setup for the talk. And we say, now we're going to look at those tensions. And there are two primary categories that are changes to run itself. And then there are changes to the rust ecosystem. And we'll look at each one of those in turn. I think that's okay. I don't love the, yeah, let's explore tension. What tension manifests in two main areas, rust itself and the rust ecosystem. Let's explore each in turn. I think that's all the transition we need actually. And so my guess here is that the setup here is going to take about five minutes. I think it's going to take about five minutes to get from here to here, just because, you know, it doesn't seem like very much text, but there's going to be a little bit more that I say here. And there's also going to be here a decent amount more to sort of flesh out in these bullet points. Yeah. So one proposal here is that we could recategorize this, right? So instead of going by where does the tension appear? It could go by what is the recommendation? Like things you do need to think about, things you don't need to think about, and things you may need to think more carefully about. Right? So in the things you need to think about bucket would go things like lints, requirements, unstable features, major versions, and abandonment maybe. Things you don't need to think about are things like additions, cargo update, accidental breakage mostly, and things you need to consider are the remainder. One reason I don't love breaking it up that way is because for the audience watching, it means that we're going to jump back and forth between talking about crates and talking about rust of the language. It also means that there's like a section of the talk that you'll want to pay attention to, which is things you need to think about. And then if the headline of the next section is things you don't have to care about, then you might just tune out even though the reasons why you don't have to think about them are actually important. I as the presenter, I'm telling you you don't need to care about these things. And that's a little unfortunate. So I think I want to keep the structure this way. Okay. So before we start fleshing out these individual points, I think the question is where I want to end the talk because we now have the, with tension as a theme, you can frame each item in relation to that. No restructure of explicitly call out what you're saying. That's true. And I think that's sort of what will go into these boxes on the right is what the tension is. Like for lints here, we already have it phrased in that way. It's a tension between, let me know if my code is bad and let me upgrade automatically. For requirements is a tension between sticking with the platform that you know works and being able to upgrade. Which is arguably the tension for all of these is let me upgrade automatically, right? For nightly, the tension is between making use of features that aren't done yet, but maybe exciting and powerful. And let me upgrade automatically for new features. Well, for new features is a little different actually, the tension is between doing work and improving the quality of your code. Yeah. So maybe that's a good point that for each of these, we should sort of highlight what the tension is. I like that. That's a good idea. Okay. So the question is where do we want to conclude out the talk? And so we talk about changes to rust itself, changes in rust ecosystem should free beset. I mean, so yes. Hi. You're trying to say you're hungry. Do you want to say hi? Do you want to be a little baby? Come on. Yeah, you're very cute. Hi, you're very cute. She's a little baby. You little stuffy. You're trying to get down? Okay. Okay. Okay. Well, it's almost like I want to say is all hope lost. But the hope is that in each of these slides, it's not as though the conclusion is, well, I guess we're fucked, right? That's not the takeaway from basically any of the slides. So when we get to this point in the presentation, the audience shouldn't be thinking everything is super dire. There are some talks that are like that, right? Where really you're presenting a big problem and then there's sort of a slide around the middle that says, but look, there's hope. This is not that kind of talk. It's not outline all the problems and then outline a solution. It is a here are the things to think about and how to think about them as a sort of semi ordered list. So by the time we get to the end here, it's not a, well, what do we do? It is a, it is more of a summary and then maybe a look towards the future. If we have something that's, you know, that there's a could be that there's a slide here that is more like the future is bright question mark. And here it could be like Rust LTS question mark, cargo Sember check question mark. Deny warnings equals 1.66 question mark. Fewer unstable features question mark standard MSRV policies question mark, right? So that there is, we could have a slide that's sort of like this of like, you know, things that may make this better in the future. But I don't think that's the main concluding slide. But maybe there is a sort of section here, which is like, will things get better? Because it's not as though things are super bad, right? That the talk so far has not been everything as shit. But it is also like some of these tensions are unfortunate and it would be nice if we could do better. So will things get better? I think we could have a slide along these lines. And then we could do, you know, what have we learned? And here are one of the things that I like doing here is a sort of single slide single point to have multiple of those like tensions, not actually that brief, but have like a couple of these saying, you know, these are the main takeaways, and then end on a summary along the lines of, I suppose this living with rust is pretty okay, actually. And I think, you know, there are a couple of general recommendations here, which is like plan ahead. This is stuff like try to take 1.0 dependencies, and sure you have automatic updates. Another is communicate back. So this is for stuff like if you discover accidental major version or accidental breaking changes in a minor version, or you know, the MSRV got updated and you're stuck on an older version for some period of time, because let's say you're on an OS distro that they hadn't really thought about. You might be like, Hey, did you forget about SUSE or did you forget about rel? Then communicating that back to the project might actually be, or to the credit in question, might actually mean that they will fix things, or even sometimes see the minimum supported rust version bump wasn't even intentional. They didn't, they just don't really have testing for it. So that actually is something I want to call out up here may have been accidental. So plan ahead, communicate back. And there's almost a point here of like, you're allowed to accumulate technical debt. You just need to be aware that you're doing it, right? So you can can ignore progress, but you're accruing debt in some sense. Cat better be better, cat better be part of the formal presentation. That's funny. This is work, but it is good work or something like that. Where did you intend that for? Would it make sense to compare where rust is that now versus where it was at seven years ago to show the potential progress seven years from now? Maybe did you have something in particular in mind that where you feel like there's been a lot of progress in the past seven years? Interest stability that is? Someone will pay for it eventually. Yeah, that's true. Although, you know, there's a sense in which there's very little cost to ignoring, you know, a new API added to the standard library, you know, that it's not really any cost at all to it, unless it specifically unlocks something for you. But as you ignore opportunities for improvement, chances are that the total sum of ways in which it could make your existing code better add up. And so you probably don't want to let them add up forever. So it's almost like a like a remember to like batch improvements, remember to do improvements, but you can do them in batches. Yeah, the progress won't ignore you. So it's almost like okay to update in batches or in sprints and delayed sprints. And at sprints, I don't mean like agile sprints or anything, but just like you can you can follow up with the progress by doing like basically interval training, right? You don't have to keep up with the marathon, you can just run many sprints. Now it's becoming a fairly long thing, like these feel like one point and it's a very long one. Ignore progress, but you're accruing debt okay to update and delayed batched sprints. So the question is, can we summarize this to make it a peg rather than a sentence? And I think the way we do that is ignore or it's like be mindful of what you ignore. Yes? Yes? Okay. Are you unhappy? Come here. Yeah, come here. What are you unhappy about? Yes, you're very cute. What are you unhappy about? Can you tell me what you're unhappy about? What are you unhappy about, Chai? Do you think it's lunchtime? Is that what you're trying to say? Do you think it's lunchtime? Okay, I'm almost done with the slides, Chai, or at least the first start of them. And then I'll give you lots of food. Yeah, burst is a good word for the kind of workload it is. Hi, has someone tasked with building a debug tool to parse read out data of a HEP detector in Rust? I'm interested, what is the essential issues for long term Rust? That is a much different or bigger challenge than in C++. I actually think that sticking with Rust long term is a little easier than it can be in C++ because of things like additions. Because the additions work sort of better than what you get with the standard bumps in C++. It's a little bit of a different experience. And also, the fact that semantic versioning is adhered to so rigorously means that it's much easier to stay up to date. You can generally automate it. Okay, nice. Just plan ahead, communicate back and be mindful of what you ignore. I like that as advice. That's pretty good. I like those takeaways. So what have we learned? Tensions sounds so severe. I think the things we've learned is that, well, arguably this is what we've learned. So we could say plan ahead, communicate back and be mindful of what you ignore. So have these be boom, boom, boom. And then down here, I like to have a slide that when the talk is done, I can leave up and it shows the takeaways. So this kind of structure is very impactful for driving home the main takeaways. But if I then ended on a slide that just said thank you, for example, when there are questions or as people are ruminating over the talk, that slide is useless to them. So I would rather have a slide like this. But I kind of want a some I want a thing that indicates we're done. So that's going to be a rust. Let's go right rust enough talk. Let's write some rest. Let's write. Let's go right rust. And then so what I'll do is I'll do you know, this talk about that a little this talk about that a little this talk about that a little enough talk. Let's go write some rust. Thank you. And then after I said thank you, move to this slide as I take questions. Living with us is pretty okay. Actually would be a great shirt, right? Boom, boom, boom. Yeah. And it's, you know, the rule of threes, that it's a good thing that we have three points. Postpone does not abandon is another way to phrase this. Although ignore and postpone are sort of different in semantics, right? Postpone is an intentional action that you're going to do with later. Ignore is I'm not going to think about it, which doesn't necessarily imply that you've planned it for later. And I think for many of these things, it's, it's actually okay to ignore them entirely. But maybe, maybe actually the takeaway here is that, okay, so an alternative take on the slide is don't ignore postpone. That's another take on that slide. Instead of be mindful of what you ignore, it's don't ignore postpone. Oh yeah, we do have to tie this back to Pharee somehow. I forget how to do that too. Is the order of the three key always relevant? Maybe being mindful is more important than communicating back. I was thinking of these three in like time order. Plan ahead is the stuff that you have to do before you start ignoring anything. You need to think about these things. Like before you take a dependency, communicate back is something that you do when something goes wrong. So I guess, yeah, maybe this one goes in the middle, maybe you're right. So this, although of course, sadly, that means they're not no longer ordered by length, which makes me sad. What do we like better? Be mindful of what you ignore or don't ignore postpone. I don't know which one I prefer actually. Relationship advice for couples. Plan ahead, be mindful of what you're ignoring. Communicate back, you're now wrong. That's pretty funny. Don't ignore postpone is less wordy. The question is, does it lose some of the... I like the phrasing be mindful. This doesn't convey that quite as eloquently, but this one is also easier and punchier. Don't ignore postpone because it implies to me that you should take notes about what you're choosing not to deal with at the moment. That's true. And in fact, you know, I could always say, be mindful of what you ignore, but have that be the point. I like that. I like that a lot. So this goes away. That goes there. And then this also changes to don't ignore postpone. Still longer than communicate back. I could make this longer just so that they are ordered, but I'm not going to do that. No, I think I like this actually, to have this be the point and then say this. Yeah, I also like the ahead and back connection. It is also true that don't ignore postpone is imperative like the other two points to make them feel similar. I like that. So now the question is, where does what maybe this is, what has for relearned? Plan ahead. Don't ignore postpone and communicate back. And then there's the, okay. So the one thing we skipped past this tech debt to a crew, we skipped past the sort of the future is bright slide. I don't know whether I want it because, you know, on the one hand, let me change this layout to this. So the future is bright is like a, what are promising avenues for making some of the things that we've talked about better. And I guess what's that? Is it cargo bus? Cargo bus factor. Rust bus. That's the one I'm after. So Rust bus is this effort to have, I don't know whether they're still active actually, but it's basically a GitHub organization that has a couple of people in it, like Rust people, where you can add them as owners to crates and they basically promise to not do anything with your crate. But should you be unable to follow up on something that they can sort of pick up the slack? So that helps with things like abandonment. It doesn't solve the problem necessarily. It's been around for a while. So it's not really a thing for the future. But I think these things are good candidates, right? So Rust LTS, I mean, I don't think we're going to see it anytime soon, but cargo semper check and cargo public API are both tools for checking that things are actually backwards compatible changes in an automated fashion. And so those are a part of solving, you know, accidental breakage, major versions, minor versions, not really minimum supported Rust versions. Denied warnings. Some of these are not really solutions either, right? So fewer unstable features. That's just a hypothesis I have that over time, you know, many of the unstable features are going to have stabilized and there'll be fewer new things and there'll be things we've already solved and figured out. No, you can't do deny warning sequels at the moment. I don't think there's even a public proposal for it. It's just, I think it would be hugely valuable. Would it be worth ordering those items by how soon they'd arrive? I don't even know that there's a way to do that. I mean, I guess, you know, semper check is one that already exists. It just, it has known limitations. Fewer unstable features. I think realistically, Rust LTS is pretty far off. And I think fewer unstable features is something that just, I'm expecting the like graph of number of unstable features to go down over time. But I don't have any proof and there's no, you know, set cutoff. Rust LTS is not really clear to me. A language version is supported as much as its libraries support that language version. Does this mean library publishers would have to support that version? No, but I think one of the reasons why we're seeing crates have wildly different minimum supported Rust versions at the moment is because there is no standard. There's nothing for them to hook on to, right? A lot of the discussions that I see on GitHub, for example, about, you know, what should this crates MSRB policy be is sort of, we're just going to pick a number that we think is sensible and that might be whatever Debian uses, it might be, you know, six months, it might be 12 months, it might be two years, it might be the whatever Tokyo uses, it might be whatever the latest addition is, it might be current version plus four. But but they're all sort of arbitrary. Whereas if there was a Rust long term release schedule, then I think what would happen is a lot of crates would align their MSRB policy to the Rust LTS. So they would say, we support everything up to the Rust LTS version, but not beyond. And there's a question of what happens when there's a new LTS and you probably want like overlapping timelines and stuff. But I think you would get, I think the ecosystem is pretty likely to align with that. And there's always a question of like, some crates are not going to be willing to stick to the LTS, because they're going to be like, well, that's, we need a feature that's newer. But hopefully at least the more connected a crate is like the deeper it is in the dependency graph, the more widely used it is, the more likely it is to have a conservative MSRB policy and one that is aligned to the LTS. And if you actually had a Rust LTS effort, you could totally imagine that the people involved in maintaining the Rust LTS might also in addition to, you know, backporting things into it contribute resources towards helping key crates stick with that LTS as their MSRB. So I do think that you're right that it depends on the ecosystem agreeing with the LTS and supporting it. But I think that would happen somewhat organically. Will the LTS issue be a very long problem to just certain libraries requiring unstable features? It's pretty rare actually that core crates require unstable nightly features. Usually the way they do it is they have build scripts that detect whether you're on nightly, detect whether you can use a given unstable feature and use it only if you can. So that's the way they sort of try to have the cake and eat it to is that they conform with the MSRB, but they take advantage of newer things if they can and something like, you know, config accessible with help with that. But ultimately, you know, you still pay the cost of needing to continue to have both code paths, right? If you have, you know, if, if this thing exists in the standard library, then we'll just use it. Otherwise we have our own implementation of it. Then until your MSRB means you can cut out your custom implementation or your backup implementation, that one's still in there and you need to continue maintaining it and supporting it. So it, it's not as though detecting what version you're on gets you everything you need for free. Cargo, public API, REST LTS, and whoa, that's a fancy ampersand. Fewer unstable features over time, question mark, question mark, question mark. I don't even know whether I want this slide because this is entirely speculation, right? Maybe the future is bright, perhaps. REST LTS standard MSRB policies, deny warnings, fewer unstable features over time. I, I think this is worth keeping. Like, okay, the, the measuring stick here is right. Would this help for free? If free is sees this slide, is it useful information to them? Cargo summer check and cargo public API is not because this is for create authors, more so for them, but the existence of them may mean that free is less likely to experience problems associated with the things that that those crates fix in the future. Same with REST LTS and standard MSRB policies is not relevant to free until it actually happens, but it might be interesting for them to be aware of the fact that it might be a thing. Deny warnings is something for you would use directly, but oh, actually, that's a good point. Lints. Lints aren't enforced on dependencies. It's important to let people know that. When you said deny warnings, that does not deny warnings in your dependencies, which is critical. Maybe you could outline these possibilities while talking about the things they would help with. Yeah, that's the other way to do it. Although like, you know, summer check and public API tie into a couple of different ones of these fewer unstable features over time, maybe. Yeah, I don't, I don't know. You are right that these are things I could mention as I go. And, and to be fair, I probably will. But it might be useful to have them collected in one place. It's just that this, this particular slides feels very of like vague and squishy. The little hermit crab could be thinking of these. That's true. I guess actually, okay, let's let's hypothesize here. Let's duplicate this slide and move it down here and say something like, what if there was a Rust LTS and MSRVs aligned with that? Yeah, I like that. And then we skip, will things get better? And then we say, okay, so we duplicate this. And then for accidental breakage, I guess that's where it would go. What if more projects, what if cargo public API, cargo Semper check and cargo public API were standard tools? Then our warnings, we already have one for Rust LTS. We don't really have one for LTS. I don't think matters up here for changes to Rust itself. I think the LTS is mostly important when it comes to MSRVs. Fewer unstable features over time. We could stick under nightly and then say, this one's not really a question, right? It's not a what if it's the number of unstable features over time go down over time. Yeah, I guess they don't have to be what ifs. Although it's nice for them to be what ifs, but they don't have to be. I like that. And then we can delete this and delete that. I don't think we need the recap actually, because I'm expecting the, I don't think the recap is important here. I think we can just talk about them as we go through. And I'm assuming these talks will be, and in fact, I know these talks will be recorded. So like people can always go back and look at them later. Okay, I think we now have the full structure for the talk. There's obviously a bunch more stuff that has to be filled out right around. What do we actually say? Or I guess, I keep saying we, what will I say when I present the slide? And what should be in the site to sort of guide me along for that slide and guide the audience thinking. But I think the cats are now complaining at me enough that I need to go feed them. But I think now we're at a very good place as far as having a sort of structure and outline and basic thread for the talk goes. So I think I'm going to stop it there. Was this generally useful? Was this generally interesting? Both from a rust perspective, but also from a making talks perspective? Or which is basically a question of should I do this again when I start filling these out? And should I do this again for another talk when I make another talk? And the answer could be yes to one or both or neither. Yes, great. Okay, I have one yes, that means it's yes. Everyone agrees. I guess the people who don't find it useful have probably already left. So the people who are left here are likely to have thought it was useful. Double yes, nice. It also be interesting to hear which aspect of this did you find useful or interesting or both? Because we've done a lot of stuff, right? We've made slides, we've thought about presentation structure, we've talked about different challenges about rust, we've talked about how to give presentations, we talked about my process for giving presentations and for designing them. And it could be that some of those things were interesting to you and some were not. So what were the interesting parts or useful parts of this? At the start, I didn't think so, but this was really dense and very insightful. Okay, that's good. I suspected that would be the case, right? That this would be a little slow to get started because we're just making a presentation, but that over time, a presentation is really a very condensed set of a lot of material. And so hopefully exposing that material would end up being interesting. I always appreciate looking how to construct talks. Yeah, I mean, as we've talked about through this too, there are a lot of ways to do it. It's not as though this is the right way and even as we've gone through this, we've considered multiple ways of doing this talk. And I think exploring that is interesting. As a non-rust developer, the rust specific stuff was more interesting than useful for me, but I present a lot, so I'm taking notes. Nice. It was interesting to see how much thought goes into little details. Yeah, I think for that's not always true for people make presentations, like some presentations are bad. Some presentations are accidentally good, but I think thinking about these details makes the presentation more interesting to watch and more helpful to watch. So it's worth thinking about the details. Seeing you keep the scope small is inspiring. I'm bad at that. It's really hard. It's very tempting to try to do a lot with a presentation because you're like, okay, I have an important topic. I have a lot of people I can talk to. Let me try to get all the things that I want to say out there. And unfortunately, if you don't reign in that instinct, the presentation ends up being bad for every part of the audience. And so it's more important to scope it down and then make sure it is actually useful and interesting to the subset that you chose to focus on. Okay, let's end it there. And I'll see about scheduling time to do sort of part two of this, or maybe I'll keep part two a secret to build up some excitement about watching the final talk. Otherwise, you'll all have seen it by the time I actually present it, which would be weird. Okay. Thanks, everyone. Thanks for joining. I'm glad you thought it was interesting. And I'll see you all again some other time. Bye, folks.