Rust is a programming language developed in the open, initially sponsored by Mozilla. Originally built for the purpose of creating a web browser, Rust was designed to be both highly efficient and highly safe. Despite only being in the market for just shy of three years, it’s already counted among the top 20 programming languages on GitHub. It’s likewise seen steady growth in commercial adoption, including by big names like Dropbox, npm, Baidu, Atlassian, and Wire.
Developers with a wide range of programming backgrounds drew on their experiences with C++, JavaScript, and Ruby to build Rust. From C++, programmers brought a keen focus on performance and an attention to detail for efficient programming abstractions. From languages like JavaScript and Ruby, they brought a packaging and dependency management system that seamlessly connects projects to the libraries they require, allowing projects as sophisticated as web browsers to be built with only a couple of steps. Ever-growing IDE support, readable error messages, and a strong sense of community around Rust help fill it out.
We’re constantly working to ensure that that sense of community—and that community itself—remains central to our maintenance of Rust. One way we’ve done this is by avoiding governance being overly dependent on any one company. Rust has a core team, a group of 10 volunteers and paid staff, only half of which are Mozilla employees. Many of these core team members lead the next layer of governance: sub-teams. Each sub-team is focused on an aspect of growing Rust: There’s a Community team, a Language team, a Compiler team, and so on. As Rust’s needs grow, so does the number of sub-teams. For instance, a new team was recently added to support the amount of testing each Rust release requires.
The Rust survey is a comprehensive annual survey intended to help us get a clear picture of how Rust is doing. The 2017 survey included both users and non-users of Rust, and garnered over 5,000 responses. From this data, the Rust teams can find strengths and deficiencies, which help form the proposal—a proposed roadmap—for the following year.
That can be a massive undertaking. For example, in January 2018, the Rust core team proposed the roadmap for the year, which was shaped by thousands of user messages, comments, and stories drawn from both from the 2017 survey and the #Rust2018 blogging campaign, a public call for users to share their vision of Rust’s future. After all that, all proposals must undergo review as part of the Request for Comment (or RFC) process in order to be approved as the official roadmap.
Every major decision in the Rust project goes through the RFC process. First, a proposal is written and posted as a pull request in the RFCs for changes to Rust repo so that others can comment. Anyone in the community can comment and share concerns or request clarifications. Discussion continues until no new points are raised. Then the appropriate team builds a summary of the discussion and comes to consensus on whether the RFC should be merged or not. Once merged, the decisions in the RFC become part of the foundation that the Rust project builds from.
To keep the RFC process—and releases, which I’ll elaborate on in a moment—moving forward, a series of bots work behind the scenes. The bots ping people who are required in a vote, monitor the health of systems, and more. The most well-known bot among Rust contributors is nicknamed “bors.” This bot’s job is to watch all incoming PRs and to test each against the regression suite. Once in the bors system, no human will accept any PRs. Instead, if a PR is ready to be accepted, the bot is notified, and it will test and accept the PR itself.
The release process is also a highly collaborative and community-oriented process. Rust releases follow the more modern dictum of “release early, release often.” An updated version of Rust is released into the world every six weeks. To make it into the release, a feature first lands in the nightly release, which any user can opt into. Here, testers try the feature against their own code and report on how well it works. The feature spends time on nightly, behind a flag, until the community feels it’s ready. Once a feature has matured to the point of stability, it “rides the train”—that is, every six weeks, the feature moves to beta, and those in beta move into the release. Features may spend multiple releases in nightly getting ready and then go through an additional 12 weeks of beta testing before being included in a release.
Each Rust release since 1.0 has maintained backwards compatibility with all previous releases. The result is that although there are new releases every six weeks, developers can keep their tools up to date without fear that an update could break them. This is done through the rustup tool, which allows developers to easily control the version of Rust on their system. The Rust survey puts the usage of the rustup tool at just over 90 percent of surveyed developers.
Through an open community, volunteer efforts in collective maintenance, and supporting infrastructure, Rust is growing—and striving every day to meet the demands of a vibrant user base.