IS4010: AI-Enhanced Application Development

Week 11: Structuring Code and Data in Rust

Brandon M. Greenwell

Session 1: Organizing Code and Custom Types

This week builds directly on ownership fundamentals from Week 10. Students now know how memory works in Rust - today they learn how to structure programs and data. Start with motivation: “You can write Rust code - now let’s organize it like professionals do.”

Housekeeping: Lab 10 check-in

• Lab 10 (Ownership & Borrowing) was due last Sunday
• How did the borrow checker game go?
• This week builds on those concepts - structs and enums follow ownership rules
• Lab 11 due Sunday, November 16 - data modeling with structs/enums/collections

Quick check-in about Lab 10. Normalize that the borrow checker is challenging. Today’s content applies ownership to real data structures. Emphasize that understanding ownership makes everything else easier.

From small scripts to real programs

• So far, we’ve written small Rust programs in a single main.rs file
• Real applications need organization: separate files, logical grouping, reusable components
• Rust’s module system provides powerful tools for structuring code
• Today we learn how professionals organize Rust projects

Transition from “can you write Rust?” to “can you organize Rust?” Students have the fundamentals - now we scale up to real programs. The module system is Rust’s answer to organization.

The Rust module system hierarchy

Three levels of organization:

1. Packages - A Cargo feature that builds, tests, and shares crates
2. Crates - A tree of modules that produces a library or executable
3. Modules - Let you control organization, scope, and privacy

Think of it like: Package = project, Crate = building, Modules = rooms

The hierarchy confuses newcomers. Use the building analogy: package is the whole project, crate is a library or binary, modules are logical divisions. We’ll focus on modules today since that’s what students will use most.

Creating modules with mod

// src/main.rs
mod front_of_house {
    pub mod hosting {
        pub fn add_to_waitlist() {
            println!("Adding to waitlist");
        }
    }

    mod serving {
        fn take_order() {
            println!("Taking order");
        }
    }
}

fn main() {
    front_of_house::hosting::add_to_waitlist();
    // front_of_house::serving::take_order(); // ❌ ERROR: private!
}

Try it in Rust Playground

LIVE DEMO: Show module definition with mod. Explain pub keyword - everything is private by default. Show the path syntax with ::. Try calling serving::take_order() to show the error. Privacy is the default - you opt into public APIs.

Privacy in Rust: default private

• Everything is private by default in Rust modules
• Use pub keyword to make items public
• Privacy rules:
  • Parent modules can’t see into child private items
  • Child modules can see everything in parent modules
  • Sibling modules can see each other’s public items
• This is defensive design - explicit about your public API

Contrast with Python where everything is public by convention. Rust enforces privacy at compile time. This prevents accidental dependencies on internal implementation details. It’s about intentional design.

The use keyword: bringing paths into scope

mod front_of_house {
    pub mod hosting {
        pub fn add_to_waitlist() {
            println!("Added!");
        }
    }
}

// Bring the module into scope
use front_of_house::hosting;

fn main() {
    hosting::add_to_waitlist(); // Much cleaner!
    // No need for full path: front_of_house::hosting::add_to_waitlist()
}

Try it in Rust Playground

‘use’ is like Python’s import or Java’s import. It creates shortcuts. Note the idiomatic pattern: bring the parent module into scope, not the function itself. This makes it clear where functions come from.

Separating modules into files

Project structure:

src/
├── main.rs
├── front_of_house.rs
└── front_of_house/
    ├── hosting.rs
    └── serving.rs

In main.rs:

mod front_of_house; // Tells Rust to look for front_of_house.rs

use front_of_house::hosting;

fn main() {
    hosting::add_to_waitlist();
}

Real projects split modules into separate files. The ‘mod’ declaration without braces tells Rust to load from a file. This is how professional Rust code is organized. The file system mirrors the module tree.

🤖 AI co-pilot technique: module organization

When organizing code into modules, ask your AI assistant:

Effective prompts: - “How should I organize this Rust project into modules? [describe project]” - “What should be public vs private in this module? [paste code]” - “Explain the difference between ‘use’ and ‘mod’ in Rust” - “Help me split this large main.rs into separate modules”

Pro tip: Ask AI to explain the module tree structure - visualizations help!

Module organization is a design skill. AI can suggest logical groupings and explain privacy trade-offs. Students should use AI to learn patterns, not just copy structure. Understanding module design makes code maintainable.

Defining custom data with struct

• A struct (structure) groups related data into a single, meaningful type
• Like Python classes but data only (methods come separately)
• Three kinds:
  1. Named-field structs - most common
  2. Tuple structs - fields accessed by position
  3. Unit structs - no fields (rare)

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

