fn area(width: u32, height: u32) -> u32 {
    width * height
}

And something felt off. Not wrong — it works. But it smells. Width and height clearly belong together. They're describing the same thing. Why are they just floating around as separate arguments like two strangers at a party who definitely know each other?

That's when structs clicked for me.

What Is a Struct, Really?

Think of a struct like a form. A user registration form has fields: name, email, whether the account is active. Those fields don't make sense in isolation — they belong together under the concept of "a user." A struct is how you express that grouping in Rust.

Where tuples let you group things by position ((30, 50) — wait, which one is width?), structs let you group things by name. That's the core win.

Here's the User struct I practiced with:

struct User {
    username: String,
    email: String,
    sign_in_count: u64,
    active: bool,
}

Different types, named fields, grouped under one concept. Instantly more readable than a tuple of (String, String, u64, bool).

Creating and Using Instances

Once you have a struct defined, you create instances of it. Each instance fills in the actual values for those fields:

let mut user1 = User {
    email: String::from("padfoot@gmail.com"),
    username: String::from("padfoot"),
    sign_in_count: 1,
    active: true,
};

Fields don't have to go in declaration order — Rust doesn't care. Access them with dot notation:

let name = user1.username;

And if you marked the instance mut, you can update fields the same way:

user1.username = String::from("0x12md10");

One important thing I noticed: mutability is all-or-nothing on the whole struct. You can't say "only this field is mutable." Either the whole instance is mut or none of it is.

Build Functions and Field Init Shorthand

Often you'll want a constructor-style function to build instances. I wrote one called build_user:

fn build_user(email: String, username: String) -> User {
    User {
        email,
        username,
        active: true,
        sign_in_count: 1,
    }
}

Notice anything about email and username in the struct literal? No email: email — just email. When a function parameter has the same name as the struct field, Rust lets you use the field init shorthand and skip the redundant assignment. It's a small thing but it removes a lot of visual noise when you have many fields.

Struct Update Syntax

Another handy feature: creating a new instance from an existing one, only overriding what's different.

let user2 = build_user(String::from("harry@gmail.com"), String::from("Harry"));
 
let user3 = User {
    email: String::from("BruceW@gmail.com"),
    username: String::from("Bruce Wayne"),
    ..user2
};

The ..user2 says: "for any fields I haven't specified, copy them from user2." So user3 gets active and sign_in_count from user2. Clean.

Tuple Structs: Named Tuples

Sometimes you want a tuple to have a type name — so you can distinguish a Color from a Point even when they have the same shape.

struct Color(i32, i32, i32);
struct Point(i32, i32, i32);

Both have three i32s. But they're different types. A function expecting a Point won't accept a Color. This is useful when type safety matters more than field names.

The Rectangle Refactor: Why Structs Actually Matter

This is where things got concrete for me. I started with this:

fn main() {
    let width1 = 30;
    let height1 = 50;
    println!("Area: {}", area(width1, height1));
}
 
fn area(width: u32, height: u32) -> u32 {
    width * height
}

It works. But width1 and height1 are just floating variables with no relationship expressed in code. I refactored through tuples first:

let rect = (30, 50);
 
fn area(dimensions: (u32, u32)) -> u32 {
    dimensions.0 * dimensions.1
}

Better — one variable now. But dimensions.0 vs dimensions.1? Which is width again? The code lost meaning in the process.

The final version with a struct is clearly the best:

#[derive(Debug)]
struct Rectangle {
    width: u32,
    height: u32,
}
 
fn main() {
    let rect = Rectangle { width: 30, height: 50 };
    println!("Area: {}", area(&rect));
}
 
fn area(rectangle: &Rectangle) -> u32 {
    rectangle.width * rectangle.height
}

Named fields. A real type. And notice we're passing &rect — a reference — because we want to use the rectangle without taking ownership of it. The function just borrows it.

Printing Structs with #[derive(Debug)]

When I tried to println! a struct, Rust immediately complained:

`Rectangle` doesn't implement `std::fmt::Display`

Primitive types know how to display themselves. Custom structs don't — there's no single "right" way to format them. But Rust gives you a shortcut for debug-style printing:

