- Home
- Skills
- Zhanghandong
- Rust Skills
- M14 Mental Model
m14-mental-model_skill
- Shell
565
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill zhanghandong/rust-skills --skill m14-mental-model- SKILL.md4.8 KB
Overview
This skill provides concise mental models and analogies to help learners think correctly about Rust concepts like ownership, borrowing, lifetimes, and smart pointers. It focuses on the right intuitions, common misconceptions, and visual metaphors that make compiler errors meaningful rather than mysterious. Use it to translate compiler messages and Rust rules into everyday analogies and practical troubleshooting prompts.
How this skill works
The skill inspects the concept or compiler error you’re struggling with and returns a targeted mental model (analogy), the typical wrong way to think about it, and the correct intuition to adopt. It highlights the safety guarantee being enforced and suggests the next conceptual or implementation step to explore. Visual layouts and short trace-up/trace-down prompts guide you from “why” to “how”.
When to use it
- Learning Rust fundamentals (ownership, borrowing, lifetimes)
- Interpreting borrow-checker or ownership-related compiler errors
- Transitioning from managed languages (Java, Python) to Rust
- Deciding which smart pointer (Box, Rc, Arc) fits a design
- Preparing to design safe concurrency or low-level data structures
Best practices
- Always ask: who owns the data, how long does it live, who can access it?
- Map compiler errors to the safety guarantee being violated before fixing code
- Prefer reshaping ownership (move, borrow, clone) over adding clone or unsafe as first fixes
- Use simple analogies (key, lending, ticket) to explain code reviews or teach others
- Trace up from an error to the design question, then trace down to implementation patterns
Example use cases
- Explain why a value is 'moved' and how to pass ownership safely
- Understand E0382/E0507 by mapping them to the unique-key model
- Choose between Box, Rc, and Arc using heap/remote-control analogies
- Resolve mutable vs immutable borrow errors by visualizing exclusive writer vs shared readers
- Coach a team member coming from Java/Python on Rust’s deterministic destruction
FAQ
The compiler enforces static guarantees (no data races, no dangling pointers). If it rejects code, some execution path could violate those guarantees; reframe the problem as a lifetime/ownership question and apply a borrow, ownership transfer, or refactor to satisfy the static rule.
When should I use clone instead of changing ownership?
Clone is fine for cheap or cheap-to-implement data, but overusing clone masks ownership design issues. Prefer moving or borrowing to express intent; use clone when semantics demand independent copies or when performance cost is acceptable.