Question 1

Explain ownership in Rust.

Accepted Answer

Summary

Every value has a single owner; when the owner goes out of scope the value is dropped. Assigning or passing a non-Copy value moves ownership, so the old binding can't be used, which prevents double frees and use-after-free without a garbage collector.

Longer Answer

Copy types (integers, floats, bool, char) are duplicated instead of moved. clone() makes explicit deep copies. Borrowing (&T, &mut T) lets code use a value without taking ownership.

Key Points

One owner; dropped at end of scope.
Moves for heap types; Copy for simple ones.
Borrowing avoids moves.

Deep dive: Rust Fundamentals: Ownership

Question 2

What are Rust's borrowing rules and what do they prevent?

Accepted Answer

Summary

At any time, either any number of shared references (&T) or exactly one mutable reference (&mut T), and references must never outlive their data. This prevents data races, iterator invalidation and dangling pointers at compile time.

Longer Answer

The borrow checker enforces these rules statically. Non-lexical lifetimes mean a borrow ends after its last use, not at the end of the block.

Key Points

Many readers XOR one writer.
No dangling references.
Checked at compile time.

Deep dive: Rust Fundamentals: Borrowing

Question 3

How does error handling work in Rust?

Accepted Answer

Summary

Recoverable errors are values of type Result<T, E>, handled with match or propagated with the ? operator; unrecoverable bugs panic. Option<T> represents absence instead of null.

Longer Answer

Libraries define error enums implementing Display and std::error::Error (often with thiserror); applications often use anyhow for context. ? converts errors via From.

Key Points

Result + ? for expected failures.
panic! for bugs.
Custom error enums; thiserror/anyhow.

Deep dive: Rust Fundamentals: Error Handling

Question 4

What are lifetimes and when must you annotate them?

Accepted Answer

Summary

Lifetimes describe how long references are valid so the compiler can prove they never outlive their data. Most are inferred; you annotate when a function returns a reference that could come from several inputs, or when a struct stores references.

Longer Answer

Annotations don't change how long values live; they express relationships (e.g. the result lives as long as both inputs).

Key Points

Describe, don't extend, lifetimes.
Needed for ambiguous returned references and structs with references.
'static lives for the whole program.

Deep dive: Rust Fundamentals: Lifetimes

Question 5

What's the difference between impl Trait, generics and dyn Trait?

Accepted Answer

Summary

Generics and impl Trait use static dispatch: the compiler generates code per concrete type (fast, no indirection). dyn Trait is a trait object with dynamic dispatch through a vtable, allowing different types behind one pointer such as Box<dyn Trait>.

Longer Answer

Use generics by default; use trait objects for heterogeneous collections, plugin-style code or to reduce binary size and compile time.

Key Points

Static vs dynamic dispatch.
Box<dyn Trait> for mixed types.
Trait bounds constrain generics.

Deep dive: Rust Fundamentals: Traits and Generics

Question 6

How does Rust prevent data races in concurrent code?

Accepted Answer

Summary

The Send and Sync marker traits are checked by the compiler: only Send types can move to other threads and only Sync types can be shared. Shared mutable state needs synchronisation like Arc<Mutex<T>>, so unsynchronised sharing doesn't compile.

Longer Answer

Channels transfer ownership between threads; scoped threads can borrow local data safely; async runtimes like Tokio handle I/O concurrency.

Key Points

Send/Sync checked at compile time.
Arc for shared ownership, Mutex/RwLock for mutation.
Channels and scoped threads.

Deep dive: Rust Fundamentals: Fearless Concurrency