1. Add #[derive(Debug)] above the struct
2. Use {:?} in the format string (or {:#?} for pretty-printed multiline output)

#[derive(Debug)]
struct Rectangle { width: u32, height: u32 }
 
println!("rect: {:?}", rect);   // compact
println!("rect: {:#?}", rect);  // pretty

#[derive(Debug)] tells the compiler to auto-generate a Debug implementation for you. You'll use this constantly while building things out.

Methods: Attaching Behavior to Your Struct

Here's the real power move. That area function is intimately tied to Rectangle — but it's defined separately, hanging out in the global scope. Methods let you attach it directly to the struct using an impl block:

impl Rectangle {
    fn area(&self) -> u32 {
        self.width * self.height
    }
}

The first parameter is always &self — a reference to the instance the method is called on. Now you call it like:

println!("Area: {}", rect.area());

Much cleaner. And it makes the relationship explicit: area belongs to Rectangle.

I also wrote a can_hold method that takes another rectangle as an argument:

impl Rectangle {
    fn can_hold(&self, other: &Rectangle) -> bool {
        self.width > other.width && self.height > other.height
    }
}

Two parameters: self (the current instance) and other (a borrowed reference to another Rectangle). Usage:

if rect.can_hold(&rect1) {
    println!("Current rectangle can hold the other.");
} else {
    println!("Current rectangle cannot hold the other.");
}

Rust handles the referencing and dereferencing automatically when you call methods — you don't need different syntax for calling a method on a value vs. a pointer like you would in C++.

Associated Functions: The Struct's Static Methods

Not everything in an impl block needs to be a method. Associated functions don't take self as a parameter — they're tied to the type, not to an instance. The most common use is constructors.

impl Rectangle {
    fn square(size: u32) -> Rectangle {
        Rectangle {
            width: size,
            height: size,
        }
    }
}

You call this with :: syntax, not dot notation:

let rect2 = Rectangle::square(2);

String::from(...) is an associated function. Vec::new() is an associated function. Now you know what that :: means.

You can have multiple impl blocks for the same struct — Rust allows it. Normally you'd keep everything in one, but it becomes useful with generics and traits (a later chapter).

Bringing It All Together

Here's the final version of the Rectangle code from my practice session:

#[derive(Debug)]
struct Rectangle {
    width: u32,
    height: u32,
}
 
impl Rectangle {
    fn area(&self) -> u32 {
        self.width * self.height
    }
 
    fn can_hold(&self, other: &Rectangle) -> bool {
        self.width > other.width && self.height > other.height
    }
}
 
impl Rectangle {
    fn square(size: u32) -> Rectangle {
        Rectangle {
            width: size,
            height: size,
        }
    }
}
 
fn main() {
    let rect = Rectangle { width: 30, height: 50 };
    let rect1 = Rectangle { width: 20, height: 30 };
    let rect2 = Rectangle::square(2);
 
    println!("rect2: {:#?}", rect2);
    println!("Area: {} square pixels.", rect.area());
 
    if rect.can_hold(&rect1) {
        println!("rect can hold rect1.");
    } else {
        println!("rect cannot hold rect1.");
    }
}

From two scattered variables to a named type with behavior — that's the struct journey.

Key Takeaways

• Structs group related data with named fields, making your code self-documenting. Prefer them over tuples when fields have distinct meaning.
• Methods live in impl blocks and always take &self (or &mut self) as the first parameter. Call them with dot notation.
• Associated functions (no self) are called with :: syntax — use them for constructors and type-level utilities like Rectangle::square(5).

References

• The Rust Book, Chapter 5: https://doc.rust-lang.org/book/ch05-00-structs.html

You've written C++ long enough to have a sixth sense for use-after-free bugs. Or maybe you come from Python or JavaScript and you've never had to think about memory at all. Either way, when you first touch Rust, something weird happens: the compiler yells at you for code that looks completely fine.

let s1 = String::from("hello");
let s2 = s1;
println!("{}", s1); // ❌ compiler error

"What do you mean s1 isn't available? I literally just defined it two lines ago."

That confusion is the exact thing this post will untangle.

The Problem Rust Is Solving

Before we get into the rules, let's understand why they exist.

In languages with a garbage collector (Java, Python, Go), the runtime tracks all memory references and cleans up when nothing points to a value anymore. It's safe, but it costs runtime overhead and introduces unpredictable pauses.

In C/C++, you manage memory yourself. Powerful, fast — and a landmine field. Use a pointer after the memory is freed? That's a bug. Free the same memory twice? Also a bug. Forget to free? Memory leak.

Rust's answer: enforce memory safety at compile time, with zero runtime cost. The mechanism it uses is called ownership.

The Three Rules (Burn These Into Your Brain)

Rust's ownership system is built on exactly three rules:

1. Each value has exactly one owner — a variable that "owns" it.

2. There can only be one owner at a time.

3. When the owner goes out of scope, the value is dropped (memory freed). That's it. The entire system flows from these three rules. They're simple to state, but their implications take a while to fully absorb.

Stack vs. Heap: Why It Matters Here

Here's an analogy: think of the stack as a notepad on your desk. You jot down a number, use it, cross it off. Fast, local, self-managing.

The heap is more like a storage unit you rent. You put your stuff in, you get a key (a pointer). Someone has to be responsible for returning that key and clearing out the unit when you're done — otherwise you're paying forever for space you're not using.

In Rust:

• Simple scalar types (i32, bool, f64, etc.) live on the stack. Copying them is trivially cheap, so Rust just copies them automatically.

• Types like String and Vec involve heap allocation. Copying them isn't free, so Rust doesn't do it silently. This is why this works just fine:

let x = 5;
let y = x; // x is copied — integers live on the stack
println!("{}", x); // ✅ x still works

But this doesn't:

let s1 = String::from("hello");
let s2 = s1; // s1 is *moved* into s2 — Strings live on the heap
println!("{}", s1); // ❌ s1 is gone

When you assign s1 to s2, Rust doesn't copy the heap data — that could be expensive and surprising. Instead, it moves the ownership. s1 is now considered invalid. There is still only one owner (rule #2), and it's now s2.

But What If I Actually Want a Copy?

Use .clone(). It's explicit, and explicit is good — you're acknowledging "yes, I want to pay the cost of a full deep copy here":

let s1 = String::from("hello");
let s2 = s1.clone(); // deep copy of heap data
 
println!("{} and {}", s1, s2); // ✅ both work

The explicitness is intentional. In Rust, expensive operations are never silent.

Ownership and Functions

The same rules apply when you pass values into functions. A function that takes ownership of its argument is like a black hole — the value goes in, and the caller can't use it anymore:

fn main() {
    let s = String::from("hello");
    takes_ownership(s);
    println!("{}", s); // ❌ s was moved into the function
}
 
fn takes_ownership(some_string: String) {
    println!("{}", some_string);
} // some_string is dropped here

Integers, of course, are fine — they're stack values, so they're always copied:

fn main() {
    let x = 5;
    makes_copy(x);
    println!("{}", x); // ✅ x was copied, not moved
}
 
fn makes_copy(some_integer: i32) {
    println!("{}", some_integer);
}

You can also get ownership back from a function by returning the value:

fn gives_ownership() -> String {
    let some_string = String::from("hello");
    some_string // moved to the caller
}
 
fn takes_and_gives_back(a_string: String) -> String {
    a_string // moved right back out
}

This works, but passing ownership in and out just to use a value is clunky. Rust has a better answer.

References: Borrow Without Taking

Most of the time, you don't want to give up ownership — you just want to use a value for a bit. That's what references are for. Passing a reference is called borrowing.

fn main() {
    let s1 = String::from("hello");
    let len = calculate_length(&s1); // we're lending s1, not giving it away
    println!("The length of '{}' is {}.", s1, len); // ✅ s1 still here
}
 
fn calculate_length(s: &String) -> usize {
    s.len()
} // s goes out of scope, but since it doesn't own anything, nothing is dropped

The & means "reference to". The function borrows s1, uses it, and gives it back implicitly when it's done. s1 never stopped being owned by main.

Think of it like lending someone your car keys. They can drive your car. They can't sell it. When they're done, you still have it.

Mutable References

By default, borrowed references are immutable. If you want the borrower to be able to change the value, you need a mutable reference:

fn main() {
    let mut s1 = String::from("hello"); // the variable itself must be mut
    change(&mut s1); // pass a mutable reference
}
 
fn change(some_string: &mut String) {
    some_string.push_str(", world");
}

Two things to note:

• The variable must be declared mut.

• You explicitly opt into mutability with &mut.

The Golden Rule of Mutable References

Here's where Rust gets strict in a way that confuses almost everyone at first: you can only have one mutable reference to a value at a time.

let mut s = String::from("hello");
 
let r1 = &mut s;
let r2 = &mut s; // ❌ compiler error: cannot borrow `s` as mutable more than once

And you can't have a mutable reference while an immutable reference is also alive:

let mut s = String::from("hello");
 
let r1 = &s;      // immutable reference
let r2 = &s;      // also fine — multiple immutable references are allowed
let r3 = &mut s;  // ❌ error: can't mutate while immutable references exist

Multiple immutable references? Fine. Everyone's just reading — no conflict.
One mutable reference? Fine. One writer, exclusive access.
Mix of both, or multiple mutable references? Hard no. This is a data race waiting to happen.

This is Rust preventing a whole class of bugs — the kind that ruin your afternoon in C++ when two threads are both mutating the same object and you get mysterious corruption. Rust makes that impossible to compile.

Quick Reference: The Rules in Practice

The Takeaways

If you read nothing else, remember these three things:

1. Move semantics are the default for heap values. Assignment, passing to a function — these transfer ownership. If you need the original, .clone() it or use a reference.

2. References let you use a value without owning it. The & operator borrows. Mutable borrows need &mut — and the variable itself must also be mut.

3. Rust's aliasing rules prevent data races at compile time. One mutable reference or many immutable references — never both at the same time. This feels annoying at first and then feels like a superpower once you've been saved by it. Ownership is the hardest mental shift when learning Rust, and also the most rewarding. Once it clicks, you stop fighting the compiler and start reading its errors like useful hints from a very strict, very helpful colleague.

Reference: The Rust Programming Language (a.k.a. "The Book")