The Rust Learning Program — Complete Guide

A 1-Year Systems Programming Curriculum for Ashwin Hebbar

March 2026

Why Rust, and Why Now

You identified the problem accurately: years of Python-layer work — frameworks, APIs, LLM services — have made you fluent at connecting components but left the layers underneath invisible. Rust is not just another language to add to your resume. It is the specific tool that will force your brain to confront what Python hides:

• Ownership and borrowing → you will understand heap vs. stack, what “passing by reference” actually means in physical memory, and why Python objects carry so much hidden overhead
• No garbage collector → you will understand the cost Python pays on your behalf, and why it makes certain workloads fundamentally slow
• No implicit null → error handling becomes a compile-time, type-level concern instead of a runtime surprise
• Fearless concurrency → you will understand threads, shared mutable state, and data races at the type level before your program even runs
• The compiler as teacher → you cannot get Rust code to compile without understanding what it does. The borrow checker does not respond to prompts.

After a year of serious Rust, you will write better Python, better SQL, and better system designs — because you will understand what is happening underneath.

Time Budget

How to split your time each week:

• Weekday evenings (4–5 hrs): Book chapters, rustlings exercises, small coding experiments, DSA practice
• Weekend blocks (4–5 hrs): Project work, longer study sessions (Crust of Rust videos, etc.), debugging and iteration

Note on pacing: This program was redesigned from 6 months to 1 year to fit around real work commitments. The content and depth are unchanged — the timeline is simply more honest. Consistent 8–10 hrs/week beats sporadic 20-hour weeks every time.

Program Structure — 5 Phases over 52 Weeks

Phase 1 — Language Foundations (Weeks 1–6)

Objective: Get fluent with ownership, types, error handling, and the compiler’s feedback loop.

Weekly Schedule:

• Week 1: Chapters 1–4 of the Book + rustlings variables/functions/if. Weekend: set up your dev environment, write small programs.
• Week 2: Revisit and deepen ownership — String vs &str, stack vs heap, Copy vs Move. Complete rustlings ownership/borrowing sections. Wrestle with borrow checker errors intentionally.
• Week 3: Chapters 5–7 (structs, enums, modules) + rustlings through enums. Weekend: practice pattern matching thoroughly.
• Week 4: Revisit modules and visibility rules. Explore Rust by Example alongside. Start csvq skeleton.
• Week 5: Chapters 8–10 (collections, errors, generics) + remaining rustlings. Weekend: core csvq implementation.
• Week 6: Finish csvq. Buffer week — revisit anything from weeks 1–5 that felt shaky. Review the Book chapters once more.

Study Material:

• The Rust Programming Language (official “Book”) — Chapters 1–10
• rustlings — complete all exercises (non-negotiable)
• Rust by Example — reference alongside the Book

Concepts to Internalize:

• Ownership, borrowing, and moves — understand why this model exists
• Stack vs. heap — concretely, where does data physically live
• Result<T, E> and Option<T> — Rust’s replacement for exceptions and null
• Structs, enums, pattern matching with match
• The module system and crate organization
• String vs &str — understand the difference at the memory level
• Basic I/O with std::fs and std::io

Project: csvq — A Command-Line CSV Query Tool

A fast CLI for ad-hoc CSV analysis. Think “ripgrep for tabular data.”

csvq data.csv --filter "age > 25" --select "name,age,salary" --sort "salary desc" --limit 20
csvq data.csv --group-by "department" --agg "avg(salary),count(*)"
csvq data.csv --stats

Full project details in the Project Specifications document.

End-of-Phase Check: Can you explain to someone what happens in memory when you assign a String vs a &str? Can you explain why the borrow checker rejected a specific piece of your code — not just how you fixed it, but why it was right to reject it?

Phase 2 — The Type System and Real-World Patterns (Weeks 7–16)

Objective: Master traits, generics, lifetimes, iterators, and production-grade error handling and serialization.

Weekly Schedule:

