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