RustCurious lesson 7 explains arrays, slices and vectors in Rust

Rust’s first real data-model puzzle is usually not ownership itself. It is figuring out why `[T; N]`, `&[T]`, and `Vec<T>` all seem to hold a list, yet Rust treats them like three different animals, and that distinction is exactly what RustCurious lesson 7 leans on.

The beginner mistake is thinking “a collection is a collection”

That is the trap this lesson helps spring open. New Rust users often reach for whatever looks closest to a list, then get surprised when the compiler pushes back on function signatures, borrowing, or size. The video gets useful because it starts from the simple fact that Rust has distinct types for fixed-length arrays, dynamic arrays, and slices, and then ties that split to ownership and borrowing instead of leaving it as syntax trivia.

That matters in practice because Rust is not only asking what data you have, it is asking who owns it and whether its shape is known up front. Once size becomes part of the type, the compiler can enforce different rules, and that is why a four-item array is not interchangeable with a growable vector, even if both can look like a sequence of numbers on the page.

Arrays are fixed-size data, and Rust treats that size as real

The Rust Reference is blunt here: an array is a fixed-size sequence written `[T; N]`, where `N` is a non-negative compile-time constant of type `usize`. That means the length is not just a runtime detail, it is part of the type itself. If you say you have an array of length 3, you really mean exactly three elements, not “three for now.”

The other detail beginners should notice is that arrays are always initialized, and safe access is bounds-checked. That is a lot of Rust’s personality in one place: no vague, half-formed collection that might or might not have data, and no casual indexing that silently wanders past the edge. Arrays are a good fit when the size is genuinely fixed and the compiler should know it, such as when you want a clearly bounded chunk of data and the number of elements is not supposed to change.

Slices are not collections you own, they are borrowed views

This is the point where the lesson’s teaching angle really pays off. A slice is a borrowed reference into a sequence of elements owned by some other variable, and the Rust Reference defines slices as dynamically sized views into a sequence of elements of type `T`. In everyday Rust, you usually see that as `&[T]` for a shared slice or `&mut [T]` for a mutable slice.

The practical payoff is that a slice lets you inspect or modify part of a larger sequence without taking ownership away from the original owner. The Rust book’s slice chapter frames that neatly as a way to reference a contiguous sequence of elements without taking ownership, which is exactly the mental model beginners need when they keep asking why the compiler refuses to let them move data around casually.

Rust By Example adds a detail that helps the abstraction feel less mystical: a slice is a two-word object, a pointer and a length. That is why slices can represent empty views, and why they can be split into chunks. They are small, lightweight windows onto data, not the data itself.

Vec is the growable collection most people actually want

When the size is not fixed, `Vec<T>` is the workhorse. The Rust Reference identifies it as the standard library’s heap-allocated resizable array type, which is the important bit for beginners who need something that can grow as data arrives. If arrays are for “exactly this many” and slices are for “look at this part of something else,” then `Vec` is for “I need this to expand.”

That is why many new Rustaceans eventually settle on `Vec` for user input, lists built at runtime, or anything whose length is not known when the code is written. The compiler cares here because a `Vec` carries ownership of its buffer, while a slice merely borrows a view into storage someone else already owns. The moment you stop treating those as interchangeable, a lot of borrow checker friction starts to look like design, not annoyance.

Function signatures are where the distinction becomes obvious

This is the part of RustCurious lesson 7 that should save you the most time. If a function only needs to read a contiguous sequence, taking `&[T]` is usually the cleanest signature because it accepts borrowed data without forcing a copy or ownership transfer. If a function needs to mutate the elements in place, `&mut [T]` says exactly that, and if the function truly needs to grow or shrink the collection, `Vec<T>` or `&mut Vec<T>` starts to make sense.

A lot of beginner confusion comes from writing signatures that are too specific. `fn f(items: [i32; 4])` only accepts one exact size, while `fn f(items: &[i32])` can work with an array, a vector, or a slice view borrowed from either of them. Once that clicks, the compiler stops feeling arbitrary and starts feeling like it is forcing you to state your real intent.

Here is the clean rule of thumb that Rust keeps teaching by pressure:

• Use arrays when the size is fixed and part of the type.
• Use slices when you want a borrowed view into existing data.
• Use `Vec` when the collection needs to grow or you need owned, heap-allocated storage.

Why lesson 7 lands so well for beginners

RustCurious does not present this as a one-off trick. The channel bills itself as “Rust explained carefully,” and the lesson sits in a broader sequence that already includes lesson 6 on enums and polymorphism, lesson 5 on destruction, and earlier introductory syntax material. That progression matters because arrays, slices, and vectors are not just another topic, they are one of the first places where Rust’s ownership story becomes visible in real code.

The lesson also points to exercise source code, which is exactly the right move for a topic like this. Rust usually becomes obvious only after you type the small example, change the function signature, and watch the compiler tell you what you actually promised. By the time that happens, the difference between fixed-size arrays, borrowed slices, and growable `Vec`s is no longer abstract. It is the foundation under almost every sequence you will write in Rust.