The Rust Project’s 2025H2 goal cycle wrap-up lists 41 goals, 13 of them flagship. That is a lot of bullet points. Rather than walk the table of contents, I want to pull on the threads that I think will shape what writing Rust feels like in 2026: the Beyond-the-& cluster, the compile-time work, and the quiet but consequential progress on the next-generation trait solver.
Beyond the &: the reference is finally being unbundled
The flagship called “Beyond the &” groups three pieces of work that, taken together, attack a limitation Rust has carried since 1.0: the &T / &mut T pair is doing too many jobs at once. It is a borrow, a place, a pointer, and a lifetime witness. That bundling is fine for ordinary code and brutal for anything that wants to express partial borrows, pinned access, or projection into a field of a Pin<&mut T>.
The three sub-goals are pin ergonomics, field projections, and reborrow traits. Each one is a chip at a different facet of the same rock.
Pin ergonomics is the one async users feel most. Today, projecting through a Pin<&mut Self> to a pinned field requires either pin-project, pin-project-lite, or unsafe pointer arithmetic. The proc-macro approach works but it is a tax: another dependency, slower compile times, and a layer of generated code that obscures errors. The experimentation here has been around a native &pin mut T sugar, where pinning becomes a property of the reference rather than a wrapper type. If that lands, writing a hand-rolled Future stops requiring you to memorize the structural-pinning rules.
Field projections generalize that idea. The observation, made cleanly in Frank Steffahn’s RFC discussions and follow-up work, is that Pin, MaybeUninit, Cell, and UnsafeCell all want the same operation: given a wrapper around a struct, give me a wrapper around a field. Each currently solves it ad hoc, badly. A language-level projection mechanism would let library authors write one trait implementation and get safe field access for free. This is the kind of feature that looks small in the changelog and removes a category of unsafe code in practice.
Reborrow traits are the third leg. Right now the compiler reborrows &mut T for you implicitly when you pass it to a function, but you cannot opt user types into the same treatment. That is why Pin<&mut T> feels awkward to thread through call chains, and why custom smart pointers like those in the kernel’s Rust for Linux work hit ergonomic walls. Making reborrow a trait, and letting custom references participate, is one of those features that unlocks more than it adds.
Compile times: four different bets at once
The “Flexible, fast(er) compilation” flagship is interesting because the project is hedging. Four distinct strategies are being pursued in parallel, and they attack compile time from different angles.
build-std is about giving up the precompiled std so you can rebuild it with the same codegen settings as your crate. For embedded and no_std users this is unblocking; for everyone else it is mostly a way to enable things like custom panic strategies or sanitizers without a custom toolchain. Cargo’s unstable -Zbuild-std has been the workaround for years.
The Cranelift backend is the one I care about most for day-to-day work. LLVM is excellent at optimizing release builds and slow at everything else. rustc_codegen_cranelift targets debug builds specifically, and the numbers from earlier reports have been in the range of 20 to 35 percent faster for incremental debug compiles on representative workloads. Making it production-ready as a debug backend means most developers would see a real-world latency drop on every cargo check and cargo run.
Parallel rustc front-end is the long-running effort to remove the single-threaded bottleneck in compilation. The front end, name resolution, type checking, borrow checking, has historically been one thread while codegen fans out. Niko Matsakis and the compiler team have been walking this in carefully because the data structures involved were not built with Send in mind. Promotion to a default-on configuration would be the largest single-machine speedup most users have seen since incremental compilation landed.
“Relink don’t rebuild” is the cheekiest of the four. The idea is that when you change a leaf crate, you should only have to relink the binary, not recompile dependents. For a 200-crate workspace this is the difference between a five-second iteration loop and a fifty-second one. The mechanism leans on stable interface fingerprints so the compiler can decide which downstream work is actually invalidated.
Any one of these would be a meaningful win. The bet, sensibly, is that several will land and stack.
The next-generation trait solver is the foundation
The “Unblocking dormant traits” flagship reads like a grab-bag, but the connecting tissue is the next-generation trait solver. The current solver has been patched for a decade and has known soundness holes around higher-ranked types, associated types, and coinductive cycles. Several long-promised features sit behind it: better GATs, async closures interacting cleanly with Send bounds, and the Polonius borrow checker.
Polonius itself, listed as the “Stabilizable Polonius support on nightly” goal, is the Datalog-based reformulation of the borrow checker that finally accepts code like
fn get_or_insert(map: &mut HashMap<K, V>, key: K) -> &mut V {
if let Some(v) = map.get_mut(&key) {
return v;
}
map.insert(key.clone(), V::default());
map.get_mut(&key).unwrap()
}The current NLL borrow checker rejects the version that returns early without the extra lookup, because it cannot see that the borrow in the if let arm does not escape. Polonius can. The catch has always been performance, the original implementation was orders of magnitude slower than NLL on real code. The 2025H2 work has been about a from-scratch implementation that fits inside the existing query system, and the goal page mentions it is now on a path where nightly stabilization is the realistic next step rather than a research project.
In-place initialization is the other piece that benefits the kernel folks directly. Linux drivers cannot rely on the move-by-default semantics that Rust assumes, because pinned data structures inside the kernel literally must not move. Library solutions exist (pinned-init is the canonical one), but a language feature that lets you write let x in place = T::new(...) removes a class of macros and unlocks more idiomatic kernel code. This is also why “Getting Rust for Linux into stable Rust” appears as its own goal, the kernel has been the forcing function on a half-dozen features that benefit everyone.
Higher-level Rust and cargo-script
The other flagship I want to flag is the cargo-script work. The goal here is that cargo learns to run a single .rs file with inline dependency declarations, which removes the friction of “I need a 30-line script that uses serde”. RFC 3502 laid out the syntax, and the 2025H2 cycle was about pushing it through stabilization. Combined with the ergonomic ref-counting RFC, the message is that Rust is taking the “high-level scripting” use case seriously instead of treating it as someone else’s problem. Whether that succeeds against Python’s incumbency is a different question, but it removes Rust’s excuse for not even trying.
What I take away from a 41-goal cycle
The goal program itself, started in 2024, is the meta-story. Rust’s governance had a reputation for things stalling between an accepted RFC and an actual implementation. Pinning down 41 owners with quarterly check-ins is a process answer to that organizational problem, and the wrap-up post is the receipt. Some goals slipped, the post is honest about which ones, and most carry forward into 2026.
For a user, the practical read is that 2026 should bring a measurably faster compiler, a borrow checker that accepts more correct code, and the first wave of features that make Pin and UnsafeCell feel like ordinary types instead of escape hatches. None of those will get a marketing push the way async/await did in 2019, but the cumulative effect on what it feels like to write Rust will be larger than any single edition release.