• Week 7: Chapters 10–13 (generics, traits, lifetimes, closures/iterators). Experiment with trait bounds in your own programs.
• Week 8: Deep dive into lifetimes — watch Crust of Rust: Lifetime Annotations. Write code that forces lifetime annotations, then figure out why.
• Week 9: Chapters 14–17 (cargo, smart pointers, trait objects). Understand Box<T>, Rc<T>, Arc<T>, RefCell<T>.
• Week 10: Deep dive smart pointers — watch Crust of Rust: Smart Pointers and Dispatch & Fat Pointers. Understand dyn Trait vs impl Trait at the vtable level.
• Weeks 11–13: Build schemaguard. Watch Crust of Rust: Iterators and Error Handling alongside.
• Week 14: thiserror vs anyhow deep dive, serde + serde_json thorough walkthrough. Read Rust for Rustaceans Chapters 1–3.
• Weeks 15–16: Build logr. Refactor code from previous weeks using new knowledge.

Study Material:

• The Rust Programming Language Chapters 10–17
• Jon Gjengset’s Crust of Rust YouTube series — at minimum: Lifetime Annotations, Iterators, Smart Pointers, Dispatch & Fat Pointers, Error Handling
• Rust for Rustaceans by Jon Gjengset — Chapters 1–5
• serde documentation — read and work through examples

Concepts to Internalize:

• Generics with trait bounds (fn process<T: Display + Debug>(item: T))
• Lifetimes — understand they describe relationships between references, not object duration
• Box<T> (heap allocation), Rc<T> (shared ownership), Arc<T> (thread-safe shared ownership), RefCell<T> (interior mutability)
• Static vs dynamic dispatch (impl Trait vs dyn Trait) — understand the vtable
• Iterator chains and lazy evaluation — .filter().map().collect() patterns
• thiserror for library errors, anyhow for application errors
• serde + serde_json for serialization/deserialization

Projects:

• schemaguard — A streaming data contract validator (real-world, open-source gap)
• logr — A terminal-native personal activity tracker

Full project details in the Project Specifications document.

End-of-Phase Check: Can you write a generic function with multiple trait bounds? Can you explain to someone why Rust needs lifetimes and what concrete problem they prevent? Can you explain the difference between Box<dyn Trait> and impl Trait?

Phase 3 — Concurrency, Async, and Networking (Weeks 17–28)

Objective: Understand threading, async I/O, TCP networking, and build real networked applications.

Weekly Schedule:

• Week 17: Chapters 16 & 20 (concurrency, multi-threaded server). Experiment with std::thread and Arc<Mutex<T>>.
• Week 18: Deep dive threading — Arc<RwLock<T>>, channels (mpsc), shared state patterns. Write programs that deliberately trigger data race compile errors and understand why.
• Week 19: Tokio Tutorial Part 1 (setup, spawning, channels). Watch Crust of Rust: async/await.
• Week 20: Deep dive async — Tokio tutorial Part 2, tokio::select!, broadcast and oneshot channels. Read Programming Rust concurrency chapters.
• Weeks 21–23: Build the HTTP/1.1 server from scratch (no frameworks). This is a weekend-intensive project spread across 3 weeks. Understand every byte of the HTTP request/response cycle.
• Weeks 24–28: Build airpost. Learn axum and sqlx. Integrate database persistence. Deploy locally and test under concurrent load.

Study Material:

• The Rust Programming Language Chapters 16 and 20
• Tokio Tutorial (tokio.rs/tokio/tutorial) — complete fully
• Jon Gjengset’s lectures on async Rust
• Programming Rust (O’Reilly) — Concurrency chapters
• axum documentation and examples
• sqlx documentation — especially compile-time query checking

Concepts to Internalize:

• std::thread::spawn, Arc<Mutex<T>>, Arc<RwLock<T>> — threading primitives
• Why async exists: threads are expensive, async tasks are cheap
• The Tokio runtime, tokio::spawn, tokio::select!
• Channels: mpsc, broadcast, oneshot — inter-task communication
• TCP sockets with std::net::TcpListener — raw network programming
• axum for HTTP servers (after building one by hand)
• sqlx for async, compile-time-checked PostgreSQL queries
• Send + Sync traits — what they mean and why Rust checks them at compile time

