
M01 Ownership
Install when you are learning or implementing Rust ownership and need agent answers anchored in C++ and Go comparisons plus smart-pointer mappings.
Overview
M01-ownership is an agent skill for the Build phase that explains Rust ownership, moves, and smart pointers using C++ and Go comparisons.
Install
npx skills add https://github.com/actionbook/rust-skills --skill m01-ownershipWhat is this skill?
- Side-by-side Rust vs C++ table: move invalidation vs std::move unspecified state
- Rust vs Go memory model: GC vs compile-time ownership and Option vs nil
- Smart-pointer map: Box/Rc/Arc/RefCell to unique_ptr, shared_ptr, and interior mutability patterns
- Runnable snippets showing post-move compile errors in Rust vs risky C++ usage
- Thread sharing pattern with Arc::clone and spawn move closures
- 4 smart-pointer mappings (Box, Rc, Arc, RefCell)
- Multi-language comparison tables (Rust, C++, Go)
Adoption & trust: 961 installs on skills.sh; 1.2k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You know C++ or Go but Rust moves, borrows, and Arc patterns feel arbitrary when the compiler rejects your code.
Who is it for?
Indie developers porting intuition from C++ or Go into new Rust backend or CLI code.
Skip if: Greenfield learners with no systems background who need a full Rust course, or teams wanting automated ownership refactors without reading compiler errors.
When should I use this skill?
Implementing or debugging Rust ownership, moves, or shared concurrent data after experience in C++ or Go.
What do I get? / Deliverables
You can choose move vs clone, pick Box/Rc/Arc/RefCell appropriately, and read spawn/move errors with a cross-language mental model.
- Explanation aligned to your code pattern
- Pointer-type recommendation (Box/Rc/Arc/RefCell) for the described sharing model
Recommended Skills
Journey fit
Ownership is core backend/systems literacy during the Build phase when you choose memory models and fix borrow-checker errors. Backend subphase fits services, CLIs, and systems code where move/copy semantics and Arc/Rc decisions matter daily.
How it compares
Concept primer skill, not rust-analyzer or a CI static-analysis integration.
Common Questions / FAQ
Who is m01-ownership for?
Solo builders writing Rust who already know C++ or Go and want quick ownership and pointer analogies while implementing backend or CLI features.
When should I use m01-ownership?
During Build when fixing move errors, designing shared state across threads, or deciding between clone, Arc, and RefCell in a new module.
Is m01-ownership safe to install?
It is documentation-style guidance with example code only; check the Security Audits panel on this page before linking it into agents with broader tool access.
SKILL.md
READMESKILL.md - M01 Ownership
# Ownership: Comparison with Other Languages ## Rust vs C++ ### Memory Management | Aspect | Rust | C++ | |--------|------|-----| | Default | Move semantics | Copy semantics (pre-C++11) | | Move | `let b = a;` (a invalidated) | `auto b = std::move(a);` (a valid but unspecified) | | Copy | `let b = a.clone();` | `auto b = a;` | | Safety | Compile-time enforcement | Runtime responsibility | ### Rust Move vs C++ Move ```rust // Rust: after move, 'a' is INVALID let a = String::from("hello"); let b = a; // a moved // println!("{}", a); // COMPILE ERROR // Equivalent in C++: // std::string a = "hello"; // std::string b = std::move(a); // std::cout << a; // UNDEFINED (compiles but buggy) ``` ### Smart Pointers | Rust | C++ | Purpose | |------|-----|---------| | `Box<T>` | `std::unique_ptr<T>` | Unique ownership | | `Rc<T>` | `std::shared_ptr<T>` | Shared ownership | | `Arc<T>` | `std::shared_ptr<T>` + atomic | Thread-safe shared | | `RefCell<T>` | (manual runtime checks) | Interior mutability | --- ## Rust vs Go ### Memory Model | Aspect | Rust | Go | |--------|------|-----| | Memory | Stack + heap, explicit | GC manages all | | Ownership | Enforced at compile-time | None (GC handles) | | Null | `Option<T>` | `nil` for pointers | | Concurrency | `Send`/`Sync` traits | Channels (less strict) | ### Sharing Data ```rust // Rust: explicit about sharing use std::sync::Arc; let data = Arc::new(vec![1, 2, 3]); let data_clone = Arc::clone(&data); std::thread::spawn(move || { println!("{:?}", data_clone); }); // Go: implicit sharing // data := []int{1, 2, 3} // go func() { // fmt.Println(data) // potential race condition // }() ``` ### Why No GC in Rust 1. **Deterministic destruction**: Resources freed exactly when scope ends 2. **Zero-cost**: No GC pauses or overhead 3. **Embeddable**: Works in OS kernels, embedded systems 4. **Predictable latency**: Critical for real-time systems --- ## Rust vs Java/C# ### Reference Semantics | Aspect | Rust | Java/C# | |--------|------|---------| | Objects | Owned by default | Reference by default | | Null | `Option<T>` | `null` (nullable) | | Immutability | Default | Must use `final`/`readonly` | | Copy | Explicit `.clone()` | Reference copy (shallow) | ### Comparison ```rust // Rust: clear ownership fn process(data: Vec<i32>) { // takes ownership // data is ours, will be freed at end } let numbers = vec![1, 2, 3]; process(numbers); // numbers is invalid here // Java: ambiguous ownership // void process(List<Integer> data) { // // Who owns data? Caller? Callee? Both? // // Can caller still use it? // } ``` --- ## Rust vs Python ### Memory Model | Aspect | Rust | Python | |--------|------|--------| | Typing | Static, compile-time | Dynamic, runtime | | Memory | Ownership-based | Reference counting + GC | | Mutability | Default immutable | Default mutable | | Performance | Native, zero-cost | Interpreted, higher overhead | ### Common Pattern Translation ```rust // Rust: borrowing iteration let items = vec!["a", "b", "c"]; for item in &items { println!("{}", item); } // items still usable // Python: iteration doesn't consume // items = ["a", "b", "c"] // for item in items: // print(item) // items still usable (different reason - ref counting) ``` --- ## Unique Rust Concepts ### Concepts Other Languages Lack 1. **Borrow Checker**: No other mainstream language has compile-time borrow checking 2. **Lifetimes**: Explicit annotation of reference validity 3. **Move by Default**: Values move, not copy 4. **No Null**: `Option<T>` instead of null pointers 5. **Affine Types**: Values can be used at most once ### Learning Curve Areas | Concept | Coming From | Key Insight | |---------|-------------|-------------| | Ownership | GC languages | Think about who "owns" data | | Borrowing | C/C++ | Like references but checked | | Lifetimes | Any | Explicit scope of validity | | Move | C++ | Move is default, not copy | --- ## Mental Model Shifts ### From