Structs are how you model domain concepts in Rust. Coming from Python, think of them as the data part of a class. The separation of data and behavior is intentional - Rust favors composition.

Creating struct instances

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

fn main() {
    let user1 = User {
        email: String::from("ada@example.com"),
        username: String::from("ada_lovelace"),
        active: true,
    };

    println!("Username: {}", user1.username);

    // Make mutable to change fields
    let mut user2 = User {
        email: String::from("grace@example.com"),
        username: String::from("grace_hopper"),
        active: true,
    };
    user2.email = String::from("new_email@example.com");
}

Try it in Rust Playground

LIVE DEMO: Create a struct instance. Show that the entire struct must be mutable to change any field - Rust doesn’t have per-field mutability. This is consistent with Rust’s ownership model.

Adding behavior with impl blocks

struct Rectangle {
    width: u32,
    height: u32,
}

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

    // Associated function (no self) - like a static method
    fn square(size: u32) -> Rectangle {
        Rectangle {
            width: size,
            height: size,
        }
    }
}

fn main() {
    let rect = Rectangle { width: 30, height: 50 };
    println!("Area: {}", rect.area());

    let sq = Rectangle::square(10);
}

Try it in Rust Playground

impl blocks add methods to structs. Methods take self (or &self or &mut self). Associated functions don’t take self - they’re like constructors or static methods. You can have multiple impl blocks for organization.

Modeling choices with enum

• An enum (enumeration) represents a value that can be one of several variants
• Much more powerful than enums in C, Java, or Python
• Each variant can hold different types of data
• Perfect for modeling “this OR that OR that” situations

enum IpAddr {
    V4(u8, u8, u8, u8),
    V6(String),
}

let home = IpAddr::V4(127, 0, 0, 1);
let loopback = IpAddr::V6(String::from("::1"));

Rust enums are algebraic data types - they’re incredibly powerful. Each variant is like a different struct. This is different from C-style enums which are just named integers. Use enums to model mutually exclusive possibilities.

Pattern matching with match

enum Coin {
    Penny,
    Nickel,
    Dime,
    Quarter(String), // Quarter holds state name
}

fn value_in_cents(coin: Coin) -> u8 {
    match coin {
        Coin::Penny => 1,
        Coin::Nickel => 5,
        Coin::Dime => 10,
        Coin::Quarter(state) => {
            println!("Quarter from {}!", state);
            25
        }
    }
}

fn main() {
    let my_coin = Coin::Quarter(String::from("Alaska"));
    println!("Value: {} cents", value_in_cents(my_coin));
}

Try it in Rust Playground

LIVE DEMO: Show match with enums. Emphasize that match is exhaustive - you must handle every variant. The compiler enforces this. Pattern matching extracts data from variants. This prevents forgotten cases that cause bugs in other languages.

🤖 AI co-pilot technique: designing with structs and enums

When modeling data, ask your AI assistant:

Effective prompts: - “Should I use a struct or enum for this? [describe data]” - “Help me model a [domain concept] in Rust with structs and enums” - “What fields should this struct have? [describe requirements]” - “Show me how to use match to handle all cases of this enum”

Example: “I need to model a blog post that can be Draft, Published, or Archived. Each state has different data. How should I structure this in Rust?”

Data modeling is a design skill. AI can suggest struct vs enum trade-offs and show idiomatic patterns. Ask AI to explain the reasoning, not just provide code. Understanding design choices makes better Rust developers.

Session 2: Error Handling and Collections

Second session builds on structs/enums. Now we use two special enums (Option and Result) and work with dynamic collections. Emphasize that these aren’t “advanced” - they’re everyday Rust. Tie to ownership from last week.

The problem with null

• In Python, Java, C++, variables can be None/null
• This causes billions of dollars in bugs: Tony Hoare calls it his “billion-dollar mistake”
• The problem: you can forget to check for null, causing crashes
• Rust’s solution: no null - instead, use Option<T>

Null reference errors are among the most common bugs. Tony Hoare invented null and regrets it. Rust eliminates this entire category of bugs by making “might not exist” explicit in the type system.

Option<T>: handling optional values

enum Option<T> {
    Some(T),
    None,
}

fn find_user(id: u32) -> Option<String> {
    if id == 1 {
        Some(String::from("Alice"))
    } else {
        None
    }
}

fn main() {
    match find_user(1) {
        Some(name) => println!("Found: {}", name),
        None => println!("User not found"),
    }

    // Shorthand with if let
    if let Some(name) = find_user(2) {
        println!("Found: {}", name);
    } else {
        println!("User not found");
    }
}

Try it in Rust Playground

