 as Steve said, I'm going to be talking about navigating. I'm here from the Rust Belt City of Pittsburgh, Pennsylvania. Note the H on the end. It's very important to distinguish from Pittsburgh, California. Our tallest building is the steel tower, which is made of quartend steel, which is a kind of steel that's made to form protective layer of rust on the outside, so you don't have to paint it. So I think this qualifies us for the rustiest place on Earth. And lest you try and outrust us, San Francisco, I'll have you know that the quartend marketing materials, say, areas that have salt, laden air, high rainfall, humidity, or persistent fog are typically not the proper environment for quartend. So don't even try. I've been using and contributing to Rust for about a year. I've really been enjoying watching and participating in Rust's open development. And by open development, I mean that the decisions, the discussions, and the history thereof are available for anyone to read and participate in, in addition to the specification and reference implementation of the language itself. I think the availability of this information has made me a better user and contributor. I also think it's very important that this information is out there not just for Rust itself, but for future language designers. The rationale, the trade-offs, and the experiments, and the results will help future language designers make decisions. Developing in the open is, thankfully, becoming more and more common. Go, for example, is also developed in the open. Even for languages that say they are open source, that doesn't always mean that their development process is open.net up until about nine months ago, for example, would just do a dumps of code every so often from their internal processes. And that is not as helpful. And for older languages, like C, this kind of information has been lost to history because the internet isn't what it is today back then. So I think having this information available for anyone is really important. An example of what I mean by the importance and what information is useful, there's an RFC out there that Patrick Walton proposed removing the tick from the lifetime syntax. And this didn't end up getting accepted, and most people were against this RFC, mostly because they were used to it. The tick didn't really bother them anymore. And Patrick made this great comment that I love, trying to get everyone out of the sunk cost status quo mindset. And what Patrick is saying here is, if from the beginning of Rust, lifetimes didn't have the tick, and this RFC was to introduce the tick, everyone would be against adding it. And to me, I think this is important because the next person to create a new language is going to be in this situation, not for ticks in lifetimes in particular, but for every decision. They're not going to have a history to fall back on. They're going to have to make every decision from scratch, and they can learn from the things that Rust tried that worked or didn't work, or people liked or didn't like, and use that information when they don't have any to start from. So let's go on a few journeys through Rust open history. There's a lot of information out there, and I'd like to share some tools and techniques that I've used to find what I'm looking for in all of this open information. I hope even seasoned developers will learn at least one new tool or technique, or at least enjoy a stroll down memory lane Rust development history. So, journey number one. The largest earliest treasure trove of Rust information is the mailing list. The Rust mailing list through Mozilla was active from about July 2010 through January 2015 when we've moved to discourse, the users in internal discourse. And the first tip I have for you is instead of looking at this on Mozilla's site, is to read on nabble.com. Nabble is a site that hosts mirrors and archives lots of different mailing lists. And the reason I would recommend this is because they have a search box. Very helpful for finding things about a particular topic that you're looking for. I love reading the mailing list because it's where discussions of important things happened before it was clear that they were important things. For example, Patrick again. This is a thread he started in 2011. Before Rust 0.1, it's this short little 21 message thread, but it's really dense with important ideas. Patrick was proposing renaming tag and log error. And if we start with the log error part, log and log error at this point in time were the only way to get output on the screen. And you had to be sure that you set your Rust log environment variable just right. So it made Hello World not very nice to do. And Ruin responded to this and said, oh hey, by the way, I just added print and print line to the standard library. And this is bizarre to me because this deserves like its own big announcement, in my opinion. Because printing to the standard out is something I do every single day. So it should be like, we have print and print line now. It's just kind of a reply to this other message. And a few messages after that, Ruin says, oh, maybe we should have a prelude like Haskell, that's something that's always imported so you don't have to import standard IO all the time. And that totally ended up happening. We have a prelude today. And regarding the tag part of the message, tag is what ends up becoming enum today. And this is where that it was agreed upon that enum would be a better name. So these three huge things are in this tiny little thread from 2011. And this just blows my mind. I love seeing the primordial ooze of rust in the mailing list. It's really, really interesting. So journey number two, this one is going to be mostly about using the power of get to finding information you want. And it's going to be about lifetimes. We've talked a lot about lifetimes in I think most talks today. Who has sprinkled tick A around your code to make the compiler happy? Yes, basically everyone. Yep, me too. Excuse me? Tick static that also tends to help, yes. Lifetimes are powerful and awesome. One of my favorite parts of rust, but they're also something new that not many people are used to and take some time. I'm very grateful for the lifetime of vision rules that make it so that you have to tell the compiler about your lifetimes less often. And if we take a look at the documentation, there's the lifetime of vision section that you've probably read. And there's a section about for the three lifetime of vision rules. And as a beginner reading these, you might think that rules were a decision that was made early on and all the rust code ever has followed these rules. Otherwise it is an error to rely on an output lifetime at the bottom here. It sounds very, very strong, very strict, very designed. But we don't know that for sure that this has always been around and have they changed at all? We don't know that either. Who came up with these rules? So if we wanted to find this out, one thing we know right now is that these rules exist in documentation, but we don't know exactly where this is. And if I wanna find out where something is now, I typically reach for gitgrep. This searches the files that git is tracking and helps answer the question of where is the code right now? And if we do a case insensitive gitgrep search on lifetime of vision, we find that these rules are in the lifetime of vision section are in this lifetime smart down file in the documentation. So now that we know the file that these rules are in, we can use git log on just that file to see how has this file changed? And if we do a git log of lifetime smart down, we get a bunch of things. This is less information than doing a git log on the entire repository, but because we're only interested in lifetime of vision section, this is still kind of too much information. So at this point, we can switch to git blame, which shows you how each line in the file was last changed. And that for lifetime's markdown looks like this. On the left side, you have the commits, who made them, and the date. And on the right side, you've got the lines of each file. Except we're looking for the lifetime of vision section, which is pretty far down the file. So we could search to that, but that kind of takes a long time. So we're still hitting the too much information problem. But if we look at this file and see what line the lifetime of vision section starts on, we can use the dash capital L argument to git blame. And since we are looking at the file and can see the lifetime of vision section starts on line 269, we can say git blame starting at line 269 of that file. And now we've got the lifetime of vision section that we're interested in. We can see that Steve last changed most of the section in April. And if we do a git show on that AB3 commit, we see that the last time this section was changed, it actually, Steve actually moved this whole section from the ownership file to the lifetimes file. I'm only showing part of the diff here, but this is the important part. So the rules existed here in a different file. So this particular change doesn't tell us anything about the origin or how the rules have changed. So we need to go further back. And we need to now go further back on the ownership file instead of the lifetimes file, but there's a catch with that in that we can't just do git blame on that file because the lifetime of vision section was removed from that file. So, and git blame shows the current state. So the lifetime of vision section is not gonna show up in this, which we can then move to a different version of the git blame command, where you specify the commit that you wanna start at. And that answers the question of how is each line at this commit in this file last changed? Now, we know this AB3 commit, but we know what happened in that commit. So we're not going to do git blame that commit because we know the change was to move the lifetime of vision section out. So we wanna save the commit before that and then we're gonna say it's parent by adding the tilde. So that's the commit before this one. So if we now run that command, now we see the git blame output on the ownership section, but we're back to the too much information problem because the ownership file is big too. And if we're too lazy to get show this file at this point in time to get the line numbers, there's a different version of the dash capital L argument where you can give it a regex. And when I found this out, I've never seen another option to command line argument that took either a line number range or a regular expression. So that was a little confusing. At this point, I would probably start tweeting about git's horrible user interface at which point either Jake or Steve or both would say, oh, it's easy. As long as you understand that line numbers and regular expressions are just nodes in a directed acyclic graph or something like that. I'm not gonna think about that too much, but we're going to give a dash capital L regex. So this is the command that's getting us, we're getting closer, I promise, we're getting closer. So we give it the regex of the lifetime and we can see that the git blame would show us that the commit that changed that was this commit, which I took a look at this and Steve just added a section that said the elision to CURT is happening for ergonomic reasons, so that wasn't very interesting. If we move beyond that commit by switching the AB3 commit for the AF0 commit, then we see a commit that says add the lifetime elision information. So here we go. So now we see that the rules haven't changed since they've been added, because this is what we've found looking back in history. This is where they got added to the documentation. But they were only added about six months ago, so they haven't existed since the beginning of Rust. They're pretty recent. And Steve mentions a GitHub issue, which then we can go take a look at that and it was an issue saying add documentation about the lifetime elision and Steve links to the RFC's repo. And whenever you're looking for reasons why or discussion about something and you find a link to RFC's repo, follow that link, because that's where you're gonna find people talking about why justifying reasons for decisions. So if we follow that link, we find RFC 141 that has 78 comments about the lifetime elision rules and you can read through these on your own time and I encourage that, because it's really interesting. For this RFC, Yehuda did a survey of existing Rust code at the time and found that there were patterns of lifetime function signatures that we could then teach the compiler about so that you didn't have to write that boilerplate. And as a result of that survey and the added power to the compiler, lifetime annotations 87% of the time could be left out of your functions signatures. So if you think you have to write take a lot now, imagine doing it this much more. So I found this really interesting because the rules were not set out from the beginning of time. They emerged from looking at existing code and trying to make that better. So I think that would be useful information for a future language designer that not everything has to be thought of upfront. You can take a look at the code that results as you're building things in your language and add additional improvements based on looking at existing code. Exploration number three. When I was reading through the mailing list, I found some messages that talked about iFace. And this was a keyword that doesn't exist anymore, but at some point it existed. From context, I could tell that it was a shortened form of interface, but I'm kind of glad it doesn't exist anymore because it makes me laugh because it sounds like it's the next Apple product you don't really need. What was iFace and where did it go and has it been replaced with something else? So if we set out to answer those questions, we can't use the tricks we used before because iFace is gone. This does return a couple of results, but there are things like a compile fail test to make sure that this is no longer a recognized keyword. So because we don't know where in the code base this was, we can't use the get log and get blame tricks from the second example. So at this point I'd pull out the pickaxe search which is get log dash capital S or capital G. If anyone knows why this is called the pickaxe, I'd love to talk to you about it later because I cannot figure out why this is called pickaxe. I still don't get it. No, it does not look like an axe. I don't think you can cut down any trees with a dash capital S, I don't know. So, and anyway, there's a dash capital G. So dash capital S finds the commits where the thing you're searching for was added or removed on a particular line in that commit. Dash capital G is a more recent addition to get where it will find lines where the thing you're searching for was changed, not just added or removed. So if we run this on the rest repository, we find this commit that, from Lindsay Cooper, that says stop parsing iFace. So this is where it disappeared. So that helps. We now know when and by whom this was removed from Rust. But we don't know why. And this is before the GitHub issues were sensibly used. So there's no issue mentioned, so we can't use that trick. At this point I was at a little bit of a dead end. So I searched for Lindsay Cooper Rust to see what other work Lindsay's done. And I found her intern presentation on Air Mozilla, which is also a great resource for all sorts of not just Rust presentations, but lots of things that Mozilla does, the videos are available on Air Mozilla. So I started watching her presentation. And at the start of her internship, iFace has existed. And what they were were lists of method signatures that you then have to implement. And they were like basic Haskell type classes, but without default implementations of other methods to find in terms of the interface methods. This reminds me a lot of Ruby, where if you implement each, then all of enumerable is implemented in terms of each. So you get all those for free. But her intern project was not related to iFaces. It was to implement traits, which were a collection of methods and fields with some being provided and some being required for you to implement. And that didn't exist at all in Rust. But as she mentioned in her presentation, about halfway through her internship, they realized that iFaces and traits could be the same thing. The required methods of traits could be the iFace method signatures. And the implementations of type classes that iFace didn't have yet could be the provided methods of traits. And these slides answered my question exactly. Here's what happened to iFace. Lindsay renamed iFace to trait, and that became what traits are today. Lindsay also mentioned that more information was on a proposal on the Rust wiki. Proposals are what RFCs are now. And unfortunately, the wiki is no longer a GitHub wiki for licensing reasons, but it's been moved to a GitHub repository called the Rust wiki backup. And a trick about GitHub wikis are they really are just Git repositories behind the scenes. So now this is a regular Git repository and we can use the pickaxe search again to find the deleted page that was the proposal for unifying traits and interfaces. So I'd like to end with some thoughts that came to me as I was working on this presentation. One thought's depressing and the other's hopeful. We're gonna start with a depressing one. You'll notice that a lot of the stuff about Rust is on GitHub right now. And I love GitHub. GitHub is great. It's made collaborating on open source stuff a lot easier and has increased participation. But what happens when GitHub goes away? You can call me paranoid by Google code or shutting down. Sourceforge is basically dead. We all have the code and the commit history on our machines but we don't have the issues, the pull requests, the comments. Fewer people have the wiki checked out I'm sure. And that's where the really interesting stuff is. I've looked into some tools that will export all your GitHub stuff to Bitbucket or GitLab. They're still kind of rough around the edges. You kind of hit API limits with a big repository like Rust. I do want to do work on this and make it better so that you can move stuff off of GitHub. Archive.org is another project that can help in this sense and it does have some snapshots of the GitHub Rust repo. But you can't really take that and continue on from there. And in the state and age of single page apps, archive.org can't crawl everything. As far as I know, we've already lost IRC logs from before April 2013 because they were on this site called IRC log grr, which doesn't exist anymore. And if you look it up on archive.org, it loaded all the data with Ajax so you just get an error message. So those are gone. So that's the depressing thought. I want us to think about how we're preserving the information we have for the future. But the hopeful thought, we're at the very beginning of Rust. There's so much left to do. Every little bit counts. As we saw, sometimes there's important things that don't really seem that important in time but become more important in the future. So I want everyone to think about the things that you're born to explore with Rust, the things that you're gonna create, the things that you're gonna discover and how you're going to journey with Rust and help the community. That's my talk. This is my ridiculous cat. She has not been hit by a car. Links to all of the things that I referenced are available on my blog. Thank you very much.