SKILL.md
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