Rust Boom: a curated Rust resource index with an agent in the loop

A catalogue for people who read Chinese

Rust Boom is a collection of Rust learning materials, development tools, libraries and frameworks, finished applications, and the questions and solutions people hit while learning, organised so that a beginner can find resources that suit them.

The project description says it in Chinese, and the whole resource is written in Chinese, which is the point of it. There are plenty of Rust link collections, and the majority are in English. This one exists for the reader who wants an article, a video course, a book or a systematic tutorial in Chinese, and it is a different proposition from the upstream Rust list it resembles.

The navigation is a table with six entries. Learning materials cover articles and periodicals, video courses, books and systematic tutorials. Development tools cover the editing environment, Cargo extensions, front end tooling and runtimes. Libraries and frameworks cover GUI, web, async, database access, graphics, multimedia and FFI. Finished applications cover editors, terminals, database servers, search engines and system tools. Community and news cover community forums, historical news and events. And a final page lists all categories with the number of resources in each.

The site is published at rust-boom.github.io/rust-boom, and the repository is a mixture of Markdown, Node tooling and Rust example crates, which is itself a hint about how the project is maintained.

Stable identifiers, per-resource pages, and an honest status field

One design decision runs through the catalogue: every resource has a stable ID and its own introduction page. The navigation is not a wall of links but a set of directories of documents, and a resource can be revised without changing how it is referenced elsewhere.

The second decision is about honesty. The maintenance status of a historical resource defaults to pending verification, and resources whose original text explicitly marks them as no longer updated keep that mark. Then comes the sentence that matters most for a reader: inclusion and migration do not represent verification of external links, of a project's current state, or of the timeliness of the information in the description.

That is a careful and unusual thing to state in a resource list, and it is the difference between a catalogue and a mirror of somebody's bookmarks. A link list that quietly accumulates dead entries is worse than no list, because it costs a reader the time to find out. This one tells you up front what the list is worth.

The maintenance documents make the same point structurally, with separate pages for the directory and category conventions, for AI maintenance and delivery, and for credits and material sources, plus a page for the illustrations. Those pages are the place to look if you want to know how the catalogue is put together and who to credit for the entries.

The repository's own tutorials, and the Rust examples beside them

Alongside the external links, the repository carries its own teaching material, and the README is careful to separate it from the external articles. The tutorial index collects the repository's own articles and their Rust examples, and the external articles in the learning section are maintained separately.

Three tutorials are listed, and they are a considered sequence rather than a random selection. Move, Copy and Clone. A method overloading pattern. And polymorphism with dyn Trait.

Those three are a good curriculum for a particular audience, because they are the questions a Rust learner actually asks after the basics. Ownership and the difference between the three ways of moving a value is where a lot of people first get stuck. Method overloading is the question that a Rust programmer arriving from another language asks, since Rust has no overloading and the answer involves traits. And dyn Trait is the moment a learner meets dynamic dispatch, which is the point where the shape of Rust's abstraction story becomes clear.

