Examples index
The repo ships two kinds of example material. The examples/ directory
holds six runnable Cargo projects (five console programs and one
browser page) plus one parse-only corpus example. Alongside
them, demo/src/examples/ holds the playground classics — short,
self-contained programs the web playground runs in the browser, the
same programs the repo’s gates compile and run in CI.
Each project has its own page in this chapter; the classics share
The playground corpus.
| Project | Run | What it demonstrates |
|---|---|---|
| 00 — Todolist | cargo run -p todolist | an entry fn surface over a rut class — the host drives CRUD through opaque handles |
| 01 — Sort | cargo run -p sort | five sorting algorithms behind one dispatcher entry; when on strings, the mut-binding law, fuel budgets |
| 02 — Digest | cargo run -p digests | byte-level codecs and hashes (MD5/SHA/base64/CRC/FNV); the host as an independent test oracle |
| 03 — Plugin | cargo run -p plugin | a module directory + .rutbundle chat-moderator plugin; re-entrant vm.call, both opaque directions |
| 04 — Custom async | parse-only — no runnable harness | a hand-written impl Future<nil> for CustomFuture plus a user launcher with per-checkpoint stats and cancellation audits |
| 05 — Todolist web | cargo test -p todolist-web + node tests/e2e-browser.mjs | a full page app whose brain is a two-package rut project — ten DOM/timer crossings over web_sys on wasm32 |
| 06 — GitHub viewer CLI | cargo run -p rgh -- --repo=… --ref=… list | rgh — an async rut brain over the std http lane; headers-then-stream downloads, fixture-lane tests |
| The playground corpus | cd demo && npm run smoke | the classics: runnable programs, compiled and run by two gates |
All Cargo commands run from the repository root. The runnable crates
share one session pattern — compile the module, verify the binary,
bind host fns, then drive it through typed vm.call sites — so the
pages cross-link often: 00 — Todolist establishes
the pattern and 06 — GitHub viewer CLI
stretches it the farthest.
The three dependency kinds
Every package carries a rut.toml manifest (see
Project structure and rut.toml),
and a manifest relates a package to other packages through three
tables, all visible in the examples:
[deps]— ordinary dependencies, transitively mounted. The common case:03-plugin’splugin/rut.tomldeclaresserver = { path = "../server" }, and 05 — Todolist web’sbizpackage declaresui(which itself pulls the collection packages).[peer-deps]— required by default: the consumer supplies the peer and the peer is never pulled transitively. Marking a peeroptional = trueflips it to a presence relation: its integration file (impl-only code the peer makes compilable) mounts only when the peer is anywhere in the program’s closure. The in-tree example is the stdjsonpackage’s serde-model impls —impl JsonSerialize for Vec<T>is written in json but must not force every json consumer to mount the collection packages, so those live as optional peers and as[dev-deps]for json’s own tests. 02 — Digest consumes json light; 06 — GitHub viewer CLI callsassemble_peersand mounts the impl groups for real because the collections are in its closure.[dev-deps]— mounted only while building the package itself, never in a consumer’s world. json develops against the real collection packages through the both-kinds pairing while its consumers mount it without them.
The full rules — the loud missing-required-peer error, the silence of absent optional peers, dedup-by-origin at the splice, and what bundle format the packer emits — are on Dependency kinds.
Reading order
New to the language: read 00 — Todolist and 01 — Sort for the embedding shape, then The playground corpus for the language surface in small doses. For the web story, 05 — Todolist web is the centerpiece and 06 — GitHub viewer CLI is the networking counterpart. 03 — Plugin is the one to study for packaging and module loading, and 04 — Custom async for what the future trait looks like from user code.