IS 4010: Application Development with Artificial Intelligence

Week 10: The soul of Rust, ownership and borrowing

Brandon M. Greenwell

Session 1: the ownership model

Ownership is the organizing concept for this week. Build from concrete values, moves, and borrows before introducing lifetimes, and state where each analogy stops matching the implementation.

Why ownership matters: memory-safety defects

• The 2014 Heartbleed bug was an out-of-bounds read in OpenSSL
• A Microsoft Security Response Center analysis reported that memory-safety issues were a large share of the vulnerabilities it examined
• C and C++ permit low-level memory operations; safe use depends on language features, libraries, tools, and programmer discipline
• Safe Rust rejects many invalid memory-access patterns through ownership and borrowing

Heartbleed was a buffer over-read vulnerability. Use it as an example of the class of memory-access errors that safe Rust is designed to prevent; avoid implying that ownership prevents every security vulnerability.

Memory-management trade-offs

Languages make different trade-offs among:

1. Runtime overhead and predictability
2. Compile-time guarantees
3. Programmer control and implementation complexity

Examples: - Python automates memory management and accepts runtime overhead - C exposes manual memory operations and few compile-time protections - Modern C++ often uses RAII and smart pointers, while still permitting low-level operations - Rust uses ownership and borrowing to enforce many memory-safety rules in safe code without a tracing garbage collector

The important distinction is enforcement time: Rust moves many checks to compilation. That improves safety and runtime predictability, but it adds concepts that students must learn.

How Python handles memory (garbage collection)

• Python implementations manage memory automatically
• CPython primarily uses reference counting and supplements it with a cyclic garbage collector
• Most objects are reclaimed when their reference count reaches zero; the cyclic collector detects unreachable reference cycles
• Benefit: Application code rarely allocates or frees memory directly
• Trade-off: Reference counting and cycle detection add runtime and memory overhead

Keep the comparison implementation-specific. CPython, PyPy, and other Python implementations can manage memory differently, and performance should be measured for the workload rather than inferred from the language alone.

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

• C exposes manual allocation with malloc() and free()
• C++ also provides RAII, containers, and smart pointers; low-level new and delete remain available
• Benefit: Direct control over representation, allocation, and lifetime
• Risk: Low-level operations can introduce 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)

Modern C++ can reduce these risks with RAII, containers, and smart pointers. Safe Rust rules out many invalid memory-access patterns, while unsafe Rust remains available for operations the compiler cannot verify.

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
• Ownership checks themselves occur at compile time
• No garbage collector needed
• Safe Rust prevents many memory-safety errors through the type system

Ownership and borrowing are checked at compile time. In safe Rust, the type system prevents data races and many invalid memory accesses; compilation does not guarantee that the program is free of logic, security, or performance bugs.

The three ownership rules

Use these three rules as the course model for owned values in safe Rust:

1. Each value has an owner
   • A binding, collection, or other value may own its data
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

• Fixed-size values can be stored directly in a stack frame or inside another allocation
• A String value contains a pointer, length, and capacity; its text buffer is normally allocated on the heap
• Moving a String transfers that fixed-size header; the heap buffer is not duplicated
• Storage location and ownership are related concepts, but they are not the same rule

Draw one local String as a pointer-length-capacity header in the stack frame and a byte buffer on the heap. Then move the header to a new binding and mark the old binding unavailable.

The stack and heap: a cooking analogy

Think of a chef setting up their station before service (mise en place):

• The stack → your mise en place bowls: ingredients pre-measured into small glass bowls on the counter
  • Fixed, known sizes: measured precisely before cooking begins
  • Right at hand: instant access, no searching required
  • Automatically cleared when the dish is finished
• The heap → the walk-in pantry: large, flexible storage for bigger and variable quantities
  • Items vary in size: a whole bag of flour vs. a pinch of salt
  • Farther away: more effort to access and manage
  • Must be tracked carefully: leave things unlabeled and they get “forgotten” (memory leak!)

Mise en place means “everything in its place.” Use the analogy only to contrast fixed-size frame data with separately allocated buffers. Then return to the actual String representation so students do not equate Copy with stack storage or heap allocation with ownership.

From the kitchen to Rust

The analogy maps directly to Rust types:

• Mise en place bowl (fixed size, cheap to duplicate) → values such as i32, f64, and bool that implement Copy
• Pantry claim ticket plus stored item → the fixed-size header and heap buffer used by String or Vec<T>
• Handing a bowl across the counter → cheap Copy (both keep their data)
• Handing off the pantry item → move: you no longer have it, they do

