IS4010: AI-Enhanced Application Development

Week 10: The Soul of Rust - Ownership & Borrowing

Brandon M. Greenwell

Session 1: The Ownership Model

This is THE defining feature of Rust. Take time here - students coming from Python will find this challenging but transformative. Use analogies and build slowly. Show enthusiasm about how elegant this system is.

Housekeeping: midterm project

• Reminder: Your midterm project was due last week. If you haven’t submitted it yet, please reach out on Microsoft Teams
• This week we’re diving into what makes Rust truly unique: its ownership system
• This is the most important concept you’ll learn in Rust programming

Check in about midterm submissions. Remind students that ownership is challenging but worth the effort. This week builds the foundation for everything else in Rust.

Why ownership matters: a real-world crisis

• In 2014, the Heartbleed bug exposed millions of users’ private data due to a memory management error in OpenSSL
• 70% of security vulnerabilities in Microsoft and Google products are memory safety issues
• These bugs happen in C/C++ because programmers must manually manage memory
• Rust eliminates these entire categories of bugs at compile time with its ownership system

Real-world impact: Heartbleed was a buffer over-read vulnerability. Microsoft and Google data shows 70% of CVEs are memory issues. Rust’s ownership system makes these bugs impossible. This isn’t academic - this is career-relevant and industry-critical.

The memory management trilemma

Historically, you had to pick two out of three:

1. Performance (fast execution, low overhead)
2. Safety (no crashes, no security vulnerabilities)
3. Ease of use (simple mental model)

Traditional choices: - Python, Java: Safety + Ease → Garbage collector costs performance - C, C++: Performance + Ease → Manual memory management sacrifices safety

Rust’s innovation: Achieves all three through ownership!

This is the key insight. Rust breaks the traditional trade-off. Draw a triangle diagram on the board. Emphasize that this was thought to be impossible until Rust proved otherwise. This is why Rust is revolutionary.

How Python handles memory (garbage collection)

• Python uses a garbage collector (GC) that runs in the background
• The GC periodically scans memory to find objects that are no longer referenced
• When it finds “garbage,” it automatically frees that memory
• Pros: You never think about memory management
• Cons: GC pauses slow down your program, uses extra memory, unpredictable timing

Python’s approach: convenient but costly. GC pauses can be milliseconds to seconds depending on heap size. Fine for web apps, terrible for real-time systems (games, embedded, high-frequency trading). Show enthusiasm for how Rust solves this.

How C/C++ handles memory (manual management)

• In C/C++, you are responsible for allocating and freeing memory
• Use malloc()/new to allocate, free()/delete to deallocate
• Pros: Maximum performance and control
• Cons: Easy to make mistakes:
  • Use-after-free: Using memory after it’s been freed (security vulnerability)
  • Double-free: Freeing the same memory twice (crashes)
  • Memory leaks: Forgetting to free memory (resource exhaustion)

Manual memory management is incredibly error-prone. Even experienced C++ developers make these mistakes. These aren’t hypothetical - these cause real CVEs and production outages. Rust makes these bugs impossible.

Rust’s approach: ownership

• Rust introduces a third approach: the ownership system
• The compiler enforces ownership rules at compile time
• If your code violates these rules, it won’t compile
• No runtime overhead (zero-cost abstraction)
• No garbage collector needed
• Memory safety guaranteed by the type system

This is the big reveal. Rust’s ownership is checked entirely at compile time. Zero runtime cost. If it compiles, memory safety is guaranteed. This is why Rust is called “fearless concurrency” - you can’t accidentally create data races.

The three ownership rules

These three rules are always enforced by the Rust compiler:

1. Each value has a variable that’s called its owner
   • Every piece of data in memory has exactly one variable that owns it
2. There can only be one owner at a time
   • When you assign a value to a new variable, ownership transfers (it “moves”)
3. When the owner goes out of scope, the value is dropped
   • Rust automatically calls drop() to free the memory

Write these three rules on the board. Students will need to internalize these. Rule 2 is the most surprising to newcomers. Rule 3 is why Rust doesn’t need garbage collection. Emphasize that these are compiler-enforced - not guidelines.

Ownership in action: the stack and the heap

