--- title: "All Hands 2026 retrospective" url: https://daily.dev/posts/all-hands-2026-retrospective-bfd4ut5ii source_url: https://blog.rust-lang.org/inside-rust/2026/07/31/all-hands-2026-retrospective type: article source: "Inside Rust Blog" published: 2026-07-31T07:24:08.679Z updated: 2026-08-03T00:36:40.333Z tags: ["open-source", "rust"] reading_time: 9 upvotes: 13 comments: 0 language: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # All Hands 2026 retrospective **[Inside Rust Blog](https://daily.dev/sources/insiderustblog)** · 9 min read · 13 upvotes · 0 comments ## Summary A retrospective of the Rust All Hands 2026 event held in Utrecht, Netherlands, where 166 Rust Project members gathered for three days of sessions, discussions, and collaboration. The event covered 73 sessions across topics including const generics, const traits, field projections, reborrowing, SIMD, allocators, Rust/C++ interoperability, Rust for Linux, Rust for CPython, and governance topics like the RFC process, Leadership Council, and project culture. Attendees rated the event 9.5/10. The next All Hands is confirmed for May 27–29, 2027, again in Utrecht as part of RustWeek 2027. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Community take How the wider developer community reacted, aggregated from 1 discussion and 77 comments across hackernews (as of 2026-08-03). **TL;DR:** The community is broadly enthusiastic about Rust's future, especially for agentic/LLM-assisted development, but has a lively debate about whether compile times are a real bottleneck and some frustration with the embedded and GPU working groups' API philosophies. **Sentiment:** 45% positive · 40% mixed · 15% skeptical **The case for** - Rust's strong type system and borrow checker provide fast, reliable feedback that benefits LLM-assisted coding workflows. - Incremental compile times are generally fast enough (especially on modern hardware) not to be a meaningful bottleneck compared to LLM turn latency. - Rust's overall tooling ecosystem (Cargo, property testing, fuzzing, static binaries, supply chain tools) is considered best-in-class. - The language's ergonomics, enum/struct syntax, and compile-time error messages make it a pleasant choice even beyond its safety guarantees. **The pushback** - Compile times are still a real degradation point for some developers using LLMs, particularly on less powerful machines or large projects like Bevy. - The embedded working group is criticized for prioritizing complex trait-heavy abstractions over practical, low-friction APIs. - Rust GPU ecosystem is fragmented and immature, with the embedded and GPU working groups seen as misaligned with practical project needs. - Hot-reload and interactive development workflows lag significantly behind alternatives like Python, Clojure, or even C++ Builder-era tooling. **By community** - hackernews (mixed): Commenters are genuinely enthusiastic about Rust but split on compile-time bottlenecks for agentic development and critical of some working group directions in embedded and GPU spaces. **Hottest debate:** Whether Rust's incremental compile times are a meaningful bottleneck for LLM-assisted development, or whether LLM turn latency dwarfs any compile overhead. **Open questions** - Will Rust's compiler speed improvements on the 2026 roadmap be sufficient to make it truly competitive for fast agentic iteration loops? - Can the Rust GPU ecosystem (rust-gpu, cuda-oxide, cubecl, etc.) consolidate around a common direction given fragmented efforts and low contributor counts? - Will the embedded working group shift toward lower-friction APIs, or will practical embedded Rust development continue to diverge from the official working group's approach? **Highlights** > The type system is great and gives extremely fast feedback. The performance wins are also incredible, it just feels like you're throwing 100s of megabytes of RAM away and 10x latency when you don't choose rust now, and for little reason. The testing tooling is really solid - property testing, fuzzing, mutation testing, etc, is all easy to use. Code structure with nice abstractions that don't become spaghetti is nice (traits, enums, etc). Static binaries as a production artifact is really nice. Supply chain story is pretty solid with cargo-vet. It's hard to come up with anything where I think Rust isn't "best in class" other than compile times. > — [insanitybit on hackernews](https://news.ycombinator.com/item?id=49149656) > Maintainer of rust-gpu and rust-cuda here. 1. Rust CUDA is over 5 years years old, was dead for 2(?) years, but was rebooted and works. It enables both rust on the GPU and controlling the GPU from the host. The host library (cust) predates cudarc. If it was started today it would just use cudarc for the host side (and indeed, you can use the device side with cudarc). Rust-cuda is based on nvvm, which was the supported layer in the past but Nvidia is moving away from. 2. Rust-gpu (vulkan) works but isn't 100% complete of course. The dimforge folks are using, there are some crypto folks using, and we have llms written in it. Rust-gpu is only the "running rust on GPU part", the host is left to wgpu or ash or whatever. The Nvidia projects are great (we gave pre-release feedback on them), but they were not announced when the call for presentations went out. They were also released as experimental with only 2 people working on them so Nvidia was cautious about marketing and over-committing. We are the only people trying to bring rust natively to the GPU rather than just making the GPU work with rust (which others like cubecl, wgpu, cuda-oxide handle well). This has some interesting considerations from a rust language and compiler standpoint, which is what was talked about at the conf. We sponsored an unconf room and got as many folks from all the various GPU projects together, including nvidia. The big problems right now are a) everybody has different needs, b) there are very few people working in the space c) the entire rust project is generally indifferent to GPUs. I expect this to change in the next year or two. > — [LegNeato on hackernews · 1 comments](https://news.ycombinator.com/item?id=49145595) > I use LLMs and rust and compile times are absolutely a significant area of degradation. I love rust, I think it's the best language for LLMs, but the biggest win Rust could get for agentic development is to speed up the compiler. > — [insanitybit on hackernews · 2 comments](https://news.ycombinator.com/item?id=49146308) > Devil's advocate from the description at the top of relevant groups speaking. The two in areas I'm familiar with are areas I'm excited about seeing rust take off in the future, and are already a great use of it. I don't think those groups are the ones that will (or should) do it. Rust-GPU: This is the org responsible for Rust CUDA, which was a historically non-working library I spent too much time trying to get working. Instead, Cudarc is a simple, "just-works" library with a responsive maintainer. For grpahics, WGPU and Vulkan bindings are good paths. To watch: Nvidia's official Cuda-Oxide, which uses Cudarc's style API for Host, and its own native Rust kernels. (Early/WIP stage on that). It is surprising to see "Rust GPU" there instead of WGPU, Nvidia/Cuda-Oxide, or Cudarc there, as it's the least viable of the set. Embedded is a fantastic area for Rust to excel in, and it's already excellent thanks to the general language tooling, Cargo, and the Knurling tools Probe-RS and defmt. I'm not sold on the embedded working group's history and style. E.g. Embedded HAL is a poor fit for practical firmware and integrations. ESP on Rust was great but turned into a mess 1 - 1.5 years ago due to mismanagement, and letting a new maintainer rewrite large chunks of the HAL. I'm comfortable using Rust on STM32 and nRF, and have built working aerobatic quadcopter firmware in Rust, but have never seen eye-to-eye with the working group. In general, they trend towards complicated APIs which focus on Traits, safe abstractions, Async etc. My pref: Use Rust as a nice overall language, and write low-friction APIs, vs the abstractions. I disconnected from the Embedded rust OSS scene; It's still my top choice for new hardware, and use it at work. It seemed like no one wanted to talk about projects and building things with rust; instead it was about using ownership, generics, safety, Async models etc to make clunky APIs. > — [the\_\_alchemist on hackernews · 3 comments](https://news.ycombinator.com/item?id=49145351) > Initial compilation and incremental compilation are very different. Large Rust projects are broken up into modules. If you change one module you don’t have recompile the whole project. Remember we’re talking about compensation time versus LLM turns in this thread. Even a 10 second incremental compile is orders of magnitude faster than an LLM turn. > — [Aurornis on hackernews · 1 comments](https://news.ycombinator.com/item?id=49146303) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=49143096) · 69 points · 77 comments ## Similar posts on daily.dev - [The next Rust All Hands](https://daily.dev/posts/the-next-rust-all-hands-wzu0sngqe) · Inside Rust Blog · 27 upvotes · 3 comments - [RustConf 2025 in Review: Rust for the Road Ahead](https://daily.dev/posts/rustconf-2025-in-review-rust-for-the-road-ahead-i31ihlbel) · Rust Foundation · 3 upvotes · 0 comments - [Rustikon 2026: Two Days, More Energy, and a Stronger Community](https://daily.dev/posts/rustikon-2026-two-days-more-energy-and-a-stronger-community-uvifwerxb) · SoftwareMill · 0 upvotes · 0 comments --- Tags: [#open-source](https://daily.dev/tags/open-source), [#rust](https://daily.dev/tags/rust) [View this post on daily.dev](https://daily.dev/posts/all-hands-2026-retrospective-bfd4ut5ii)