This Week in Rust - Issue 350
Episode Page with Show NotesThis Week in Rust 350
Nell Shamrell-Harrington: Greetings, fellow Rustaceans! We’re back with another episode of This Week in Rust on the Rustacean station.
As always, I’m Nell Shamrell-Harrington, lead editor of This Week in Rust and also a Sr. Staff Research Engineer on the Rust team at Mozilla.
This episode covers issue number 350 of This Week in Rust, published on August 4, 2020.
We are continuing with dividing our news and blog post section into subsections. Thank you to all who expressed your feedback on Reddit and Twitter, it seems you really like the subheadings, and we are going to continue to do them.
Additionally, I’m going to do something special on this podcast for the next few weeks. RustConf is coming up on Thursday August 20. I’m MCing the conference and am getting ready by interviewing the upcoming RustConf speakers. Each interview is 5-10 minutes long and we’ll start off this week with Sian Griffin, Jane Lusby, and Ashley Hauck. Each speaker will introduce themselves and give you a brief preview of their talk at the end of this episode.
First, the news.
In official announcements, we had not one but two new versions of Rust released this week. Rust 1.45.1 is a collection of fixes. It addresses bugs that only affected the 1.45.0 release. Rust 1.45.2 is also a collection of fixes, one fix for 1.45.1 and one for 1.45.0. Check out the blog posts for more information.
Moving on to tooling, I’d like to highlight a new project called Headcrab, which just published its July 2020 progress report. Headcrab, which I’ve mentioned on this podcast before, is a project to create a new modular and composable debugger library for Rust. This project looks very promising and I encourage you to check it out and get involved.
Next, a new section of the newsletter called “Newsletters”. While This Week in Rust provides a general overview of what is going on with the Rust language and in the Rust community, there are several specialized newsletters that focus specifically on Rust gamedev, Rust and blockchain, and, as featured this week, Rust OSDev. This Month in Rust OSDev provides a regular overview of notable changes in the Rust operating system development ecosystem. Take a look at the full newsletter for updates to projects hosted under the rust-osdev GitHub organization, as well as updates to personal projects also related to Rust OS Dev.
Like last week, and I think like most weeks going forward, the learning section has by far the most articles.
Ferrous Systems has published the first in a series of posts called “Learning Rust: Mindsets and Expectations”. This series will cover patterns for learning Rust effectively. These patterns are based on interviews with many different Rust developers about how they learned and found success with Rust. In the article’s own words “Give some time to your learning process, and you’ll see that core concepts like Ownership and Borrowing deliver joy: they make it easy and comfortable to write programs that are memory-safe!”
Speaking of memory safety, Tiemoko Ballo has published “Blue Team Rust: What is ‘Memory Safety’, really?” Ballo explores what “safe” means on a technical level. This includes going over what exactly Rust’s “memory safety guarantees” are — including stack protection, heap protection, references always being valid and variables initialized before use, and data races being completely eliminated. There are some caveats when discussing memory safety in Rust. In particular, not all Rust code is memory safe - memory safety guarantees apply broadly, not universally. Unsafe Rust code drops memory safety guarantees for a limited scope and doesn’t eliminate all checks. Additionally, Interior mutability can push borrow checks to runtime.
To quote the author:
“Memory safety is not a new idea, garbage collection and smart pointers have been around for a while. But sometimes it’s the right implementation of an existing good idea that makes for a novel great idea. Rust’s ownership paradigm — which implements an affine type system — is that great idea, enabling safety without sacrificing predictable performance.”
In a previous issue, we featured an article on packaging Rust applications for Windows by Ryan Gorup, founder of Ebbflow. Gorup has now followed up with a new post that covers how Ebbflow packages its Rust applications for Linux. The article is broken up into problems that Ebbflow needed to solve after the core code for their client was written. These problems included figuring out how to run a daemon in the background - which was solved by creating a systemd service and including a systemd unit file in the compiled packages. These problems also included statically linking dependencies using a MUSL target with rustup and using rustls. Finally, they also had to develop different packages for different Linux distributions. They used cargo deb to create deb packages and cargo-rpm to create rpm packages. There will be another post in the future on automating builds and vending those builds to users.
One of the most fascinating articles to me in this week’s issue is “Reverse Engineering a USB Device with Rust.” Harry Gill, the author of the post, was building a new workstation with the AMD Ryzen 3950x CPU and trying to get the maximum performance out of it to reduce Rust compile times. Gill used a Corsair H150i RGB PRO XT AIO to cool the new computer. It was working well, until they discovered that Corsair does not provide any support for Linux, which meant Gill could only adjust settings for and view the status of cooling through Windows. Not to be deterred, the article goes on to describe how they researched USB protocol and used tools like USBPcap to capture packets being transmitted between the cooling unit and the PC. Next, Gill created a Rust project to read information from, configure, and send commands to the cooling device from Linux. This is a really cool project and a great introduction to reverse engineering USB devices
One of my favorite ways to learn and practice new programming languages — or refine my technique with known programming languages — is through Exercism IO. Exercism IO is a site where anyone can download exercises for various programming languages, solve the exercises, submit them back up to Exercism, and then receive mentorship on their solutions by volunteers. One of the challenges of Exercism is that it can take some time for a live person to get around to reviewing a submission. Sean Chen, a contributor to Exercism IO, describes this problem and a potential solution in the blog post titled “Some Learnings from Implementing a Normalizing Rust Representer”. Chen wanted to decrease wait times for students by streamlining the feedback process for Exercism mentors. One thing Chen realized would help would be normalizing the submissions by stripping away things like formatting, comments, and variable names so the mentor could focus on the logical approach of the submission. Chen created a Rust normalizing representer that parses the source code of submissions into an abstract syntax tree, then applies transformations to the appropriate tree nodes, and finally turns the tree back into a string representing the transformed source code. See the blog post for more information about the implementation of this normalizer — to me it felt very similar to how the Rust compiler works.
My other favorite way to learn and practice Rust is through the Rustlings exercises. Rustlings is a collection of small exercises to get you used to reading and writing Rust code, including reading and responding to compiler messages. Chris Biscardi has put together a series of videos that show them working through the various Rustlings exercises. I have been through all of the Rustlings exercises myself and there were 2 or 3 that I could never fully figure out the answer to. I’m looking forward to watching and learning from the videos on those exercises.
Moving onto project updates. The Rust Language Cheat sheet, also known as cheats.rs, is a project from GitHub user ralfbiedert. It is a single page Rust resource for people who like high information density. Ralfbiedert has written up a status update that details changes to the project from 2019-2020, including a complete rewrite of the Memory and Lifetimes section, the addition of a visual section, coding guides, and much more.
Under the miscellaneous heading in this week’s newsletter we feature two episodes of The Virtual Worlds Podcast. The Virtual World podcast by Ty Tracey is a podcast about Software Engineering, Technology, VR, Art, Music, Creativity, Inclusivity, and Love. This week they posted two “State of Rust” episodes — one with Alex Chrichton and one with Steve Klabnik.
Moving onto RFCs, one RFC was approved this week — the C unwind ABI. It has been exciting to watch the progress of this RFC from it’s very beginning to its acceptance. We’ve covered this RFC on previous episodes of this podcast, please refer to those episodes or to the RFC itself for more details.
Two new RFCs were proposed this week. The first, titled “Edition 2021 and beyond”, revises rules and plans for Rust editions. It announces plans for a Rust 2021 edition and for a regular cadence of editions every 3 years. In the RFCs own words: “Unlike Rust 2018, we will avoid using editions as a “deadline” to tie together high-priority projects. We specify a cadence for Edition lints. We specify a policy on reserving keywords and other prospective changes.” See the full RFC for all the details and discussion.
The second new RFC is titled “Procedural vtables and wide ptr metadata”. To quote the RFC’s summary “Building a wide pointer from a concrete pointer (and thus vtable generation) can be controlled by choosing a custom wide pointer type for the trait. The custom wide pointer must implement a trait that generates said wide pointer by taking a concrete pointer and a generic description of a trait impl. By default, if no vtable generator function is specified for a specific trait, the unspecified scheme used today keeps getting used.”
Now, let’s discuss upcoming events in the Rust community. Are you feeling nostalgic for travel? Over the next two weeks you can take a trip around the world through online Rust meetups - including in Johannesburg, South Africa, Dublin, Ireland, Linz, Austria, Berlin, Germany, Saarbrücken, Germany, Buffalo, New York, Indianapolis, Indiana, Seattle, Washington, and San Diego, California. Enjoy your trip!
Additionally, an in person meetup is currently scheduled in Columbus, Ohio.
And that’s it for the summary of This Week in Rust issue number 350. Now, let’s move onto interviews with some of the RustConf speakers.
Sian Griffin Interview
Our first interview is with Sian Griffin, who will be presenting the closing keynote of RustConf.
Sian, well, could you introduce yourself for our listeners?
Sian Griffin: Yeah, my name’s Sian Griffin. My pronouns are they/them. I’ve been working in Rust for— I don’t know how many years now. I co-lead the crates.io team, and I’m also a member of the infrastructure team.
Nell: Awesome. We’re glad to have you on the show and very excited about hearing you speak at RustConf. What’s the topic of your talk?
Sian: So my talk is about the “MissingNo” glitch from Pokemon Red and Blue. We’re gonna look at all of the really technical details of why it happened, and the constraints the developers of those games were working under. And why I think if you were working under those constraints, you would have introduced the exact same bug.
Nell: Absolutely. We were talking a little bit before this, and I mentioned my dad, who’s an Air Force pilot, used to say whenever he was analyzing an accident, after analyzing it, “there but for the grace of God go I.”
Sian: Yeah, it’s just insane, the constraints that game developers had to work under in the early nineties. I mean, this was when folks were still handwriting assembly and your whole program had to fit in 8k.
Nell: Right. So this is original Game Boy, it sounds like, if it’s in the nineties era.
Sian: Yep, original Game Boy. The follow up, which fixed this bug, was Pokemon Yellow, which was on the Game Boy Color.
Nell: Gotcha. And what drew you to this topic?
Sian: My partner and I have both been big fans of Pokemon our entire lives. And I really enjoy watching speed runs of video games, and there’s a lot of speed runs of the original Pokemon games. Because there are glitches all over the place that you can exploit to finish the game really quickly. As a kid in the nineties, we all knew about the MissingNo glitch. It was a really useful thing that just somehow managed to spread across the entire— at least the entire country, I assume the entire world, but I can’t speak for folks who grew up outside the US, what their experience was.
But yeah, so as an adult, I was curious, like, so why did that bug even occur? It was such a, like— why did encountering this Pokemon— It was such a seemingly random sequence of events you have to do to cause the which to happen, and increasing the item count of the sixth item in your inventory was just such a weird side effect of encountering a Pokemon. I really wanted to know why it happened, and when I looked, and when I started to learn all the details of what goes into it, I just realized, oh— Yeah, no— it’s absolutely reasonable that would have slipped through. And so I kind of want to give a talk of just like, hey, maybe we should stop saying things like, oh, this software is so broken, because usually it’s just under constraints that we don’t understand.
Nell: Yeah, I’m trying to remember— I’m just thinking about the constraints that game developers in the nineties would have been under. Not just the crunch time that we hear about in game development today, but also the restraints of a— compared to your x86 computers today, a very constrained system in the Game Boy.
Sian: Well, and it’s also, at the time of the original Pokemon, Game Freak was a really small company. This was their first large-scale game. It was relatively rushed out in Japan. If you look at the sprites for Pokemon Green, you can definitely see, like, the massive difference in quality between Green and Blue, and for Blue, I mean, it was unexpectedly popular in Japan and they had to rush out a U.S. release. And that’s where a lot of this stuff sort of slipped in.
Nell: Awesome. So, you cover this a little bit, but just getting a little more specific, what can our audience look forward to seeing in your talk at RustConf, because you’re their closing keynote?
Sian: Yeah, so I mean, this is gonna be a really in-depth technical look at the assembly of the relevant pieces of the game. What it looks like in Rust— don’t worry, you do not have to be well versed in Z80 assembly in order to enjoy this talk. You also don’t need to have played or even heard of Pokemon before. We’re gonna go over all of this. But we’re basically going to be looking at what actually happened under the hood, at each step of the bug. Why the developers may have made the choices that they did, that led to the bug happening. And basically, just try to understand, why is it, that if you if you talk to a dude who catches a Weedle in one city, and then surf up and down a coast in another city, you have run into a glitched Pokemon and get 128 rare Candies?
Nell: Awesome. Well, I certainly look forward to seeing your talk. RustConf is virtual this year. If it was physical, I would say, well, let’s have a Pokemon Go party afterward, but we can have a— we’ll figure something out. Well, thank you so much for joining us, Sian. And I can’t wait to hear your talk.
Sian: Of course. Thanks for having me.
Jane Lusby Interview
Now, let’s hear from Jane Lusby who will be presenting “Error Handling Isn’t All About Errors.”
Nell: Could you introduce yourself for our listeners?
Jane Lusby: Yeah. My name is Jane Lusby. On GitHub and Twitter my tag is “yaahc”. And I am like, you know, just a Rust fangirl who really likes error handling.
Nell: Awesome. And what’s the topic of your talk?
Jane: My talk is about error handling. Specifically, the talk is titled, “Error Handling Isn’t All About Errors.” And I’m going to try and get into some of the details of error handling, and specifically, errors versus context versus error reporting, and kind of separate these ideas in a way that makes everything easier and simpler to understand.
Nell: I know as Rust developers, whether they’re new or experienced, a lot of us don’t want to deal with error handling, so we just copy and paste stuff that we think works into it. But we don’t really understand how they work, and how we can use them to to make our code the best they could be. And what drew you to this topic?
Jane: It’s actually— it was a yak shave. I was trying to open source this little tool I’d written for work. And I ended up, like, before I open sourced it, I was kind of embarrassed by the error handling, because I had, kind of just copied and pasted, and tried to like, sweep it under the rug, so I could get the actual work done. And I really wasn’t happy with it, and so I decided to try and fix it before I open source the project, and ended up getting lost completely in the world of error handling. And now it’s just, kind of, my favorite thing about Rust.
Nell: All right, what can our audience look forward to about your talk?
Jane: Hopefully you can learn some useful patterns and some cool libraries that you can use to easily do proper error handling from the start.
Nell: Awesome. Well, I am looking forward to that talk. I think you’re first up right after the quarantine keynote. Sorry, didn’t mean to make you nervous there.
Jane: That’s cool. I had a gasp but than I’m like, wait, it’s recorded. Like, I’m not going to actually be nervous—
Nell: This is true. We are prerecording them. So, very much looking forward to your talk, and looking forward to chatting with you in the Discord server at RustConf.
Jane: Yes!
Ashley Hauck Interview
Nell: Finally for this week, we also spoke to Ashley Hauck who will be presenting “Controlling Telescope Hardware with Rust”.
All right. Well, Ashley, welcome to our podcast. Could you introduce yourself for our listeners?
Ashley Hauck: Hi. My name is Ashley Hauck. I am a developer at a game studio called Embark Studios in Stockholm. I have been interested in space since I was a kid.
Nell: How long have you been doing Rust?
Ashley: I’ve been doing Rust for a couple of years now. Probably around four or five years, I think. I have attended RustConf starting in 2017, I think.
Nell: Great. Well, what’s the topic of your talk?
Ashley: So I’ll be talking about telescopes, and how they work, and especially how to control a custom hobbyist telescope with Rust. And so I’ll be talking about the hardware and how we talk to that hardware, using serial ports, using C APIs.
Nell: It sounds like it’s gonna be covering a lot of ground.
Ashley: Yeah, it is. It’s mostly an introduction of hardware. So if you’re, like, a super Arduino hacker, whatever, this’ll mostly be over you, but if you want to get an introduction of, how to start in the world of hardware with Rust, this is the talk for you.
Nell: Awesome. What drew you to this topic?
Ashley: I’ve been interested in space since a kid. I think it grew out of a passion to be an astronaut. Like, every kid wants to be an astronaut, and that passion sort of morphed into a passion for astronomy. And so I got into astrophotography a couple of years ago. I bought a telescope, bought all of the hardware, and started taking pictures of the sky. And I suddenly realized that I wanted to customize my telescope quite a bit. And so I developed an application to control all of my telescope hardware in Rust, and I wanted to share all of my experiences of developing those hardware controls in Rust.
Nell: Sounds great. Next question I’m gonna ask is, what can our audience look forward to about your talk? But I think I want to preface that with, will there be pretty space pictures?
Ashley: Yes. There will be pretty space pictures in the talk.
Nell: And it sounds like, somewhat, there’s going to be pretty space pictures, and also it’s gonna be a good introduction to hardware hacking, which, I know there’s a lot of interest about.
Ashley: Of course, of course. Yes.
Nell: Thank you. Well, I am looking forward to your talk. I know our listeners are too, and we will see you at RustConf.
Ashley: Thank you so much for having me.
Nell: As a reminder, RustConf registration is open and I hope to see you all there. Make sure to listen next week for more interviews with the upcoming speakers.
And that’s all for this week’s podcast, make sure to check out the full issue of This Week in Rust for even more fantastic Rust content.
This Week in Rust is edited by myself, Andre Bogus, and Colton Donnelly. This week’s contributors included, using their GitHub usernames: Gorup, Lfn3,Darneas, Imor, Ralfbiedert, Marek-g, Epilys, Daniel-Liu-c0deb0t, Shinokada, Dns2utf8, Inshalayaz, Tnballo, and pnehrer.
As always, if you write a great article on Rust or happen to see one — please submit it to This Week in Rust by opening a pull request on our GitHub repo. Have a wonderful week everyone and please stay safe out there!