• Simple values like integers are stored on the stack (fast, fixed size, automatically managed)
• Complex values like String are stored on the heap (flexible size, slower, needs management)
• The stack holds the pointer, capacity, and length
• The heap holds the actual string data
• When ownership moves, the stack data moves, but heap data stays put (just the pointer changes)

Draw a memory diagram on the board. Stack on the left, heap on the right. Show how a String has three stack values (ptr, len, cap) pointing to heap data. This visual is crucial for understanding moves vs copies.

Example: ownership transfer (move)

fn main() {
    let s1 = String::from("hello");
    let s2 = s1; // Ownership moves from s1 to s2

    // println!("{}", s1); // ❌ ERROR: value borrowed after move
    println!("{}", s2); // ✅ OK: s2 owns the string now
}

Try it in Rust Playground

LIVE DEMO: Uncomment the s1 line to show the error. Read the compiler error message aloud - it’s excellent! Explain that this prevents double-free bugs. In C++, this code would crash or cause undefined behavior.

Why moves matter: preventing double-free

• If Rust allowed both s1 and s2 to be valid, both would try to free the same memory when they go out of scope
• This is a double-free error - a serious security vulnerability
• Rust prevents this by invalidating s1 after the move to s2
• The borrow checker enforces this at compile time

Double-free errors are CVE-worthy bugs in C/C++. They can be exploited to execute arbitrary code. Rust makes them impossible by design. This is the “fearless” in fearless concurrency.

The Copy trait: the exception to moves

• Simple types like i32, f64, bool, and char implement the Copy trait
• Types with Copy are copied instead of moved
• This is efficient because they live entirely on the stack (no heap allocation)
• After copying, both variables remain valid

let x = 5;
let y = x; // Copy happens (not a move)
println!("x = {}, y = {}", x, y); // ✅ Both valid!

Copy vs Move is a key distinction. Copy types are stack-only, so copying is cheap (just copy the bytes). String is NOT Copy because it has heap data. You can’t accidentally expensive operations.

🤖 AI co-pilot technique: understanding moves

When you encounter move errors, ask your AI assistant for help:

Effective prompts: - “Explain this Rust move error in simple terms: [paste error message]” - “Why does Rust move String but copy i32?” - “How do I use a value after it’s been moved?” - “What’s the difference between Copy and Clone in Rust?”

Pro tip: The Rust compiler error messages are incredibly helpful on their own - read them carefully before asking AI!

Teach students to read compiler errors first. Rust’s error messages are some of the best in any language. Then use AI to deepen understanding, not as a first resort.

Scope and automatic cleanup

• Every variable has a scope: the region of code where it’s valid
• When a variable goes out of scope, Rust automatically calls drop()
• drop() is a special function that cleans up resources (like freeing heap memory)
• This is called RAII (Resource Acquisition Is Initialization) - borrowed from C++, but enforced by the compiler in Rust

{
    let s = String::from("hello"); // s is valid here
    // use s
} // s goes out of scope, drop() is called automatically

Try it in Rust Playground

RAII is a C++ concept but Rust enforces it. This is why you rarely see explicit cleanup code in Rust. The scope determines lifetime automatically.

Session 2: Borrowing, References & Lifetimes

This builds directly on ownership. Borrowing is how we work with data without taking ownership. Students will struggle with the borrow checker at first - normalize that struggle and emphasize the error messages are your friend.

The problem: functions that take ownership

fn calculate_length(s: String) -> usize {
    s.len()
} // s is dropped here

fn main() {
    let my_string = String::from("hello");
    let len = calculate_length(my_string); // Ownership moved!
    // println!("{}", my_string); // ❌ ERROR: value borrowed after move
}

• When we pass my_string to the function, ownership moves to s
• After the function returns, we can’t use my_string anymore
• This is annoying - we just wanted to read the length!

This is the motivating problem for borrowing. Show this code and let students feel the frustration. Then introduce references as the elegant solution.

The solution: references and borrowing

• A reference lets you refer to a value without taking ownership
• References are created with the & operator
• Using references is called borrowing
• The original owner retains ownership, so the value won’t be dropped

fn calculate_length(s: &String) -> usize {
    s.len()
} // s goes out of scope, but it doesn't own the String, so nothing is dropped