Projects:

• HTTP/1.1 Server from scratch (no frameworks — learning exercise)
• ticknorm — ⚠️ Replaced due to conflict of interest with LSEG. See project specs for details.
• airpost — A real-time air quality data aggregator (public good, real-world)

Full project details in the Project Specifications document.

End-of-Phase Check: Can you explain the difference between OS threads and async tasks? Can you explain what Send + Sync mean? Can you explain why your raw HTTP server would break under concurrent connections without Arc?

Phase 4 — Performance, Finance, and Python Integration (Weeks 29–40)

Objective: Understand why Rust is fast, build a finance-domain tool with real mathematical depth, and bridge Rust back to Python via PyO3.

Weekly Schedule:

• Week 29: Study unsafe Rust, FFI basics. Profile your previous projects with cargo flamegraph. Understand what unsafe permits and why it exists.
• Week 30: Read Rust for Rustaceans Chapters 6–9 (unsafe, FFI, performance). Deep dive into memory layout: repr(C), alignment, padding.
• Weeks 31–35: Build riskbook. Implement Black-Scholes math. Learn criterion for benchmarking. Week 35 is dedicated to profiling, benchmarking, and squeezing performance — use flamegraphs, not guesses.
• Week 36: Review PyO3 guide end-to-end. Build a small throwaway PyO3 proof-of-concept before touching xlsxfmt. Read Rustonomicon Chapter 11 (FFI).
• Week 37: Understand the XLSX format before writing code. Open a .xlsx file with unzip and read the raw XML. Implement XLSX reading: cell values, shared string table.
• Week 38: Implement XLSX writing — create workbooks, write cell values, write basic formatting (bold, font size, fill color) via styles.xml.
• Week 39: Cell range reading, formula string preservation (read → store formula string → write back; do not evaluate), row height and column width.
• Week 40: PyO3 binding, integration tests (read → modify → write → re-read → assert), README that explicitly states what is and is not supported, publish as 0.1.0-alpha.

Note: xlsxfmt is scoped to a reliable basic implementation in Weeks 37–40. Advanced features (merged cells, conditional formatting, charts, full number format string parsing, streaming reader for large files) are documented separately as a post-program extension track for Weeks 53–60+.

Study Material:

The Rustonomicon (doc.rust-lang.org/nomicon) is the official guide to unsafe Rust. It is not telling you to write unsafe code. It is telling you what you are promising the compiler when you do.

Concepts to Internalize:

• unsafe Rust — what it permits (raw pointer derefs, FFI calls, etc.) and when it’s necessary
• Memory layout: repr(C), alignment, padding
• Profiling: cargo flamegraph, reading flame graphs, identifying hotspots
• Benchmarking with criterion — statistical benchmarking, not wall-clock timing
• PyO3 — writing Python modules in Rust, converting types across the FFI boundary
• Floating-point arithmetic: precision, rounding, NaN handling (critical for finance)
• ZIP archive format and XML parsing at the byte level

Projects:

• riskbook — A real-time portfolio risk engine (finance, Black-Scholes, VaR)
• xlsxfmt — A high-fidelity bidirectional Excel processing library (real-world gap)

Full project details in the Project Specifications document.

End-of-Phase Check: Can you profile a Rust program and identify a performance bottleneck? Can you explain what Black-Scholes computes and implement it from the formula? Can you explain what unsafe permits and why it exists?

Phase 5 — Capstone (Weeks 41–52)

Choose one of three projects. All three teach the same advanced Rust concepts: DSL/formula parsing, trait-based architecture, PyO3 bindings, benchmarking, and crates.io publishing. Pick whichever excites you most. Full specifications for all three are in the Project Specifications document.

Option A: docforge — Document Conversion Library

