Read the original design rationale and tradeoffs behind any Rust language feature by looking up its RFC document.
Propose a new Rust language feature by writing an RFC using the provided template and opening a pull request.
Track the status of a Rust proposal by reading the discussion and Final Comment Period on its pull request.
Understand why a Rust feature works the way it does by studying the accepted RFC that introduced it.
| rust-lang/rfcs | ethereum/ethereum-org-website | missing-semester-cn/missing-semester-cn.github.io | |
|---|---|---|---|
| Stars | 6,487 | 5,926 | 7,240 |
| Language | Markdown | Markdown | Markdown |
| Setup difficulty | easy | moderate | easy |
| Complexity | 1/5 | 3/5 | 1/5 |
| Audience | developer | developer | developer |
Figures from each repo's GitHub metadata at analysis time.
This repository is the official place where significant changes to the Rust programming language are proposed, debated, and decided. RFC stands for Request for Comments, and each RFC is a document that describes a proposed change, explains why it is needed, and addresses the tradeoffs and alternatives considered. Not every change to Rust goes through this process. Small bug fixes, documentation improvements, and minor additions can go straight into the codebase through a normal pull request. The RFC process is reserved for changes that affect how the language looks or behaves in meaningful ways, like adding new syntax, removing existing features, or making large additions to the standard library. When someone wants to propose a change, they write a document using a provided template and open a pull request in this repository. The community then discusses the proposal in the pull request comments. Once the discussion matures, the relevant group of maintainers (called a sub-team) can call a Final Comment Period, which is a 10-day window for any last objections before a final decision is made. If accepted, the RFC document is merged into this repository and the feature can then be implemented in Rust itself. Acceptance of an RFC does not guarantee the feature will be implemented quickly, or at all. It means the design has been agreed upon in principle. The RFC author is encouraged to also write the implementation, since approved proposals do not automatically get assigned to a developer. The repository itself is just a collection of Markdown text files, one per proposal, organized by number. There is also a browsable book version of all accepted RFCs linked from the repository homepage.
The official archive of every significant Rust language change proposal, each RFC document records why a feature was added, what alternatives were rejected, and how the community decided.
Mainly Markdown. The stack also includes Markdown.
License details were not included in the explanation.
Setup difficulty is rated easy, with roughly 5min to a first successful run.
Mainly developer.
This repo across BitVibe Labs
Verify against the repo before relying on details.