Rust's Golden Rule

[00:00:00]Imagine if Rust worked like a dynamic language like Ruby or Python. You could write a function with no return type at all like this one. The last line returns X. So the return type is inferred to be an integer. But what happens if we change this one line? If we comment out this line, the functions return type changes completely. FU used to return an integer and now it returns nothing. And we get no error or warning. And even worse, we know that every piece of downstream code that calls FU just broke and nothing told us. That's everyday life in a dynamic language. But luckily, Rust has one golden rule that completely eliminates these issues. And that rule lets Rust do something that even Java or C cannot do. In this video, I'll explain Rust's golden rule, why that rule makes Rust more robust than other strongly typed languages, and where the rule starts to work against you. Let's start with the golden rule. Here's our foo function from the beginning of the video. We've also added a second function baz that calls fu and adds one to the result. The y variable is whatever fu hands back, which is currently nothing. So the build breaks inside of baz, the caller. But food, the function we actually changed, is what's really broken. One edit broke code far away, and the compiler blamed the wrong spot. Now, here's Rust's solution, and it starts right at the top. In real Rust, we fix this code by writing robust function signatures. FU takes a number and hands back a number. That's the contract. And now our missing return type is caught immediately inside FU.

[00:01:39]The compiler reads the signature, sees that the function body hands back nothing, and blames the body, right where the problem is. The function signature is the contract, and the function body has to keep it. Steve Clavnik, one of the authors of the official Rust book, named this Rust Golden Rule and wrote a great blog post about it, which I'll link below. Now, you're probably thinking, "Every typed language does this. Java, C, Go, and you're right." But here's where Rust goes further than other typed languages.

[00:02:11]And we'll show it with a real example.

[00:02:13]Here's a payment function called charge.

[00:02:16]A typed language like Java lets you express the kinds of values going in and the kind of value coming out. Most type languages stop here. But Rust goes one step further. The amperand mute here means charge needs exclusive access to the account. Nobody else is allowed to touch that account while charge runs. In Rust, function signatures express more than just types. They express how memory is used. And this has a huge benefit.

[00:02:44]All the information the Rust compiler needs to ensure memory safety is written in the function signature. This means the Rust compiler does not need to read the function body which makes compilation faster. But that same rule has a cost and this is the exact thing that makes people fight the borrow checker. Here's where that cost shows up. Here's a point strct with two small helper methods. Xmute hands back the X field and Y mute hands back the Y field.

[00:03:11]Now look at Xmutes signature. It borrows self-mutably. Borrowing self-mutably in Rust gives exclusive access to the entire point, not just the field X. And when we look at Ymute, its signature does exactly the same thing. It takes exclusive access of the whole point, not just the Y field. Now when we look at scale, we notice it calls both methods.

[00:03:35]It ends up asking for exclusive access to the entire point strct twice at the same time. And Rust never allows two exclusive mutable borrows of the same value at once because if it did, Rust could no longer guarantee memory safety.

[00:03:51]And so the compiler refuses to build this code. Now you and I can see that the two methods touch different fields.

[00:03:58]So there is no real conflict. But the Rust compiler will not analyze the function bodies to get this context. It only reads the function signatures and both functions claim exclusive access to the whole point strct. The signature actually bites us even though the body is fine. So here's the fix and it lives in this one line scale signature. Right now it borrows all of self. Let's change the signature. Instead of borrowing all of self, scale now asks for two fields directly X and Y as two separate references. The body still currently uses self to fetch those fields which we no longer need. So we simplify the body to just multiply X and Y. Now scale does not touch self at all. And because its signature names the two separate fields, the Rust compiler can see they do not conflict and it accepts the code. The signature says exactly what the code touches. So the golden rule is a trade.

[00:04:55]The upside is huge. Every function is checked by its signature alone. errors stay local and changing the functions body does not break its callers. And because Rust function signatures include how memory is used, the compiler can guarantee memory safety just by looking at the function signature. Something languages like Java and C cannot do. The downside is that the signature can ask for more than the body actually needs, like borrowing all of self when only one field is used. So when Rust rejects code you know is safe, do not fight the borrow checker. change the signature so it matches what the code actually touches. Once you understand that, the golden rule stops feeling restrictive and starts feeling like one of Rust's biggest strengths. Once again, this whole idea comes from Steve Clapnick's post, Rust's golden rule. It's a fantastic read and the link is in the description. And if you're interested in learning how to write production Rust, check out our Rust Live Accelerator.

[00:05:53]It's our tailored mentorship program where we help developers go beyond YouTube videos, build production-grade Rust software, and land their first Rust job. You can join the wait list for our next cohort by heading over to let's get rusty.com/join or by clicking the link in the pinned comment below. When you join the wait list, we'll also send you our Rust developer roadmap as a small gift. So tap the link join the wait list and I'll talk to you very soon.