AWS Open Source Blog
Innovating with Rust
The Rust programming language is an open source project started by Mozilla Research more than a decade ago. Since then, more than 5,000 people have contributed to the Rust project, and the language has had a resounding impact on technology. Technology companies, large and small, are using and benefiting from Rust.
The Rust language builds on the superpowers of other languages and innovates when required to deliver big on performance, reliability, productivity, and accessibility. Because Rust does not require a runtime or garbage collector, it can achieve runtime performance similar to C and C++. At the same time, Rust uses a strict type system and ownership model to achieve compile-time verification of memory and concurrency safety, making the cost of testing and validating Rust implementations significantly lower than C and C++.
Mission and goals
The Rust language has quickly become critical to building infrastructure at scale at Amazon Web Services (AWS), and we’re adapting models for parallel development to incorporate agility in the language. We’re bringing in people from the Rust community and innovating on models for integrating open source developers into our organizations. Our goal is to support the mission and future successes of the Rust project and community, while finding opportunities to scale the expertise of the Rust community. In support of these goals, we borrowed from the open source model for growing contributors, and it worked.
In 2019, my AWS team had a prototype built by brilliant engineers who had learned Rust implementing a greenfield solution using Tokio. We were struggling to meet customer performance expectations with the confounding challenges of lack of expertise in Rust, complexity of building with Tokio 0.1, and shortcomings in performance profiling tools for Rust. We hired members of the Tokio core team and embedded them with the existing product team. The model of embedding open source maintainers and contributors within an engineering team building a product with a dependency on that project is pretty common. What our team did differently was the model within the team.
Contribution model
Open source engineers embedded in a product team typically are asked to spend between 20 and 50 percent of their time on open source work and the balance on the team’s product and mentoring. This approach can work well for the team overall, but it is challenging for the open source engineer. An engineer’s career advancement is a function of their impact to the business, and it is challenging for a manager to look beyond their immediate product into their open source dependencies. Additionally, many senior open source engineers are leaders in their projects and their contributions involve work such as triaging, roadmap planning, and mentoring. This work can be difficult to value on our own teams and becomes nigh impossible to quantify in an unfamiliar space.
We turned that model upside-down. When we embedded the Tokio engineers in our product team, instead of asking them to contribute part time to the product, we had those engineers continue to dedicate 100 percent of their capacity to open source and gave the rest of the team the choice to dedicate 20 percent of their time to contributing to the Tokio stack. We had fantastic results. The whole team gained expertise in Rust and Tokio by contributing to Tokio’s 1.0 launch at the end of 2020. Additionally, the team was able to deliver our product to customers by working with the Tokio open source community to deliver for all Rust developers.
This model worked really well for our team, because the product we were developing was so closely aligned to the work the Tokio team was doing in 2020. But that’s not easy to achieve year after year, and doesn’t extend to other parts of the Rust project, where there’s equally important work to be done. As we grew the number of Rust open source maintainers and contributors on the team, embedding them within a single product team no longer made sense, so we created a new team with a model for open source that evolved from that experience.
AWS Rust team
The AWS Rust team is comprised of maintainers and contributors to the Rust language and compiler teams as well as the Tokio stack, and we are working 100 percent in the open on the Rust project and ecosystem. We are a new model for a team, and it’s not just the way we work that’s different. We see the need to evolve the model for a successful engineer to include the model for successful open source maintainers and contributors.
The skills of an open source engineer extend beyond typical engineering capabilities. Experienced open source maintainers have the skills of a startup owner, including marketing, product development, project management, and recruiting. Thus, we need to recognize and value a different model for a successful big tech engineer on open source teams like the AWS Rust team. We only realize the full value of our talent when we value our talents. Engineers on the AWS Rust team will continue to invest significant time supporting their Rust project open source teams, speaking at events, and growing and developing Rust talent.
The AWS Rust team also connects other AWS teams with the Rust ecosystem and the Rust project. We’re extending the successful relationship model the Tokio engineers had with the original product team to the relationship the AWS Rust team will have with all AWS teams. We’re working to enable a world in which all AWS developers using Rust participate in the maintenance and improvement of the libraries we use, or of the compiler itself. That effort will have a ton of benefits. It will help to sustain the libraries, of course, and it will identify opportunities for optimizations or other improvements that will benefit our AWS services.
Our AWS Rust team’s first task was figuring out how best to relate to both AWS and the broader open source community. We knew we wanted to operate in the open and as members of the community at large. At the same time, we knew that we wanted to take full advantage of being at AWS. Drafting a charter and tenets was part of our process for finding a way to do both. The AWS Rust team’s charter is simple: The AWS Rust team works to make Rust performant, reliable, and productive for all its users.
We use tenets at AWS to convey what a team, project, or other sort of effort is all about. Each of our tenets captures one core belief or principle that informs our team’s decisions. They are specific to our team and help us focus on delivering value. The tenets are not meant to be written and forgotten. They are actively used during day-to-day operations to help guide us as we figure out how to resolve issues.
Our tenets prioritize the specific needs of engineers building cloud computing solutions. We are an AWS team. We lead the development of tools and mechanisms for building and operating services in the cloud, and we leverage our proximity to AWS services to gather insights that help us improve Rust.
AWS engineers are choosing Rust for its unique combination of fast, consistent performance, memory, and concurrency safety. We help Rust deliver on its promise. The AWS Rust team focuses on the developer experience, optimizations, and tools for the features our AWS engineers will use to build and operate services that take full advantage of the Rust promises of performance and safety.
Our tenets also describe how and where we build. We work in the open. We share and collaborate on our designs openly with the community. We believe this improves the quality and value of our deliveries. We support the communities we are a part of. We do our share of the “needful things,” like triaging issues, grooming backlogs, mentoring and onboarding other contributors, participating in design discussions, and fixing bugs.
Vision and support
One example is our support of the Rust Async Foundations Working Group’s new vision initiative. The Rust project’s governance is delegated across autonomous teams, distributing decision-making for documentation, language design, compiler, infrastructure, release, and more. This distributed system of governance empowers more owners across the project, enabling project teams to make faster decisions aligned by the principles of performance, reliability, productivity, and accessibility.
The Rust Async Foundations Working Group is innovating on open source product design by building a shared vision for Async Rust through a community-wide collaboration to create a shared vision document for Async Rust, and engineers from the AWS Rust team are supporting this work by contributing our own user stories and leading writing workshops to help others contribute successfully, too.
The vision document starts with a cast of characters, tied to particular Rust values (e.g., performance, productivity, etc.) determined by their background; this background also informs the expectations they bring when using Rust. For each character, the community is writing “status quo” stories that describe the challenges they face in achieving their goals and “shiny future” stories that describe the world of async 2 or 3 years in the future. The group believes Rust can become one of the most popular choices for building distributed systems, ranging from embedded devices to foundational cloud services.
Engineers at cloud providers such as AWS, Microsoft, Google, and Huawei are already choosing Rust, because it enables them to build services much more quickly and at a lower cost. The consistently high-performing, memory-safe, concurrency-safe Rust implementations those engineers are deploying are also consuming minimal energy [1]. The result is that the accessibility of Rust is driving fast and broad adoption that will deliver better sustainability for computing. For cloud computing companies, moving to Rust for critical, high-throughput services delivers better experiences, safer systems, and more sustainability where the impact is greatest.
These companies have also come together with Mozilla, the creator and original corporate sponsor of the Rust project, to create the Rust Foundation with the mission to empower Rust maintainers to joyfully do their best work. The Rust Foundation board includes directors from all of the founding sponsors, AWS, Microsoft,Google, Huawei, and Mozilla, as well as five Rust project directors, and Facebook, our newest sponsor.
The directors and the corporate sponsors that we represent recognize that we’re the beneficiaries of amazing contributions from a large community of Rustaceans, and we are excited to be able to participate in Rust’s future successes through the Rust Foundation. It’s still very early days for the Foundation, but I envision it becoming an organization that provides the Rust project maintainers with the support I provide my own AWS team. We make Rust truly accessible when we eliminate maintainer out-of-pocket costs for compute, storage, and productivity tools. We can also provide access to resources like leadership and communication training to help Rust maintainers grow themselves and their teams. Rust Foundation programs will support the volunteer work of Rust maintainers, and many Foundation sponsors are also choosing to invest directly in teams like the AWS Rust team.
Continuing evolution
As the Rust project funding model evolves into dedicated, embedded teams like the AWS Rust team, the Rust community’s openness to borrow from prior art and innovate when necessary to achieve the goals of performance, reliability, productivity, and accessibility will have a resounding impact far beyond technology. The Rust language, project, community, foundation, and corporate sponsors are working together, and the result will be improved performance, memory safety, concurrency safety, greater sustainability, scalable governance, innovative product and project mechanisms, and a more diverse and inclusive engineering community. Just — wow! 🙂
1. Rui Pereira et al., Energy Efficiency across Programming Languages: How Do Energy, Time, and Memory Relate?, SLE 2017, October 23–24, 2017, Vancouver, Canada.
This article originally appeared in Java Magazine, Vol. 6 in April 2021 in German translation.