Come and explore with me
Async Rust with Tokio Part 2: Tokio Architecture Deep Dive – Scheduler, epoll, and Thread Model
Async Rust with Tokio Series Part 1: How Async Rust Works – Futures, Poll, and the Runtime Gap
Async Rust with Tokio Part 1: How Async Rust Works – Futures, Poll, and the Runtime Model
Advanced Rust Series Part 10: Advanced Lifetime Tricks – Variance, PhantomData, and Zero-Cost Abstractions
Advanced Rust Series Part 9: Lifetime Patterns in Production Code – Common Mistakes and How to Fix Them
Advanced Rust Series Part 8: The Self-Referential Struct Problem – Pin, Unpin, and Async State Machines
Advanced Rust Series Part 7: Smart Pointers and Interior Mutability – Box, Rc, Arc, RefCell, and Mutex
Advanced Rust Series Part 6: Lifetimes in Trait Definitions and Bounds
Advanced Rust Series Part 5: Lifetimes in Structs and Enums – Holding References Safely
Azure CLI + GitHub Copilot in VS Code: What Actually Works in 2026 
Tokio is far more than an async runtime. This post goes inside the work-stealing scheduler, the epoll/kqueue/IOCP integration, the timer wheel, and the thread model that lets Tokio handle massive concurrency on a small number of threads.
Most async Rust tutorials start with Tokio and skip what async actually is. This post goes back to first principles – the Future trait, the poll model, why Rust ships no runtime, and what a runtime is actually doing when it runs your code.
Before you can use Tokio effectively, you need to understand what async Rust actually is under the hood. This post covers the Future trait, the poll model, why Rust has no built-in runtime, and how laziness gives you control that most async runtimes do not.
The final part of the series goes deep into the type system: variance, PhantomData, the drop checker, and the techniques library authors use to write APIs that are both safe and zero-cost. The type-state pattern, newtype pattern, and phantom ownership explained with production-grade examples.
Theory is one thing. Production code is another. This post covers the ownership and lifetime patterns that appear in real Rust codebases, the mistakes developers make repeatedly, and the diagnosis process that resolves borrow checker conflicts that have no obvious fix.
Pin and Unpin are two of the most conceptually difficult parts of Rust. They exist to support self-referential structs and async state machines – understanding them demystifies how async Rust works under the hood and when you actually need to think about them.
Rust’s ownership model is strict by design, but real programs need patterns like shared ownership and interior mutability. Box, Rc, Arc, RefCell, Cell, and Mutex each solve a specific problem. This post maps out when to use each one and what trade-offs you are accepting.
Traits and lifetimes interact in ways that go well beyond what you see in basic Rust. This post covers lifetime bounds on traits, trait objects with lifetimes, and higher-ranked trait bounds – the features that power flexible and safe library APIs.
Holding references inside structs and enums is where lifetime annotations become unavoidable. This post covers how to annotate data structures that borrow from external data, what the constraints mean in practice, and the design patterns that keep your code clean.
A full written version of the Azure CLI + GitHub Copilot in VS Code session delivered at Global Azure Bootcamp 2026. Covers the .azcli file trick, Copilot Chat for Azure commands, Bicep generation, GitHub Actions workflows, error debugging, and honest limitations — with all demo commands included.
