Let's dive back into Rust, this time we're exploring ownership. Ownership is Rust's secret sauce for achieving memory safety without relying on a garbage collector. Brace yourself, as this concept can be challenging, especially for those coming from other languages.

If you're unfamiliar with memory-safe programming, @jess initiated a discussion seeking ELI5 explanations, yielding some fascinating insights.

Explain "Memory Safe Programming Languages" Like I'm Five Please

Jess Lee ・ Feb 27

#explainlikeimfive #discuss

Understanding Ownership

Ownership revolves around memory management, typically handled in two ways: through a garbage collector that periodically cleans up unused memory or through manual memory allocation and deallocation. Rust takes a unique approach by side stepping these norms, instead implementing a set of compile-time rules to manage memory. If any of these rules are violated, compilation fails.

Exploring Memory

To grasp memory management, let's first understand memory itself. Random Access Memory (RAM) serves as temporary storage on devices, facilitating fast read/write operations. RAM comes in two primary forms: Stack Memory and Heap Memory. Understanding these allocations is crucial for optimizing memory usage and enhancing application performance.

Stack Memory

Stack memory operates as a pre-allocated memory section generated upon the invocation of a function/routine. Conceptually, it resembles a stack of plates, allowing for data addition at the top. When it's time to remove data from memory, the most recent items are the first to be removed, following the "Last In, First Out" (LIFO) principle. Upon completion of the function or routine, the entire stack is deallocated, erasing all stored data.

Heap Memory

Heap memory contrasts with stack memory in its dynamic nature. It allows for flexible allocation and deallocation of memory space, capable of growing and shrinking as needed, without any particular order. Conceptually, it resembles a heap of clothes on the floor, where items can be accessed, added, and removed in any order. Although this lack of organization may cause a slight slowdown, heap memory offers the advantage of accessibility across the entire application and accommodates large volumes of data, making it highly versatile.

Variable Scoping

When a variable is declared and stored in memory—whether it's allocated in the stack due to compile-time determinacy or in the heap for flexibility—it is also bound to a scope, delineated by curly braces.

fn main() { // Scope begins
  println!("App starting."); // Scoped but not declared
  let var: u8 = 7; // Scoped and declared
  println!("variable: {}", var); // Scoped
} // End of scope
// 'var' is no longer valid

In languages with garbage collection, a routine periodically cleans up memory that's out of scope, relieving developers of manual memory management. However, this incurs overhead and delays in reclaiming memory.

Other languages require manual memory deallocation, offering control but being error-prone and leading to memory leaks.

Rust strikes a balance, leveraging strict compile-time rules. As a scope closes, Rust automatically invokes the drop function, releasing memory tied to the current scope. This mirrors the Resource Acquisition Is Initialization (RAII) pattern in C++.

Copy, Move and Clone

In JavaScript and many other languages, shallow copying allows multiple variables to point to the same memory location. However, Rust diverges from this approach due to concerns about potential double-free errors, which could lead to data corruption or security vulnerabilities. Instead, Rust employs ownership transfer, known as moving, to prevent such issues.

Imagine a box of chocolates. Shallow copying is akin to sharing the box with friends, where everyone's actions affect everyone else. In contrast, Rust's move is like passing the entire box to someone else, relinquishing access for yourself.

Although Rust avoids shallow copying, it still allows for deep copying, known as cloning. While cloning prevents rule violations, it's computationally expensive as it duplicates memory.

Caveat

When data is stored on the stack, where its size is fixed, assigning one variable to another behaves similarly to cloning. This behaviour is a result of the fixed nature of stack memory.

We're given a glimpse of the Copy trait here, which serves as a precursor to the broader concept of traits, to be explored in more detail later on.

References and Borrowing

References and Borrowing in Rust provide a workaround for the cumbersome process of passing variables to functions without cloning. A reference allows us to point to a variable, preserving its original memory location even when dropped. Denoted by the & symbol, references come in mutable (&mut) and immutable forms. However, having a mutable reference in scope restricts the presence of other references to the same variable, preventing dangling references like wise returning references is disallowed for the same reason.

fn main() {
  let mut original_string = String::from("hello");

  // Creating a mutable reference to 'original_string'
  let reference = &mut original_string;

  // Modifying the string through the mutable reference
  reference.push_str(", world!");

  // Prints: String after modification: hello, world!
  println!("String after modification: {}", original_string);
}

Slices

Slices offer a powerful tool in Rust, allowing us to reference segments of an array without the need to reference the entire dataset. By creating references rather than transferring ownership, slices simplify memory management.

Rust tackles the challenge of memory mutability by shifting it to the compile step, ensuring that memory doesn't change unexpectedly after being referenced. While the book's example utilises strings and substrings, the concept extends seamlessly to arrays and vectors, fundamental data structures in Rust.

Earlier, we explored how variables and references interact with memory. Slices provide a nuanced approach, pointing to a specific memory location and delineating the start and end positions of the slice. Like references, slices are bound by the same scope rules, ceasing to exist once the original variable is out of scope.

In our example, we delve into arrays, iterating through elements to find the largest number. By returning a reference to the slice containing the largest number, we maintain efficiency without consuming additional resources, thanks to Rust's memory management mechanisms.

fn main() {
    // Define an array of 10 u8 numbers
    let num_list: [u8; 10] = [43, 97, 12, 55, 28, 84, 39, 62, 76, 19];

    // Call the largest_num function passing a reference to the array
    let largest = largest_num(&num_list);

    // Print the largest number found
    println!("The largest number is: {}", largest);
}

// Define a function to find the largest number in an array
fn largest_num(nums: &[u8; 10]) -> &u8 {
    // Initialize variables to track the index of the largest number and the current highest number
    let mut start_index: usize = 0;
    let mut current_highest: u8 = 0;

    // Iterate through the array elements using an iterator and enumerate
    for (index, &item) in nums.iter().enumerate() {
        // Compare each element with the current highest number
        if current_highest < item {
            // If the current element is larger, update the current highest number and its index
            current_highest = item;
            start_index = index;
        }
    }

    // Return a reference to the slice containing the largest number (slice of length 1)
    return &nums[start_index..start_index + 1][0];
}

While the explanation of slices at this juncture may seem premature, it lays the groundwork for understanding ownership and memory management in Rust. As we progress through the lessons, I'm sure we'll revisit these concepts to gain a deeper understanding.

Signing off

And with that, we conclude our exploration into Rust's ownership model! It's been quite the journey, navigating through the intricacies of memory management and the unique approach Rust takes to ensure memory safety. This lesson felt a lot denser with a lot of new concept to understand.

Thanks so much for reading. If you'd like to connect with me outside of Dev here are my twitter and linkedin come say hi 😊.