fn main() {
    let my_string = String::from("hello");
    let len = calculate_length(&my_string); // Borrow, don't move
    println!("{} has length {}", my_string, len); // ✅ Still valid!
}

Try it in Rust Playground

This is the elegant solution. The ampersand syntax is borrowed from C/C++. Emphasize that references are pointers under the hood, but safe pointers checked by the compiler.

Immutable vs. mutable references

• By default, references are immutable (&T)
• You can create a mutable reference with &mut T
• Mutable references let you modify the borrowed value
• But there’s a catch… (next slide)

fn add_world(s: &mut String) {
    s.push_str(", world");
}

fn main() {
    let mut my_string = String::from("hello");
    add_world(&mut my_string);
    println!("{}", my_string); // Prints: hello, world
}

Try it in Rust Playground

Note that the variable must also be declared mut. Rust’s mutability is opt-in at every level. This is defensive by default - prevents accidental modification.

The borrowing rules (enforced by the borrow checker)

The borrow checker enforces these rules at compile time:

1. At any given time, you can have EITHER:
   • One mutable reference (&mut T)
   • OR any number of immutable references (&T)
2. References must always be valid
   • No dangling references (pointing to freed memory)

Why? These rules prevent data races at compile time!

Write these two rules on the board. Rule 1 is the “XOR” rule - mutable XOR immutable. This prevents iterator invalidation bugs (common in C++). Rule 2 prevents use-after-free bugs (also common in C++).

Borrow checker error: multiple mutable references

let mut s = String::from("hello");

let r1 = &mut s;
let r2 = &mut s; // ❌ ERROR: cannot borrow as mutable more than once

println!("{}, {}", r1, r2);

The error:

error[E0499]: cannot borrow `s` as mutable more than once at a time

• Rust prevents multiple mutable references to avoid data races
• A data race occurs when two threads access the same memory and at least one is writing
• Rust’s rule is stricter: only one mutable borrow even in single-threaded code

Try it in Rust Playground

LIVE DEMO: Show this error. Read the compiler message - it’s incredibly clear! Explain that iterator invalidation (a common C++ bug) is impossible in Rust because of this rule.

Borrow checker error: mixing mutable and immutable

let mut s = String::from("hello");

let r1 = &s;     // Immutable borrow
let r2 = &s;     // Another immutable borrow (OK)
let r3 = &mut s; // ❌ ERROR: cannot borrow as mutable

println!("{}, {}, {}", r1, r2, r3);

The error:

error[E0502]: cannot borrow `s` as mutable because it is also borrowed as immutable

• You can’t modify data while others are reading it
• This prevents “reading while writing” bugs

Try it in Rust Playground

This prevents the “reading while writing” pattern that causes bugs in other languages. Example: in C++, you might iterate over a vector while modifying it, causing a crash. Impossible in Rust.

The fix: reference scope ends at last use

• Non-Lexical Lifetimes (NLL) - a Rust 2018 improvement
• A reference’s scope ends at its last use, not at the closing brace
• This makes many common patterns “just work”

let mut s = String::from("hello");

let r1 = &s;     // Immutable borrow
let r2 = &s;     // Another immutable borrow
println!("{}, {}", r1, r2); // r1 and r2 last used here - scope ends

let r3 = &mut s; // ✅ OK: no immutable borrows are active
println!("{}", r3);

Try it in Rust Playground

NLL was a major usability improvement in Rust 2018. Before NLL, this code wouldn’t compile. Now the compiler is smart enough to see that r1 and r2 aren’t used after their last println. Celebrate this - the language is getting better!

🤖 AI co-pilot technique: debugging borrow checker errors

The borrow checker is your friend, but it takes practice. Use AI to accelerate your learning:

Effective prompts: - “Explain this borrow checker error: [paste full error message]” - “Why can’t I borrow this variable as mutable? [paste code]” - “How do I fix ‘cannot borrow as mutable more than once’?” - “What’s a dangling reference and how does Rust prevent them?”

Best practice: Read the error message first, understand the rule being violated, then ask AI for deeper insight or alternative solutions.

Teach the workflow: 1) Read compiler error carefully, 2) Try to understand the rule, 3) Use AI to explain WHY that rule exists, 4) Ask AI for the idiomatic fix. This builds understanding, not just copy-pasting.