What it is: A Rust library that converts XLSX and DOCX files to PDF — the open-source alternative to LibreOffice headless that actually preserves formatting. Builds on your xlsxfmt project.

Weekly Schedule:

• Weeks 41–44: XLSX → PDF rendering. Build on xlsxfmt. Render cells, formatting, borders, merged cells.
• Weeks 45–48: DOCX → PDF. Parse DOCX (ZIP + XML). Render paragraphs, headings, tables, basic styles.
• Weeks 49–52: Clean API, documentation, benchmarks vs LibreOffice, PyO3 binding, publish to crates.io.

Study Material: OOXML specification, printpdf crate docs, rustdoc conventions, crates.io publishing guide.

Key Rust concepts: Binary I/O (ZIP/PDF), XML processing, trait-based renderer pipeline (DocumentReader, PdfRenderable), font rendering, unsafe for performance-critical paths, PyO3.

End-of-Phase Check: Is the crate published? Do benchmarks show improvement over LibreOffice headless? Can a Python user pip install docforge and convert a file?

Option B: formulaengine — Spreadsheet Formula Computation Engine

What it is: A standalone engine that evaluates spreadsheet formulas (SUM, VLOOKUP, IF, etc.) with a dependency graph and incremental recalculation. The “SQLite of formula evaluation.” Pairs with xlsxfmt to form a Rust spreadsheet toolkit that doesn’t exist in any language.

Weekly Schedule:

• Weeks 41–44: Formula parser (tokenizer, recursive descent parser, AST) and core evaluation engine with 20+ built-in functions.
• Weeks 45–48: Dependency graph, topological sort, circular reference detection, incremental recalculation, 20+ advanced functions (VLOOKUP, SUMIF, etc.).
• Weeks 49–52: xlsxfmt integration, CLI, PyO3 binding, benchmarks (100k cells), documentation, publish to crates.io.

Study Material: Crafting Interpreters by Robert Nystrom (chapters 4–8, free online), petgraph crate docs, Excel formula specification, rustdoc conventions, crates.io publishing guide.

Key Rust concepts: Parsing (tokenizer → AST → evaluator), graph algorithms (topological sort, cycle detection), enums with data (Value, Expr), trait-based function registry, generics, lifetimes, incremental computation, PyO3.

End-of-Phase Check: Is the crate published? Can it evaluate 100k cells with dependencies in under 1 second? Does the xlsxfmt integration work? Can a Python user pip install formulaengine and evaluate formulas?

Option C: ruleforge — Embeddable Business Rules Engine

What it is: A lightweight rules engine with its own DSL. Business analysts define rules like when customer.tier == "gold" AND order.total > 5000 then set discount = 0.15, and the engine evaluates them at runtime against JSON data. No redeployment needed for rule changes. The Rust answer to Java’s Drools.

Weekly Schedule:

• Weeks 41–44: Rule DSL design and parser (tokenizer, recursive descent parser, AST). Conditions, actions, priorities, nested field access, AND/OR/NOT.
• Weeks 45–48: Evaluation engine, conflict resolution strategies (priority, first_match, all), rule chaining with loop detection, audit trail.
• Weeks 49–52: CLI (eval, validate, explain modes), PyO3 binding, benchmarks (10k rules), documentation, publish to crates.io.

Study Material: Crafting Interpreters by Robert Nystrom (chapters 4–8, free online), Drools documentation (for conceptual understanding), OPA/Rego design docs, rustdoc conventions, crates.io publishing guide.

Key Rust concepts: Language design (you’re building a DSL), parsing (tokenizer → AST → evaluator), enums with data (Expr, Value, Action), trait-based extensibility (ConflictResolver, Function), generics, lifetimes, serde (advanced), audit logging, PyO3.

End-of-Phase Check: Is the crate published? Can it evaluate 10k rules in under 100ms? Does the explain mode produce human-readable output? Can a Python user pip install ruleforge and evaluate rules?