LIVE DEMO: Show Option in action. The type system forces you to handle the None case - you can’t forget. Show both match and if let patterns. if let is syntactic sugar for matching one pattern and ignoring others.

Result<T, E>: recoverable errors

enum Result<T, E> {
    Ok(T),
    Err(E),
}

use std::fs::File;
use std::io::ErrorKind;

fn open_config() -> Result<File, std::io::Error> {
    File::open("config.txt")
}

fn main() {
    match open_config() {
        Ok(file) => println!("Opened file successfully"),
        Err(error) => match error.kind() {
            ErrorKind::NotFound => println!("File not found!"),
            other => println!("Error opening file: {:?}", other),
        },
    }
}

Try it in Rust Playground

Result is for operations that can fail. Like Option, the type system forces you to handle errors. No more forgotten try/catch! You can nest matches to handle specific error types. This is much safer than exceptions.

The ? operator: error propagation

use std::fs::File;
use std::io::{self, Read};

fn read_username_from_file() -> Result<String, io::Error> {
    let mut file = File::open("username.txt")?; // ❓ propagates error if Err
    let mut username = String::new();
    file.read_to_string(&mut username)?;        // ❓ propagates error if Err
    Ok(username)                                  // ✅ returns Ok if success
}

// Without ? operator, this would be:
// match File::open("username.txt") {
//     Ok(mut file) => match file.read_to_string(&mut username) {
//         Ok(_) => Ok(username),
//         Err(e) => Err(e),
//     },
//     Err(e) => Err(e),
// }

The ? operator is syntactic sugar for error propagation. If Result is Err, it returns early with that error. If Ok, it unwraps the value and continues. This makes error handling code much cleaner. It’s like try/catch but explicit in types.

🤖 AI co-pilot technique: error handling patterns

When handling errors, ask your AI assistant:

Effective prompts: - “When should I use Option vs Result in Rust?” - “Help me handle this error idiomatically: [paste code]” - “Explain the ? operator and when I can use it” - “Convert this match error handling to use ? operator”

Pro tip: Ask AI to show both verbose (match) and concise (? operator) versions to understand what’s happening under the hood.

Error handling patterns take practice. AI can show idiomatic approaches and explain trade-offs. Students should understand both match and ? operator - ? is sugar for match patterns. Ask AI to explain, not just provide code.

Common collections: Vec<T>

• Vec<T> (vector) is a growable array - like Python’s list
• Stores values of the same type
• Allocated on the heap (flexible size)
• Most common collection in Rust

fn main() {
    // Creating vectors
    let mut v: Vec<i32> = Vec::new();
    let mut v2 = vec![1, 2, 3]; // vec! macro for initial values

    // Adding elements
    v.push(5);
    v.push(6);

    // Accessing elements
    let third = &v2[2];         // Panics if out of bounds
    let maybe_third = v2.get(2); // Returns Option<&T>

    // Iterating
    for i in &v2 {
        println!("{}", i);
    }
}

Try it in Rust Playground

LIVE DEMO: Show Vec creation, push, indexing, and iteration. Explain the two ways to access: [] panics if out of bounds, .get() returns Option. This ties back to Option from earlier. Vectors follow ownership rules - you can’t modify while iterating immutably.

Strings in Rust: String vs &str

• Rust has two main string types (not one!):
• String - Owned, growable, heap-allocated (like Vec<u8>)
• &str - String slice, borrowed, immutable view
• All strings are UTF-8 encoded

fn main() {
    // String - owned
    let mut s = String::from("hello");
    s.push_str(" world"); // Can modify

    // &str - borrowed string slice
    let slice: &str = &s[0..5]; // "hello"

    // String literals are &str
    let literal = "I'm a &str";

    // Converting
    let s2: String = literal.to_string();
    let slice2: &str = &s2;
}

Try it in Rust Playground

String vs &str confuses everyone. String is owned data, &str is a view into string data. Think: String is like Vec, &str is like &[u8]. String literals in code are &str with ’static lifetime. This follows ownership from Week 10.

HashMap<K, V>: key-value storage

use std::collections::HashMap;

fn main() {
    // Creating
    let mut scores = HashMap::new();

    // Inserting
    scores.insert(String::from("Blue"), 10);
    scores.insert(String::from("Yellow"), 50);

    // Accessing
    let team_name = String::from("Blue");
    let score = scores.get(&team_name);  // Returns Option<&V>

    match score {
        Some(&s) => println!("Score: {}", s),
        None => println!("Team not found"),
    }

    // Iterating
    for (key, value) in &scores {
        println!("{}: {}", key, value);
    }
}

Try it in Rust Playground

