How to Read the Examples

Every finished chapter should contain:

1. a concrete consumer goal;
2. a complete program visible by default;
3. observed stdout as if the reader ran it;
4. a timeline when ordering materially aids understanding;
5. the public contract (Future, Send, ownership, cancellation safety);
6. one changed input or failure case;
7. only the source needed to explain visible behavior.

Do not require the reader to run code. Programs should remain runnable so the book can verify its claims, but commands belong in contributor documentation, not in the teaching flow.

Provider-source excerpts may eventually be folded. Consumer programs and their output should remain visible.

Distinctions to preserve

• async fn does not start a background thread.
• Calling an async function creates a future; polling drives it.
• .await suspends the current task, not necessarily the operating-system thread.
• Concurrent work is not automatically parallel work.
• spawn changes ownership and lifetime requirements.
• Dropping a future is the ordinary cancellation mechanism, but cancellation safety depends on the operation.
• Blocking work inside an async task can block an executor worker.

Evidence convention

Pin Rust and dependency versions before claiming exact diagnostics or runtime formatting. Timing examples should explain ordering relationships without depending on exact millisecond measurements.