The Rust code is not decoration. The workspace in the Cargo manifest has members of docs/* and play/*, which is a directory of small crates, one per tutorial or example, each independently compilable. A reader who clones the repository can build and run each example rather than reading pseudocode.

How a link gets into the catalogue

The maintenance section describes two submission routes and one unusual mechanism, and the mechanism is the most interesting part.

For a contributor who only wants to provide a link, there is an issue form for giving an agent a link and having it collected automatically. The maintainer assigns the issue to Copilot, and then a resource-curator agent reads the material, checks for duplicates, classifies it, writes a Chinese description and opens a pull request. The README points at the agent collection guide for the configuration, which has to be published to the default branch and Copilot enabled before it works.

The second route is the same idea with more typing: an issue form for adding or updating a Rust resource, filled in by hand, or a pull request submitted directly following the contribution guidelines. Resources go into the catalogue after review and merge.

So the pipeline is: a human decides what should be in the catalogue, an agent does the mechanical work of reading, deduplicating, classifying and writing the Chinese description, and a human reviews the pull request. That is a sensible division. The judgement about what belongs in a Rust resource list is not something to delegate, and the writing and filing is exactly the kind of work an agent does well.

The README also notes the design for a later stage, that subsequent automatic dispatch of agents and full automatic field writing is covered in the GitHub workflow proposal document.

What the pull request checks actually enforce

The validation step is described in one sentence, and it is a list worth reading, because a catalogue that is generated rather than hand-maintained needs a check to make sure the generation and the sources agree.

The pull request check verifies the resource metadata, the category, duplicate IDs and duplicate main links, local file links, and whether the generated catalogue is consistent. In other words, the generated output is treated as a build artefact that must agree with its inputs, and the structural rules of the catalogue are machine-checked rather than trusted to review.

The Node tooling in the root package.json is what does it. There is a catalog script that regenerates the catalogue, a check script that runs the same code in check mode, a verify script for checking the resources themselves, and a test script that runs node --test over the catalogue tests, the agent delivery tests, the merge review tests and the resource verification tests. The only runtime dependency is yaml at a pinned 2.9.1, which is a small enough surface to review.

So the workflow is: a source of truth for the entries, a generator that turns it into the navigable pages, a checker that fails the pull request when the two disagree, and a test suite over the checker itself. That is a small piece of engineering that turns a link list into something that stays true.

Where a resource index is the wrong tool

The first wrong-tool case is authoritative documentation. The Rust book, the standard library documentation and the crate registry are the sources of truth for how Rust works and what a crate does, and a curated list is a pointer to them at best. A reader who treats a catalogue entry as a specification will be disappointed by a list that says it does not verify the state of a project.

The second is a question about current versions. A catalogue carries a description written at a point in time, and the pending verification status is the honest way of saying so. If your question is which version of a crate is current, the registry answers it and the catalogue does not.

The third is the maintenance burden of a language ecosystem. Rust moves, crates are renamed and deprecated, and a catalogue about Rust ages exactly as fast as the ecosystem it describes. The status field and the per-resource pages mitigate that, and the agent-assisted pipeline makes the updating cheaper, but a reader should expect to check anything important themselves.

There is also a scope point. The catalogue is for beginners, which is stated in the project description, and the tooling and the workflow are built for a contributor base that will grow through issue forms rather than code. A team looking for an internal list of approved libraries needs a different artefact, with a named owner and a review cadence.

MIT, a very recent commit, and a bilingual workflow

The project is MIT licensed, with the LICENSE file at the repository root, and the site configuration sits in _config.yml, which is the file that turns the Markdown into the published site. The default branch is master, the repository is not archived, and the last push was on 2026-10-17, two days before this review, so the catalogue is actively maintained.

The primary language of the repository is recorded as JavaScript, which is worth explaining rather than repeating, because the content is Chinese and the subject is Rust. The JavaScript is the tooling: the scripts/ directory holds the catalogue generator, the checks and the tests, the .agents/ directory holds the agent configuration and its skills, and the package.json declares Node 22 or newer as the engine requirement. The Rust in the repository is the example code in the workspace members docs/* and play/*.

So the repository is a site with a build pipeline, a set of small Rust crates, and a catalogue of external resources, and the pipeline is the part that is unusual. There are no GitHub releases, since the artefact is a website and a set of documents, and the AGENTS.md and CONTRIBUTING.md at the root, together with the maintenance/ directory, are the documentation for a project whose main workflow runs through issues and agents rather than through code changes.

For a reader in Chinese looking for Rust material, the navigation table is the fastest way in, and the pending verification status is the fastest way to know how much to trust what you find.

Editorial conclusion

Adopt Rust Boom if you are learning Rust in Chinese or maintaining a Chinese-language learning path, and treat the entries as a starting point rather than as verified fact, because the README says the catalogue does not confirm external links or the current state of a project. Do not adopt it as a substitute for the Rust book, the standard library documentation or the crate registry, all of which are more authoritative for their own questions. Before you rely on an entry, check the linked project yourself, and before you contribute, read CONTRIBUTING.md and the maintenance documents, since the submission process has a specific shape with issue forms, an agent and a set of automated checks.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. rust-boom/rust-boom on GitHub