Parallel Track: DSA Remediation (Throughout All 12 Months)

This runs alongside the Rust program. Dedicate 2–3 hours per week (from your weekday evening hours). Lower weekly target than the 6-month version — it fits the realistic schedule.

Months 1–3: Foundations (Phase 1 of Rust program)

• NeetCode 150: Arrays & Hashing, Two Pointers, Sliding Window, Stack, Binary Search
• Do these in Python first for speed
• Focus: understand the pattern, not just the solution
• Target: 2–3 problems per week

Months 4–7: Intermediate (Phase 2–3 of Rust program)

• NeetCode 150: Linked Lists, Trees, Tries, Backtracking, Heap/Priority Queue, Graphs (BFS/DFS)
• Start redoing selected problems in Rust (combines DSA + Rust practice)
• Target: 2–3 problems per week

Months 8–12: Advanced + Rust (Phase 4–5 of Rust program)

• Dynamic Programming (essential for optimization problems in finance)
• Graph algorithms: Dijkstra, topological sort, cycle detection
• All new problems in Rust
• Target: 1–2 problems per week (harder problems take longer, and Phase 4–5 Rust is demanding)

DSA Goal

By month 12: solve any LeetCode medium confidently within 30 minutes, without AI assistance. In Rust or Python.

Parallel Track: OSS Contributions (Phases 3–5)

This track runs alongside Phases 3, 4, and 5. It does not add weekly hours — it replaces some of the reading/exploration time in those phases. A hiring manager at Cloudflare, Qdrant, or Anduril sees solo portfolios regularly. What is rarer is a GitHub history showing merged PRs to production Rust codebases they recognize.

The target is to demonstrate that you can write Rust at a standard that other experienced Rust engineers will accept after review. That is a different skill than writing Rust that works in isolation.

Recommended Target Projects (in priority order)

Phase 3 (Weeks 17–28) — First Contribution

Goal: One merged PR before Phase 3 ends.

Scope deliberately small. A documentation improvement, a missing example, or a clearly-described small bug with a reproduction case. The goal is not impressive code — it is learning how a real production Rust project handles review, CI requirements, and contribution standards.

Before writing a single line: read the project’s CONTRIBUTING.md and issue tracker. Understand what “good first issue” actually means in that codebase.

Phase 4 (Weeks 29–40) — Substantive Contribution

Goal: One PR with real engineering substance.

By Phase 4 you have concurrency, async, and criterion benchmarking. You are capable of touching core logic. Target: a feature built on an existing abstraction, a performance improvement with benchmark comparison, or a meaningful bug fix in concurrent code.

Phase 5 (Weeks 41–52) — Ongoing Engagement

Goal: Additional PR or active issue engagement.

If your capstone is ruleforge: contributing to OPA’s issue tracker or documenting research on Grule’s architecture strengthens both. If your capstone is formulaengine: engaging with HyperFormula’s GitHub issues (even as a reporter of bugs you discover) is legitimate community presence.

Minimum Bars

Rules on AI During This Program

The heuristic: if you haven’t earned the confusion by trying yourself, you haven’t earned the explanation.

Resources

1-Year Outcome

If you complete this program honestly:

1. You will understand how memory works — concretely, not abstractly
2. You will have 3+ tools that solve real problems and could be open-sourced or SaaS’d (schemaguard, riskbook, and your capstone)
3. You will have a published crate on crates.io — whether it’s a document converter, a formula engine, or a rules engine — that fills a genuine gap in the Rust ecosystem
4. You will have built a parser, evaluator, and trait-based architecture from scratch — the kind of work senior engineers do
5. You will write better Python, SQL, and system designs because you understand the layers beneath
6. You will be one of very few engineers in your peer cohort who work fluently at both the Python/ML layer and the systems layer
7. The AI dependency will be resolved — not because you stopped using AI, but because you will know enough to catch its mistakes
8. LeetCode mediums in 30 minutes without assistance

The gap you identified is real. You identified it yourself, before it bit you. Now close it.