Rust All Hands 2026 Retrospective
blog.rust-lang.org
Rust All Hands 2026 Retrospective
1–10 of 63 posts
Re: Rust All Hands 2026 Retrospective
#2Re: Rust All Hands 2026 Retrospective
#3Re: Rust All Hands 2026 Retrospective
#4I could see Rust becoming the language for coding agents, because it has such solid guardrails built in. I could also see it slipping into obscurity as LLMs get faster and compile times become a more and more obvious bottleneck on iteration speeds.
I’ve worked on some very large Rust projects. The incremental compile times are nowhere near the same order of magnitude of a bottleneck as an LLM turn.
Re: Rust All Hands 2026 Retrospective
#5I could see Rust becoming the language for coding agents, because it has such solid guardrails built in. I could also see it slipping into obscurity as LLMs get faster and compile times become a more and more obvious bottleneck on iteration speeds.
> I could also see it slipping into obscurity as LLMs get faster and compile times become a more and more obvious bottleneck on iteration speeds. I’ve worked on some very large Rust projects. The incremental compile times are nowhere near the same order of magnitude of a bottleneck as an LLM turn.
Have you tried Cerebras, Groq, Taalas, et al? It was a paradigm shift for me.
Re: Rust All Hands 2026 Retrospective
#6Earlier quoted context omitted.
> I could also see it slipping into obscurity as LLMs get faster and compile times become a more and more obvious bottleneck on iteration speeds. I’ve worked on some very large Rust projects. The incremental compile times are nowhere near the same order of magnitude of a bottleneck as an LLM turn.
I don't doubt this is true for many projects currently (though it's not for a bevy project I'm working on). Have you tried Cerebras, Groq, Taalas, et al? It was a paradigm shift for me.
I was disagreeing with the concept that incremental compile times could be a bottleneck. LLMs are even better at doing large swaths of work at once and having it compile first or second try than a human.
Re: Rust All Hands 2026 Retrospective
#7Rust-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.
Re: Rust All Hands 2026 Retrospective
#8Earlier quoted context omitted.
I don't doubt this is true for many projects currently (though it's not for a bevy project I'm working on). Have you tried Cerebras, Groq, Taalas, et al? It was a paradigm shift for me.
I have, but even with the high token generation speed, incremental Rust compile times were not a bottleneck. I was disagreeing with the concept that incremental compile times could be a bottleneck. LLMs are even better at doing large swaths of work at once and having it compile first or second try than a human.
Re: Rust All Hands 2026 Retrospective
#9Earlier quoted context omitted.
I don't doubt this is true for many projects currently (though it's not for a bevy project I'm working on). Have you tried Cerebras, Groq, Taalas, et al? It was a paradigm shift for me.
I have, but even with the high token generation speed, incremental Rust compile times were not a bottleneck. I was disagreeing with the concept that incremental compile times could be a bottleneck. LLMs are even better at doing large swaths of work at once and having it compile first or second try than a human.
Re: Rust All Hands 2026 Retrospective
#10I could see Rust becoming the language for coding agents, because it has such solid guardrails built in. I could also see it slipping into obscurity as LLMs get faster and compile times become a more and more obvious bottleneck on iteration speeds.
> I could also see it slipping into obscurity as LLMs get faster and compile times become a more and more obvious bottleneck on iteration speeds. I’ve worked on some very large Rust projects. The incremental compile times are nowhere near the same order of magnitude of a bottleneck as an LLM turn.