Mental Models

Layer 2: Design Choices

Core Question

What's the right way to think about this Rust concept?

When learning or explaining Rust:

• What's the correct mental model?

• What misconceptions should be avoided?

• What analogies help understanding?

Key Mental Models

Concept Mental Model Analogy

Ownership Unique key Only one person has the house key

Move Key handover Giving away your key

&T

Lending for reading Lending a book

&mut T

Exclusive editing Only you can edit the doc

Lifetime 'a

Valid scope "Ticket valid until..."

Box<T>

Heap pointer Remote control to TV

Rc<T>

Shared ownership Multiple remotes, last turns off

Arc<T>

Thread-safe Rc Remotes from any room

Coming From Other Languages

From Key Shift

Java/C# Values are owned, not references by default

C/C++ Compiler enforces safety rules

Python/Go No GC, deterministic destruction

Functional Mutability is safe via ownership

JavaScript No null, use Option instead

Thinking Prompt

When confused about Rust:

What's the ownership model?

• Who owns this data?

• How long does it live?

• Who can access it?

What guarantee is Rust providing?

• No data races

• No dangling pointers

• No use-after-free

What's the compiler telling me?

• Error = violation of safety rule

• Solution = work with the rules

Trace Up ↑

To design understanding (Layer 2):

"Why can't I do X in Rust?" ↑ Ask: What safety guarantee would be violated? ↑ Check: m01-m07 for the rule being enforced ↑ Ask: What's the intended design pattern?

Trace Down ↓

To implementation (Layer 1):

"I understand the concept, now how do I implement?" ↓ m01-ownership: Ownership patterns ↓ m02-resource: Smart pointer choice ↓ m07-concurrency: Thread safety

Common Misconceptions

Error Wrong Model Correct Model

E0382 use after move GC cleans up Ownership = unique key transfer

E0502 borrow conflict Multiple writers OK Only one writer at a time

E0499 multiple mut borrows Aliased mutation Exclusive access for mutation

E0106 missing lifetime Ignoring scope References have validity scope

E0507 cannot move from &T

Implicit clone References don't own data

Deprecated Thinking

Deprecated Better

"Rust is like C++" Different ownership model

"Lifetimes are GC" Compile-time validity scope

"Clone solves everything" Restructure ownership

"Fight the borrow checker" Work with the compiler

"unsafe to avoid rules" Understand safe patterns first

Ownership Visualization

Stack Heap +----------------+ +----------------+ | main() | | | | s1 ─────────────────────> │ "hello" | | | | | | fn takes(s) { | | | | s2 (moved) ─────────────> │ "hello" | | } | | (s1 invalid) | +----------------+ +----------------+

After move: s1 is no longer valid

Reference Visualization

+----------------+ | data: String |────────────> "hello" +----------------+ ↑ │ &data (immutable borrow) │ +------+------+ | reader1 reader2 (multiple OK) +------+------+

+----------------+ | data: String |────────────> "hello" +----------------+ ↑ │ &mut data (mutable borrow) │ +------+ | writer (only one) +------+

Learning Path

Stage Focus Skills

Beginner Ownership basics m01-ownership, m14-mental-model

Intermediate Smart pointers, error handling m02, m06

Advanced Concurrency, unsafe m07, unsafe-checker

Expert Design patterns m09-m15, domain-*

Related Skills

When See

Ownership errors m01-ownership

Smart pointers m02-resource

Concurrency m07-concurrency

Anti-patterns m15-anti-pattern