State the limit of the analogy: Copy is a trait about duplication semantics, not a guarantee that a value physically resides on the stack. String and Vec contain fixed-size metadata plus owned buffers.

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, read the diagnostic, and trace which assignment moved the value. Explain why invalidating the old binding gives one owner responsibility for dropping the buffer.

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 defects can be security vulnerabilities. Safe Rust’s ownership rules prevent two ordinary owners from independently dropping the same allocation; unsafe code still requires its invariants to be reviewed.

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
• Their values have copy semantics and do not own resources that require custom cleanup
• 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 copilot 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?”

First step: Read the compiler diagnostic, identify the values and borrows it names, and then ask an AI assistant about the specific rule that remains unclear.

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.

Python permits mutation during iteration

# Goal: remove all even numbers from a list
items = [1, 2, 3, 4, 6, 7, 8]

for item in items:
    if item % 2 == 0:
        items.remove(item)  # Modifying the list while iterating!

print(items)  # Expected: [1, 3, 7]
              # Actual:   [1, 3, 6, 7]  ← 6 is never checked!

• Python runs to completion: no error, no warning, exit code 0
• When 4 is removed at index 2, the list shifts left; the iterator advances to 7, skipping 6 entirely
• This is a logic bug: the language permits the operation, so tests must detect the incorrect result

LIVE DEMO opportunity: Run this in the Python REPL and ask students to predict the output BEFORE running it. The mechanism: removing 2 (index 1) shifts the list; the iterator advances to index 2 which is now 4. Removing 4 (index 2) shifts again; the iterator advances to index 3 which is now 7, skipping 6, which has shifted into index 2. 6 is even and should have been removed but never gets checked. The bug appears whenever two consecutive removal candidates are adjacent in the list.

Why the Python loop skips an item

for item in items tracks a hidden index counter: it increments by 1 each step, unaware of any list changes:

• Index 0 → 1 (odd, skip). List: [1, 2, 3, 4, 6, 7, 8]
• Index 1 → 2 (even, remove). List: [1, 3, 4, 6, 7, 8]
• Index 2 → 4 (even, remove). List: [1, 3, 6, 7, 8]
• Index 3 → 7 (odd, skip): 6 shifted into index 2 and was never visited!
• Index 4 → 8 (even, remove). List: [1, 3, 6, 7]
• Index 5 → past end, loop stops

The counter keeps incrementing; the list keeps shifting. They fall out of sync.

This is iterator invalidation. The for loop’s index counter has no awareness that the list is changing under its feet. Every removal shifts subsequent elements left, which pushes one element into the “already visited” zone. Python never raises an error because from its perspective, the loop ran to completion normally.

Rust catches this at compile time

fn main() {
    let mut items = vec![1, 2, 3, 4, 6, 7, 8];

    for item in &items {                    // immutable borrow of `items`
        if item % 2 == 0 {
            items.retain(|x| x != item);   // ❌ ERROR: mutable borrow!
        }
    }
}

error[E0502]: cannot borrow `items` as mutable because it is also borrowed as immutable
 --> src/main.rs:6:13
  |