LIVE DEMO: Show HashMap creation, insertion, and lookup. Note that .get() returns Option - the key might not exist! HashMap owns its keys and values. When you insert, ownership moves into the HashMap. This is consistent with ownership rules.

Choosing the right collection

Vec<T> - Use when: - You need an ordered list - You want to access by index - You’ll add/remove from the end

String - Use when: - You need owned, growable text - Building strings dynamically

HashMap<K, V> - Use when: - You need key-value lookups - Order doesn’t matter - Fast access by key is important

Choosing collections is a design decision. Vec for lists, HashMap for lookups, String for text. These cover 95% of use cases. There are other collections (BTreeMap, HashSet, etc.) but start with these three. Ask yourself: How will I access this data?

Real-world example: building a phone book

use std::collections::HashMap;

struct Contact {
    name: String,
    phone: String,
    email: Option<String>, // Email is optional
}

fn main() {
    let mut phone_book: HashMap<String, Contact> = HashMap::new();

    phone_book.insert(
        String::from("Alice"),
        Contact {
            name: String::from("Alice Smith"),
            phone: String::from("555-1234"),
            email: Some(String::from("alice@example.com")),
        }
    );

    // Look up by name
    if let Some(contact) = phone_book.get("Alice") {
        println!("Phone: {}", contact.phone);
        if let Some(email) = &contact.email {
            println!("Email: {}", email);
        }
    }
}

Try it in Rust Playground

This example ties everything together: struct for Contact, Option for optional email, HashMap for storage, if let for handling Options. This is how real Rust programs are structured. Show students this is production-quality code.

🤖 AI co-pilot technique: working with collections

When using collections, ask your AI assistant:

Effective prompts: - “Which Rust collection should I use for [describe use case]?” - “Help me convert this Python list comprehension to Rust: [paste code]” - “Show me how to iterate over a HashMap in Rust” - “How do I handle the Option returned by HashMap.get()?” - “What’s the difference between Vec::push and Vec::append?”

Example: “I have a list of user IDs and need fast lookup. Should I use Vec or HashMap?”

Collections have many methods. AI can help find the right one and show idiomatic patterns. Students should ask AI to explain trade-offs (Vec vs HashMap performance), not just provide syntax. Understanding when to use each collection is key.

Introducing Lab 11: data modeling challenge

This week’s lab has three parts:

1. Structs and Enums
   • Model a library system with custom types
   • Use structs for Book/DVD data
   • Use enums for ItemStatus (Available/CheckedOut)
2. Error Handling
   • Return Result from functions that can fail
   • Use Option for optional data
   • Practice the ? operator
3. Collections in Action
   • Store items in Vec<T>
   • Build HashMap<K, V> for fast lookups
   • Iterate and search

Full instructions: labs/lab11/README.md

Lab 11 applies everything from today. Students will design data structures, handle errors properly, and use collections. This is practical Rust - the kind they’ll write in real projects. Emphasize that this builds on ownership from last week.

Career relevance: production Rust patterns

What you learned today is used daily in industry:

• Discord - Structs for message data, enums for event types
• Dropbox - Result for error handling, HashMap for file tracking
• Cloudflare - Vec for request queues, modules for organization

Interview topics: - “How does Rust handle errors differently than exceptions?” - “When would you use an enum instead of inheritance?” - “Explain Option vs Result”

These patterns aren’t academic - they’re production Rust. Companies choose Rust partly because of these features (Result vs exceptions, enums vs inheritance). Students learning these concepts now are learning industry standards.

Resources for going deeper

Official Rust documentation: - The Rust Book - Chapter 7: Modules - The Rust Book - Chapter 5: Structs - The Rust Book - Chapter 6: Enums and Pattern Matching - The Rust Book - Chapter 9: Error Handling - The Rust Book - Chapter 8: Collections

Interactive practice: - Rust by Example - Modules - Rust by Example - Error Handling - Rustlings - Structs Exercises

All these links are essential reading. Chapter 8 (Collections) and Chapter 9 (Error Handling) are particularly important. Rustlings has great exercises for structs and enums. Encourage students to work through these after the lab.

Questions?

Remember: - Modules organize code, structs/enums organize data - Option<T> eliminates null pointer errors - Result<T, E> makes error handling explicit - Collections (Vec, String, HashMap) follow ownership rules - Use AI to explore design patterns and learn idioms

Lab 11 due: Sunday, November 16 at 11:59 PM

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

End on an encouraging note. Today’s content is dense but practical. Every concept (modules, structs, enums, Result, collections) is used daily in production Rust. The lab lets them apply it all. Remind them that understanding ownership makes this week easier.