# Inside Rust Blog Want to follow along with Rust development? Curious how you might get involved? Take a look! This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Welcome Dongpo and Ross to the Cargo team DevFeed: [Welcome Dongpo and Ross to the Cargo team]() Original publisher: [Read original article]() Author: Weihang Lo Published: 2026-09-08T00:00:00Z Content type: news Language: en Sources: [Inside Rust Blog]() Topics: [Rust](), [Development](), [Caching](), [Testing]() Tags: [2026](), [caching](), [rust]() ### AI overview The Rust Project announces Dongpo Liu and Ross Sullivan joining the Cargo team. Ross is leading the 2026 cross-workspace caching goal, while Eric Huss steps down and Jacob Finkelman and Weihang Lo become Cargo's new co-leads. ### Source excerpt We are excited to welcome Dongpo Liu and Ross Sullivan to the Cargo team! Dongpo has contributed to the Rust Project for years across different teams. He has been an important bridge between Cargo and other Rust teams and has brought insights and fresh ideas from across the Project. Dongpo also integrated cargo info from an external experiment into Cargo as a built-in command. That fulfilled a feature request that was nearly ten years old! He is also a kind and thoughtful reviewer. He always gives careful feedback and takes the time to help contributors. Fun fact: Dongpo joined the team in December 2024, but we never publicly announced it! Ross is brave and a deep thinker. In his first Cargo contributions, he jumped straight into one of Cargo's hardest topics: build artifact management and caching. He has shepherded the new build directory layout through design, implementation, and extensive community testing. This work lays a great foundation for cross-workspace caching and many other future optimizations. He is now leading the 2026 Project Goal for cross-workspace caching! Ross also always takes responsibility for his work. He responds quickly in discussions, fixes regressions, and helps unblock other teams. We are very glad to have him on the team. At the same time, Eric Huss has stepped down from the Cargo team. He contributed to the Rust Project for nearly a decade and served as a Cargo team lead for more than seven years. Eric's fingerprints can be found across basically every part of Cargo. He was our go-to person whenever we needed to understand the history of Cargo. In fact, his work reached far beyond Cargo. He maintained mdBook and books such as the Rust Reference and the Rustonomicon. He also helped lead the Edition work and represented the Dev tools team on the Leadership Council. Cargo and the Rust Project are much better because of him. Thank you, Eric! With Eric stepping down, the Cargo team has selected Jacob Finkelman and Weihang Lo as its new co-l ## 1.98.1 pre-release testing DevFeed: [1.98.1 pre-release testing]() Original publisher: [Read original article]() Author: Release automation Published: 2026-09-02T00:00:00Z Content type: release Language: en Sources: [Inside Rust Blog]() Topics: [Rust](), [releases](), [Release notes]() Tags: [pre-release](), [release](), [rust](), [testing](), [update]() ### AI overview The Rust 1.98.1 pre-release is ready for testing and is scheduled for release on September 3. The article provides instructions for trying it locally and links to release notes and feedback channels. ### Source excerpt The 1.98.1 pre-release is ready for testing. The release is scheduled for September 3. Release notes can be found here. You can try it out locally by running: RUSTUP_DIST_SERVER=https://dev-static.rust-lang.org rustup update stable The index is https://dev-static.rust-lang.org/dist/2026-09-02/index.html. You can leave feedback on the internals thread. General feedback about our pre-release process is welcome on this GitHub issue. ## Program management in July-August 2026 DevFeed: [Program management in July-August 2026]() Original publisher: [Read original article]() Author: Nurzhan Saken Published: 2026-08-31T00:00:00Z Content type: article Language: en Sources: [Inside Rust Blog]() Topics: [Rust]() Tags: [2026](), [funding](), [infrastructure](), [project](), [rust](), [update]() ### AI overview The Rust project's July-August 2026 program-management update reports seven newly opened goals, one completed goal, two discontinued goals, and changes in goal funding. It also covers project updates, repository and Zulip channel renaming, improved goal-owner reporting, configurable reminder frequency, and automatic Zulip topic creation for proposed goals. ### Source excerpt It's been fun since the last update. Tomáš was away for a month, and I had to get my wisdom teeth pulled right after he left. Despite everything, a lot has happened! Project Goals Since the previous update, we've opened seven more goals: Contracts: primitive ownership assertions Process-Safe Rustup Toolchain Operations End-to-End Executable Rust Specification f16b Primitive Type Polymorphic code generation experiment C interop: Complex Allocators 1.0 There's now a roadmap for Binary size reduction, which includes async future and statemachine optimization goals, build-std, and future possibilities that aren't goals yet. One goal was completed (Stabilize Cargo's linting system), and two were discontinued (Experimental language specification and Continue Experimentation with Pin Ergonomics). Several goals have received partial funding (Incremental Systems Rethought, Native async fn dynamic dispatch in traits, and Cargo cross workspace cache), and some are now fully funded (C interop: f80, f128, and c_longdouble, C interop: Complex, and Async statemachine optimization). Don't forget to add your goal to the funding table if it needs funding (see template)! Some goal owners and contributors have been writing about their work beyond the regular goal updates. Here are some of the places to check out: Monthly updates by Hexcat Rust Maintainer Monthly Report: August 2026 by Gen Li Status Update - July 2026 by the BorrowSanitizer team Field Projection Designs by Benno Lossin Four levels of in-place initialization by Yoshua Wuyts Optimizing the new trait solver by Jana Dönszelmann Rust Function Overloading - Call for Experimentation by teor A Vision for a Rust Formal Specification by Nadrieril Infrastructure The Goals repository has been renamed to rust-lang/goals from the verbose rust-lang/rust-project-goals, and we've renamed the Zulip channels to #goals, #goals/proposed, and #goals/meta. The website now lives at goals.rust-lang.org; the old links should redirect there ## Electing new Project Directors 2026 DevFeed: [Electing new Project Directors 2026]() Original publisher: [Read original article]() Author: Manish Goregaokar Published: 2026-08-28T00:00:00Z Content type: article Language: en Sources: [Inside Rust Blog]() Topics: [Rust]() Tags: [2026](), [process](), [project](), [rust]() ### AI overview The Rust Project has launched its 2026 process to elect two Project Directors to the Rust Foundation Board. Project members are invited to nominate candidates by September 21, with the election following candidate gathering. ### Source excerpt Today we are launching the process to elect two Project Directors to the Rust Foundation Board of Directors. This is the fourth round of slots, following from last year's election. We will briefly explain the goals and procedures here, but this is mostly copy-pasted from last year's post and the official process documentation. We ask all Project members to begin working with their Leadership Council representative to nominate potential Project Directors. See the candidate gathering section for more details. Nominations are due by September 21. What are Project Directors? The Rust Foundation Board of Directors has five seats reserved for Project Directors. These Project Directors serve as representatives of the Rust Project itself on the Board. Like all directors on the Foundation board, the Project Directors are elected by the entity they represent, which in the case of the Rust Project means they are elected by the Rust Leadership Council. Project Directors serve for a term of two years and will have staggered terms. This year we will appoint two directors and next year we will appoint three directors. See the role description document for more details about what is involved in being a Project Director. The current Project Directors are Carol Nichols, David Wood, Jack Huey, Niko Matsakis, and Ryan Levick. This year, Carol Nichols and Ryan Levick's seats are up for reelection. We want to make sure the Project Directors can effectively represent the Project as a whole, so we are soliciting input from everyone on the team. The elections process will go through two phases: 1) candidate gathering and 2) election. Read on for more detail about how these work. Candidate gathering The first phase is beginning right now. In this phase, we are inviting the members of all of the top level Rust teams and their subteams to nominate people who would make good Project Directors. The goal is to bubble these up to the Council through each of the top-level teams. You should be heari ## 1.98.0 pre-release testing DevFeed: [1.98.0 pre-release testing]() Original publisher: [Read original article]() Author: Release automation Published: 2026-08-19T00:00:00Z Content type: release Language: en Sources: [Inside Rust Blog]() Topics: [Rust](), [releases](), [Release notes]() Tags: [pre-release](), [release](), [rust](), [update]() ### AI overview This article announces that the Rust 1.98.0 pre-release is ready for testing. It states that the release is scheduled for August 20 and provides instructions and links for trying it and submitting feedback. ### Source excerpt The 1.98.0 pre-release is ready for testing. The release is scheduled for August 20. Release notes can be found here. You can try it out locally by running: RUSTUP_DIST_SERVER=https://dev-static.rust-lang.org rustup update stable The index is https://dev-static.rust-lang.org/dist/2026-08-18/index.html. You can leave feedback on the internals thread. General feedback about our pre-release process is welcome on this GitHub issue. ## Rust Function Overloading - Call for Experimentation DevFeed: [Rust Function Overloading - Call for Experimentation]() Original publisher: [Read original article]() Author: teor Published: 2026-08-19T00:00:00Z Content type: release Language: en Sources: [Inside Rust Blog]() Topics: [Rust](), [C++](), [Compiler](), [interoperability]() Tags: [c-plus-plus](), [compiler](), [interoperability](), [languages](), [rust](), [syntax]() ### AI overview The Rust Project is experimenting with function and method overloading for FFI bindings through the incomplete nightly "splat" compiler feature. The experiment aims to assess implementation complexity and improve interoperability with C++, while its design may change or be removed. ### Source excerpt In partnership with the Rust Foundation's Rust-C++ Interop Initiative, the Rust Project has been experimenting with function overloading for FFI bindings. This experiment is now at a stage where compiler and interop tool developers can start exploring function overloading. Stable Rust already supports a form of overloading using tuples and traits, but calling these overloaded functions looks strange, because the overloaded arguments have to be passed as a single tuple argument, like this: hypot((2.0, 3.0, 6.0)). Stable Rust also allows overloading of built-in operators with user-defined types, via traits like Add (the + operator) and Neg (the - value negation operator). We are running an unstable nightly Rust language experiment to answer questions like: How much overloading can we do with Rust's existing trait system? Could this help us call C++ from Rust ergonomically? In the tradition of yeet (to avoid bikeshedding), we are using basic syntax in the first stage of the experiment: the #[rustc_splat] attribute. Alternative syntaxes can be considered later, if the experiment generates useful outcomes. Experimental Function Overloading Rust nightly builds from 2026-07-31 onwards have experimental support for more ergonomic function and method overloading, using the incomplete "splat" compiler feature; if you're a compiler or interop tool developer, we encourage you to experiment with it! This experiment lets overloaded functions be called with separate arguments, like this: hypot(2.0, 3.0, 6.0). No double parentheses required! But type inference and type checking still happen as they would in a stable Rust overload. We are experimenting with splat to get a feel for the complexity of the implementation, and to see if it solves some language interoperability use cases. Like most Rust language experiments, this nightly feature has no RFC, and can change or be removed at any time. Experiment Design We expect the feature to change significantly in future, or to be replace ## Experiment in reducing target directory size on nightly DevFeed: [Experiment in reducing target directory size on nightly]() Original publisher: [Read original article]() Author: Jakub Beránek Published: 2026-08-18T00:00:00Z Content type: article Language: en Sources: [Inside Rust Blog]() Topics: [Rust](), [Compiler](), [data]() Tags: [compilation](), [compiler](), [disk-space](), [information](), [rust](), [space](), [state]() ### AI overview The Cargo Team is testing -Zembed-metadata=no by enabling it by default on the nightly channel. The experiment aims to reduce Rust target directory size by avoiding duplicated crate metadata in build artifacts, while gathering feedback about viability and user impact. ### Source excerpt TL;DR: The Cargo Team will be rolling out an experiment to identify user impact for a proposed change. Cargo will enable the -Zembed-metadata=no feature on the nightly channel by default, which can help reduce the size of the target directory somewhat. This is an experiment designed to gather feedback about viability of this feature. Users are not expected to migrate to support this feature, but to report any issues and opt-out if needed in the meantime. What is this about? High disk usage of Rust compilation artifacts is frequently cited as one of the biggest annoyances of Rust users. In our 2025 State of Rust survey, it was actually the second most commonly reported problem, right after compilation speed. There are various reasons why the target directory can become quite large, such as: Cargo compiles the whole crate graph from scratch by default, which produces a lot of build artifacts. Debug information takes a lot of disk space. Incremental compilation artifacts take a lot of disk space. While you can disable debug information or incremental compilation to reduce the target directory size, that of course comes with severe trade-offs in compilation speed and debuggability of your program. However, there is one source of data in the target directory that currently takes too much size even though it doesn't really have to. It is the "crate metadata", which can be duplicated across multiple files. We will focus on that in this blog post. What causes duplicated (meta)data For years, Cargo has been using pipelined compilation to speed up building of crate graphs. When compiling a library crate, it tells the compiler to produce an .rmeta file (which contains all the crate metadata required to use this library) as soon as possible, even before having the final executable code available. This enables dependent crates to start compiling sooner. However, once the library does finish compiling, the final produced .rlib file will contain both the executable code and the Ru ## Leadership Council September 2026 Representative Selections DevFeed: [Leadership Council September 2026 Representative Selections]() Original publisher: [Read original article]() Author: Jakub Beránek Published: 2026-08-18T00:00:00Z Content type: release Language: en Sources: [Inside Rust Blog]() Topics: [Rust]() Tags: [2026](), [leadership](), [rust](), [september-2026](), [teams]() ### AI overview The Rust Leadership Council representative selection process is beginning for the Infra, Lang, Libs, and Mods teams. Teams are expected to confirm representatives by September 23, 2026, with new members joining council meetings from September 25. ### Source excerpt The selection process for representatives on the Leadership Council is starting today. Every six months, half of the council terms end. The following teams are up to choose their representative for the next year: Infra Lang Libs Mods We are aiming to have the teams confirm their choices by September 23, 2026, and for any possible new members to be ready to join the council meetings starting September 25th. Criteria for representatives Any member of the top-level team or a member of any of their subteams is eligible to be the representative. See candidate criteria for a description of what makes a good representative. There is a limit of at most two people affiliated with the same company or other legal entity being on the council 1. During the selection process, the council will consider the affiliation of candidates to decide if all choices will be compatible with that constraint. Representatives may serve multiple terms if the team decides to choose the same representative again. There is a soft limit of three terms.2 It is recommended that teams rotate their representatives if possible to help avoid burnout and to spread the experience to a broader group of people. What do Representatives do? A representative provides a voice on the council to represent the interests of their teams and contribute to the long-term success of the Rust Project. A detailed description of the role may be found at the Representative Role Description. How should teams make their selection? The Leadership Council has put together a Representative Selection Guide with recommendations for teams on how to go about choosing a representative. It is not a requirement that teams follow this guide; top-level teams may choose their own process. See Limits on representatives from a single company/entity ↩ See Term limits. ↩ ## June 2026 Project Director Update DevFeed: [June 2026 Project Director Update]() Original publisher: [Read original article]() Author: Carol Nichols and David Wood Published: 2026-08-17T00:00:00Z Content type: news Language: en Sources: [Inside Rust Blog]() Topics: [Rust](), [Open Source](), [Security](), [C++]() Tags: [2026](), [c-plus-plus](), [open-source](), [rust](), [security](), [update]() ### AI overview The Rust Foundation's June 2026 board update covers policy discussions, committee review, infrastructure security improvements, sustainable funding ideas for crates.io, C++ interoperability work, upcoming Foundation activities, the Trusted Training program, and the Rust Commercial Network. ### Source excerpt This post covers the Rust Foundation board meeting that took place on June 9, 2026. Find the full June 2026 minutes on the Foundation's site. Highlights include: Abi Broom brought a draft Donation Acceptance Policy to the board for discussion; us Project Directors provided some feedback and gathered some feedback from the Project. The board discussed whether our current subcommittees were serving us, and we agreed to re-evaluate committee membership after Project Director selections in September. The Foundation has successfully distributed hardware 2FA tokens to all relevant Foundation and Project members to improve infrastructure security. The Foundation staff has started brainstorming possible ideas to fund crates.io sustainably in line with the Joint Statement on Sustainable Stewardship signed by many open source languages' package registry maintainers. These ideas are targeting heavy corporate usage and will be discussed with the Project and the Board before implementation. teor held a workshop on C++ interop at the All Hands and has been working on a number of other interop projects. There will be updates soon! The August board meeting will be cancelled, and there will be a hybrid in-person and online board meeting at RustConf in September. The Foundation is also running a Team Health Summit the day before RustConf. The Foundation is planning to coordinate with DARPA to gather an evaluation committee for TRACTOR submissions, which is a contest the board agreed for the Foundation to support in 2024. The Foundation staff and Project Directors will be connecting with the Project in Zulip soon to discuss any questions or comments about this initiative prior to DARPA soliciting Project input/evaluator volunteers. The Foundation launched its Trusted Training program with five initial training partners. The Foundation launched the Rust Commercial Network, a community where the companies and organizations running Rust in production work together, and with the Rust Proj ## Call for testing: Restricting trait implementability and field mutability DevFeed: [Call for testing: Restricting trait implementability and field mutability]() Original publisher: [Read original article]() Author: Ryosuke Yamano Published: 2026-08-10T00:00:00Z Content type: article Language: en Sources: [Inside Rust Blog]() Topics: [Rust](), [Testing](), [Code]() Tags: [compiler](), [implementation](), [rust](), [scope](), [sealed](), [testing]() ### AI overview Rust RFC 3323, "Restrictions," is ready for testing on nightly Rust. It introduces impl_restriction for limiting where traits may be implemented and mut_restriction for limiting where fields may be mutated. ### Source excerpt We are excited to announce that RFC 3323 "Restrictions" is ready for testing on nightly Rust. In this post, we will briefly describe the features. If you are already familiar with them, you can skip ahead to the How can I help? section. The RFC is split into two features: impl_restriction and mut_restriction. What is impl_restriction? The impl_restriction feature allows explicit restriction of the scope in which a trait may be implemented. For example, consider a trait Foo with a method that we want users to be able to call, while preventing downstream crates from providing their own implementations. With this feature, we can write: #![feature(impl_restriction)] pub impl(crate) trait Foo { fn method(); } impl Foo for usize { fn method() {} } The impl(crate) restriction prevents Foo from being implemented outside the current crate. As with pub, other paths can also be specified, such as impl(super) or impl(in path). Without this feature, this use case is typically handled using the sealed trait pattern, which is described in the Rust API Guidelines. In short, this pattern defines a public Sealed trait inside a private module and makes it a supertrait of Foo. Because downstream crates cannot name Sealed, they cannot implement Foo. pub trait Foo: private::Sealed { fn method(); } // Implement `Foo` for selected types. impl Foo for usize { fn method() {} } mod private { pub trait Sealed {} // Implement `Sealed` for those same types, but no others. impl Sealed for usize {} } However, this pattern requires defining an additional Sealed trait. The new impl_restriction feature provides a more direct and concise way to express the same restriction. The feature also allows the compiler to produce a more direct error message when an implementation is attempted outside the permitted scope. For example, the following code: #![feature(impl_restriction)] pub mod foo { pub mod bar { pub(crate) impl(super) trait Foo {} } // `Foo` may be implemented here. impl bar::Foo for i8 {} } //