exercism/rust, a track of practice exercises with a closed contribution queue

What a track repository is, and what this one holds

exercism/rust is one of many programming language tracks on exercism.org, and the repository description is precise about its contents. It holds all the instructions, tests, code and support files for the Rust exercises currently under development or implemented and available for students.

That word exercises is doing a lot of work. An Exercism exercise is not a tutorial chapter. It is a small problem with a stub file, a set of tests, an instructions document written for the student, and usually an example solution that lives in the repository as the reference the tests were written against. The student's job is to make the tests pass, and the interesting part for a learner is that a human mentor looks at the code afterwards.

The repository layout reflects that structure. There is an exercises directory holding the individual exercises, a concepts directory for the concept material the track defines, a docs directory, a bin directory for the scripts that operate on the track, a config.json that describes the track to the platform, a rust-tooling directory for the Rust specific tooling, a mise.toml for task running, and a .appends directory for content that is appended to exercise files.

There is also a .markdownlint.yaml, which is a small clue about the scale of the repository. Exercism exercise instructions are markdown documents written by many people over years, and they are linted like documentation, not like code.

The track page is at exercism.org/tracks/rust, and the licence is MIT.

No syllabus, so the Rust track is practice from day one

The most important design fact about this track is stated early and it shapes everything else. Some Exercism language tracks have a syllabus meant to teach the language step by step. The Rust track's syllabus is a work in progress and is not activated yet, and all exercises presented to students are practice exercises.

Students are expected to learn the language themselves, for example with the official book, and practice with the exercises.

That is a real difference from the tracks that do have a syllabus, and it is worth being clear about what it means in practice. A syllabus track walks you through concepts in a designed order, each one introduced by a concept exercise and reinforced by practice exercises, so a beginner never meets an unfamiliar idea without context. This track does not do that. Every exercise is a standalone problem, and the ordering is not a curriculum.

The consequence is that the track suits a particular person well: someone who already knows some Rust, or who is learning alongside a book or another resource, and who wants a supply of well-specified small problems with test suites and mentor feedback. For a complete beginner with no other material, the absence of a syllabus makes the track a harder entry point than it looks.

The concepts directory in the repository is where the syllabus work will land when it is activated, which is a reasonable thing to know if you are interested in that direction.

The contribution queue is closed, and the forum is the alternative

The repository says it plainly, in a sentence of its own: the maintainers are not accepting community contributions at this time, and there is a link to a community blog post for details. The badge in the header says the same thing, marked as contributions paused, and the repository topics carry a community contributions paused tag alongside a maintained tag.

So the two tags together describe an interesting state. The track is maintained, in the sense that the exercise content and the tooling are still being worked on, and the last push was on 2026-10-09. What is paused is the inbound flow of new exercises and improvements from outside the maintainer group.

The project redirects that energy rather than discarding it. Suggestions for a new feature or a new exercise should go through the Exercism Community Forum, and the recommendation is to read the suggesting exercise improvements guidance and Chesterton's Fence before doing so, with the claim that thoughtful suggestions will likely get faster and more enthusiastic responses from volunteers.

Chesterton's Fence is the right reference for this situation. It is the idea that you should not remove a fence until you know why it was put there, and applied to a track it means that an exercise which looks redundant or badly written may exist for a reason a newcomer cannot see from the outside. The pause is best read that way.

For anyone planning to contribute, the practical answer is that this repository is not the place right now, and the forum is.

The specifications that decide what a good exercise looks like

For anyone who wants to understand what the track expects, the repository links the entire specification set, and the links are the most useful part of the documentation for a technical reader.

There is the track structure documentation, which describes how a track is laid out, and separate documents for tasks, for concepts, for concept exercises and for practice exercises. There is exercise presentation, which covers how an exercise is written and formatted, and a writing style guide with a markdown specification, both of which live in the exercism/docs repository rather than here.

That split matters. The specifications are shared across every track, so an exercise written for Rust is written to the same rules as an exercise for any other language. The Rust specific material is in this repository, and the rules are somewhere else, and a contributor who only reads the local documentation will miss half of what they need.

The document set is also a reasonable description of the pedagogical model. Concepts are the ideas the track can teach, concept exercises introduce one, practice exercises reinforce one or several, tasks are the end of track pieces, and presentation covers the formatting rules that make a student experience consistent across tracks. Even without an activated syllabus, the track defines the vocabulary.

The community documentation is in the same set: the code of conduct, being a good community member, the words that we use, and the role definitions for contributors, mentors, track maintainers and admins.

Rust tooling in the repository, and a track built to be generated

A few top level entries are specific to Rust, and they tell you how a track of this kind is maintained.

The rust-tooling directory holds the Rust specific tooling for the track, and the bin directory holds the scripts that operate on it. The mise.toml file is a task runner configuration, which is how the repository runs its checks consistently on every machine, and the.github directory holds the workflows, including the CI badge the header points at.

The bin directory is the more interesting one. An Exercism track is not just a folder of exercises, it is a repository that generates the student facing artefacts: the stub files a student starts from, the example solutions used to validate the tests, and the per exercise configuration the platform needs. Those steps are scripts, and they are versioned with the exercises, so a change to the test format or the stub layout is a change anyone can run and check.

The.appends directory points at the same idea from the other end. Content that has to be appended to exercise files, such as shared instructions or language specific notes, lives in one place and is applied by the tooling, rather than being copy pasted into every exercise and left to drift.

For a learner, none of this is visible, and that is the point. For a maintainer, it is the difference between a collection of documents and a build that produces them, and it is why a track with a closed contribution queue can still be maintained rather than merely archived.

MIT licensed, no releases, and a moving main branch

The licence is MIT, which matters for a specific and practical reason. The exercises, the tests, the instructions and the example solutions are all in this repository under a permissive licence, so a company can use them internally, adapt them for a workshop, or build its own training material from them without asking.

There are no GitHub releases. That is normal for a track repository. There is nothing to version as an artefact for a consumer, because the platform reads the repository and the content is the deliverable. The default branch is main, and the last push was on 2026-10-09, so the content is being maintained even while contributions are paused.

The header carries a CI badge, so the exercise test suites are actually run somewhere, which is the mechanism that catches an exercise whose tests no longer pass for a change in the Rust compiler or in the test template.

The other thing the project says is that students are expected to learn the language themselves, with the official Rust book linked as an example, and the track is for practice. Combining that with the paused contribution state gives a clear picture: this is a maintained corpus of exercises that learners use, rather than a community project in the middle of a growth phase. Both things are true at once, and the second one is the reason the repository is not where the interesting work is happening right now.

Editorial conclusion

Adopt this track as a practice corpus if you want a set of small Rust problems with tests and human mentor review rather than a guided course, and work through it alongside the Rust book the project points to. Do not plan to contribute exercises to it now, because the maintainers have paused community contributions and the project asks for suggestions through the community forum instead. Before you start, read the practice exercises documentation and the presentation rules so you know what a submitted solution is expected to look like.

Frequently asked questions

Official sources

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