Preventing dangling references

• A dangling reference is a pointer to memory that has been freed
• This is a critical security vulnerability in C/C++ (use-after-free)
• Rust makes dangling references impossible at compile time

fn dangle() -> &String {  // ❌ Won't compile!
    let s = String::from("hello");
    &s  // ERROR: s will be dropped, but we're returning a reference to it
} // s goes out of scope and is dropped, but the reference would point to freed memory

The fix: Return the owned value, not a reference:

fn no_dangle() -> String {  // ✅ Ownership transfers to caller
    let s = String::from("hello");
    s  // Move ownership out
}

Dangling pointers are CVE-level bugs in C/C++. They can be exploited for arbitrary code execution. Rust makes them impossible. This is a major security advantage.

Introduction to lifetimes

• Lifetimes are Rust’s way of ensuring references are always valid
• Every reference has a lifetime - the scope for which it’s valid
• Usually, the compiler can infer lifetimes automatically
• Sometimes you need to annotate them explicitly with 'a, 'b, etc.
• Lifetimes prevent dangling references at compile time

Lifetimes are often the hardest concept for new Rustaceans. Emphasize that the compiler usually handles this automatically. When you do need to annotate, it’s because you have multiple references and the compiler needs clarity.

Why lifetimes exist: a problematic example

fn longest(x: &str, y: &str) -> &str {  // ❌ Won't compile!
    if x.len() > y.len() {
        x
    } else {
        y
    }
}

The error:

error[E0106]: missing lifetime specifier
  --> src/main.rs:1:33
   |
1  | fn longest(x: &str, y: &str) -> &str {
   |               ----     ----     ^ expected named lifetime parameter

• The compiler doesn’t know if the returned reference comes from x or y
• It can’t verify the returned reference will be valid
• We need to tell the compiler about the relationship between input and output lifetimes

This is THE classic lifetime example. Don’t skip this. The error message is excellent - read it aloud. Explain that the compiler is asking “how long is this returned reference valid?”

Lifetime annotations: the solution

fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
    if x.len() > y.len() {
        x
    } else {
        y
    }
}

• 'a is a lifetime parameter
• It says: “the returned reference will live as long as the shortest-lived input”
• If x lives longer than y, the return value’s lifetime is tied to y (the shorter one)
• The borrow checker uses this to ensure safety

Try it in Rust Playground

Lifetimes are descriptive, not prescriptive. We’re not changing how long things live - we’re describing the relationships so the compiler can verify safety. The 'a syntax is intimidating but it’s just a label.

When you need lifetime annotations

You typically need lifetime annotations when:

1. Function returns a reference that came from one of multiple input references
2. Structs contain references (struct must not outlive the referenced data)
3. Multiple references with complex relationships where the compiler can’t infer

Good news: In most code, lifetimes are inferred automatically thanks to lifetime elision rules

Emphasize that most Rust code doesn’t need explicit lifetime annotations. The compiler is very smart. When you do need them, the error messages will guide you. Don’t let lifetimes intimidate students - they’re rarer than they think.

🤖 AI co-pilot technique: understanding lifetimes

Lifetimes can be confusing. Use AI to build intuition:

Effective prompts: - “Explain Rust lifetimes like I’m coming from Python” - “Why does this code need a lifetime annotation? [paste code]” - “What does ‘a mean in this function signature? [paste signature]“ - ”How do I fix ’lifetime may not live long enough’?” - “When can I omit lifetime annotations in Rust?”

Pro tip: Use Rust Playground to experiment. Change code, see errors, ask AI to explain the errors.

Lifetimes are abstract. AI can provide multiple explanations and analogies until one clicks. Encourage iterative learning: try → error → AI explanation → try again. Playground is perfect for this.

Lifetimes in structs

struct Excerpt<'a> {
    text: &'a str,  // This reference must be valid as long as the Excerpt exists
}

fn main() {
    let novel = String::from("Call me Ishmael. Some years ago...");
    let first_sentence = novel.split('.').next().unwrap();
    let excerpt = Excerpt { text: first_sentence };
    println!("{}", excerpt.text);
} // excerpt and novel both go out of scope here (OK: excerpt doesn't outlive novel)