4 |     for item in &items {
  |                 ------  immutable borrow occurs here
...
6 |             items.retain(|x| x != item);
  |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ mutable borrow occurs here

• for item in &items takes an immutable borrow of the whole vector
• .retain() needs a mutable borrow of the same vector, at the same time
• Rust’s rule: you cannot hold both simultaneously, so this does not compile
• The logic bug that ran in Python is rejected by Rust’s borrowing rules before execution

Try it in Rust Playground

Connect this to the course borrowing rule: while an immutable borrow is in use, a conflicting mutable borrow cannot overlap it. Contrast the Python program’s incorrect output with Rust’s compile-time diagnostic, then have students identify the two operations that conflict.

Why Rust catches it

for item in &items takes an immutable borrow of the entire vector: a compile-time contract:

“This data will not change while I hold this reference.”

• Any method that mutates the vector (.retain(), .remove(), .push()) requires a mutable borrow
• You cannot hold an immutable borrow and a mutable borrow at the same time, ever
• The compiler checks this before your program runs: zero runtime overhead
• This isn’t just about iteration: the ownership system makes any aliased mutation impossible

The deeper principle: an immutable reference guarantees stability for its entire lifetime. Python’s iterator has no such guarantee: the list can change under its feet. Rust makes the contract explicit and enforced at compile time. Iterator invalidation is just one of many bugs this invariant rules out. Data races in multithreaded code are another.

The Rust way: transform instead of mutate

When Rust says no to mutating in place, it is steering you toward a cleaner pattern:

fn main() {
    let items = vec![1, 2, 3, 4, 6, 7, 8];

    let odds: Vec<i32> = items
        .into_iter()
        .filter(|x| x % 2 != 0)
        .collect();

    println!("{:?}", odds);  // ✅ [1, 3, 7], correct every time
}

• into_iter() consumes items, giving the iterator full ownership, with no borrow conflict
• .filter() selects elements without touching the original collection
• .collect() builds a fresh Vec<i32>
• Python equivalent: odds = [x for x in items if x % 2 != 0]: same idea, now enforced by the type system

Try it in Rust Playground

The borrow checker rejects mutation during iteration, which motivates a pipeline using into_iter, filter, map, and collect. Connect this pattern to the Python list comprehensions from Week 4: the data transformation is familiar, while Rust checks the borrowing rules at compile time.

Session 2: borrowing, references, and 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 and 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 binding must also be declared mut. Rust requires mutation to be explicit at the binding and borrow sites, which makes intended state changes visible in the code.

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. A reference cannot outlive the value it borrows
   • 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 and trace the overlapping mutable borrows named in the diagnostic. Explain that safe Rust rejects this pattern before it could create invalidated references.

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

Non-lexical lifetimes let the compiler end these borrows after their last use rather than at the closing brace. Ask students to move the final use of r1 below r3 and compare the diagnostic.

AI copilot 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 the compiler error carefully, 2) identify the rule, 3) use AI to explain why the rule exists, and 4) ask for an idiomatic fix. Require students to explain the final change in their own words.

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)
• Safe Rust prevents references from outliving the values they borrow

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
}

Use-after-free defects can create serious security vulnerabilities. Safe Rust rejects references that outlive the borrowed value; unsafe code and external interfaces still require separate review.

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 copilot 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 can feel abstract. Compare more than one explanation, but bring each analogy back to the concrete question: which borrowed value must remain valid, and for how long? Use Playground to test the explanation.

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

When a struct stores references, its type may need lifetime parameters that relate the struct to the borrowed data. The compiler then rejects a value that would outlive that data.

The big picture: why ownership matters

What ownership gives you: - Memory safety without garbage collection - No data races in safe Rust (enforced at compile time) - Predictable performance (no GC pauses) - Compile-time checks that usually do not add runtime work

The trade-off: - Steeper learning curve (you’re learning now!) - Resolve borrow-checker feedback while learning the ownership model - More upfront thinking about data ownership

Transfer: Ownership practice gives you another way to reason about resource lifetimes, aliases, and mutation in Python, JavaScript, and other languages.

Emphasize the transferable questions: who owns this resource, who may mutate it, and how long must a reference remain valid?

Case studies to investigate

Examples of organizations describing Rust migrations:

• Discord: Discusses latency behavior in one service migration from Go to Rust
• Dropbox: Describes design choices in a cross-platform sync engine
• npm: Reports results from selected CPU-bound services
• Microsoft: Discusses memory-safety vulnerabilities and safer systems-language research

Discussion question: Which results come from the language, the new design, the workload, or the implementation team?

Treat these as case studies, not controlled language benchmarks. Ask students to identify the baseline, workload, metric, and other changes that accompanied each rewrite.

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

This week’s lab has two parts:

1. Borrow-checker puzzles (practice)
   • Fix and run the seven commented ownership and borrowing examples
   • Interpret each compiler diagnostic
2. Implementation exercises (graded)
   • Implement to_uppercase_owned, string_length, append_suffix, and concat_strings
   • Do not modify the supplied test module
3. Required checks
   • Run cargo test, cargo fmt, and cargo clippy -- -D warnings
   • Push week10/ and confirm the matching README badge is green

Full instructions: week10/lab10.md

Part 1 is not graded automatically; part 2 and the supplied checks define the automated contract. The green Week 10 badge is the complete 10-point grade.

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

Use Rust Book Chapter 4 as the primary reference. Rustlings is optional practice, and the Rustonomicon is outside this lab’s required scope.

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: Practice ownership and borrowing. These concepts support the Rust topics that follow.

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) - Read the compiler diagnostic before deciding on a fix - Use AI assistants to deepen understanding, not to skip learning - Explain each ownership fix in terms of the value, owner, and borrow involved

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.