• When a struct contains a reference, we must annotate the lifetime
• 'a says: “this struct can’t live longer than the data it references”
• The borrow checker enforces that novel outlives excerpt

Try it in Rust Playground

Structs with references are less common than owned data. But when you need them, lifetimes are essential. This prevents the struct from outliving the data it points to.

The big picture: why ownership matters

What ownership gives you: - Memory safety without garbage collection - No data races (guaranteed at compile time) - Predictable performance (no GC pauses) - Zero-cost abstractions (compile-time checks, zero runtime overhead)

The trade-off: - Steeper learning curve (you’re learning now!) - Fight the borrow checker (initially - then you’ll think differently) - More upfront thinking about data ownership

Career insight: Once you understand ownership, you’ll write better code in every language. You’ll think about memory and references more carefully even in Python or JavaScript.

This is the payoff slide. Emphasize that fighting the borrow checker is temporary. Once you internalize these concepts, you’ll write better code everywhere. This is transferable knowledge.

Real-world performance wins

Examples of Rust’s ownership system delivering real results:

• Discord: Switched from Go to Rust, reduced latency spikes from seconds to milliseconds (10x improvement)
• Dropbox: Rewrote sync engine in Rust, reduced memory usage by 2x, improved performance
• npm: Rewrote CPU-heavy services in Rust, 10x performance improvement
• Microsoft: Using Rust in Windows to prevent 70% of security vulnerabilities

The common thread: No garbage collector + memory safety = high performance + security

These are real stories, not marketing. Discord’s blog post is excellent - show it to students. npm’s case study shows 10x improvements. Microsoft’s 70% figure is from their security team. This is industry validation.

Try it yourself: borrow checker challenges

Challenge 1: Fix the ownership error Rust Playground Link

Challenge 2: Fix the borrowing error Rust Playground Link

Challenge 3: Fix the dangling reference Rust Playground Link

Give students 5-10 minutes to work through these. Walk around and help. Encourage them to read the error messages carefully. These are the three most common borrow checker errors.

Introducing Lab 10: ownership and borrowing mastery

This week’s lab has two parts:

1. The Borrow Checker Game
   • Fix 5-7 progressively challenging ownership and borrowing errors
   • Learn to interpret compiler error messages
   • Practice the fix-compile-test cycle
2. Hands-on Ownership Exercises
   • Implement functions demonstrating ownership concepts
   • Work with references and borrowing patterns
   • Test your understanding with cargo test

Full instructions: labs/lab10/README.md

Lab 10 is all about practice with the borrow checker. Part 1 is diagnostic - can you read errors and fix them? Part 2 is constructive - can you write correct code from scratch? Both essential skills.

Resources for going deeper

Official Rust resources: - The Rust Programming Language book - Chapter 4 (Ownership) - The Rust Programming Language book - Chapter 10 (Lifetimes) - Rust by Example - Ownership - The Rustonomicon - Advanced ownership

Interactive learning: - Rust Playground - experiment in your browser - Rustlings - small exercises to get you used to reading and writing Rust code

Community: - r/rust - Rust subreddit - The Rust Programming Language Discord

The Rust book Chapter 4 is essential reading. Rustlings is excellent for practice. The community is friendly and helpful - encourage students to engage. The Rustonomicon is advanced - mention it but don’t overwhelm students yet.

Looking ahead: next week

Week 11 preview: structs, enums, and pattern matching - Creating custom data types with struct - Rust’s powerful enum type - Pattern matching with match - AI-assisted data modeling strategies

For now: Focus on mastering ownership and borrowing. These concepts underpin everything else in Rust!

Next week builds on this foundation. Everything in Rust flows from ownership. Structs and enums are easier once ownership is clear. Encourage students to struggle with the borrow checker this week - it’s normal and valuable.

Questions?

Remember: - The borrow checker is your friend (even when it feels like your enemy) - Compiler error messages are incredibly helpful - read them carefully - Use AI assistants to deepen understanding, not to skip learning - Fighting with Rust now makes you a better programmer forever

Office hours: Available on Microsoft Teams - reach out anytime!

End on an encouraging note. Ownership is hard but worth it. Normalize the struggle. Remind them you’re available for help. This is the most important concept in the entire Rust portion of the course.