Rust All Hands 2026 Retrospective
blog.rust-lang.org
blog.rust-lang.org
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.
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.
There is also a Cuda-Tile rust lib which I have been meaning to try, but I haven't used tiles so far.
cuda-tile is great...I would use it for anything written from scratch as it is closer to how the hardware (and projects like triton) work. But there are tradeoffs as it requries your code to be structured a certain way.
Aren’t they the main selling points of Rust? Why use Rust over another language if you’re not using its main features?
I don't see rust and think "I have to write using Safe abstractions, traits etc because they're the rust way". There are many reasons to choose (or not depending on your preferences) rust beyond that. For example: "I am choosing rust here because Python's slow and its module system is a mess" or, "I'm choosing Rust here because its enum and struct syntax is fantastic" or "I'm choosing rust here because I can install the toolchain with a single command, and compile + flash with another without getting frustrated". Or "I'm choosing rust here because it makes it easy to architect complicated programs, and has really nice copmile-time error messages".
Stated another way: > Why use Rust over another language if you’re not using its main features?
It depends on the use case and what language you're comparing it to.
However, that does not mean that every single piece of code must be 100% safe. An embedded developer today is already constantly juggling with safety. Especially when it comes to low-level hardware interaction, I'd rather have a raw unsafe API today than wait several years for an inevitably-flawed safe abstraction.
I don't need Rust to track the ownership of an I2C peripheral. It's a nice-to-have, but it is easy enough to do by yourself - there aren't that many of them and interactions are rather obvious. I'm already used to the possibility of mishandling some pins resulting in the board catching fire, I promise I can handle this.
On the other hand, I really do want Rust to keep track of what's going on in all my business logic, for all the same reasons you want memory safety on a regular computer. Is my 10k-line protocol handler safe? Sure would love a double-check on that!
So no, I'm not really all that interested in the fancy clever abstractions. Making sure the KISS ones are rock solid is far more important to me.
The rust embedded ecosystem seems to have way too much focus on ownership and safe handling of peripherals. Exactly as you say there's not many of them, you're limited to what's in the hardware. These are not things that you are dynamically spinning up and tearing down dozens of instances all the time but the HALs I've seen all treat them that way. The result is a lot of abstraction that creates a ton of needless boilerplate.
I would rather these things just get out of the way and let me focus on building abstraction in the business logic where it's needed.
Co-signed.
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.
You also don't share what LLM you use, some of them reason a lot, some of them nothing, some a bit. Again, personally I use LLMs with their maximum reasoning always, trading quality for speed/waiting every single time, and even compiling the Linux kernel would be faster than most LLM responses I get nowadays, for me, on a workstation.
because of the type system? i work in ~dynamically typed language and the llms almost never make a type error.
It's hard to come up with anything where I think Rust isn't "best in class" other than compile times.
(On my local machine, `cargo check` is roughly 2x faster than `cargo build`. It's still slower than hot-reloaded Python, but it's rarely my development bottleneck.)
Anyways, if the code compiles, but the behavior is wrong, a test might be useful. But so is reading the code… so I’m skeptical of rerunning tests constantly.
Like, devs actually pay for having hot reloading.
IME it's just not really that big of a deal at this point. YMMV, etc.
Which is why then they go back other languages,
You'll love Clojure, gets you even closer; you can make changes while your program is running, by changing source code then applying just that function you changed, while your editor is connected to your program and can show what the new results are.
It feels almost criminal that it works, but it's quite nice.
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.
This entirely depends on (a) what a step/prompt/turn is trying to do and (b) tooling and rate limiting and various other aspects of your model and/or access to it.
If you have high rate limits and aren't using an Opus-or-larger sized model you can get a LOT of changes done in 10 seconds.
And this is especially true for "oh not all the tests are passing yet, let me change..." iterations where the change attempts are often low-single-digit seconds.
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.
Really, if you're using a SaaSS LLM like Claude or Copilot or ChatGPT, which already sends all your code to someone else's computer to run on a beefy GPU, they should just send the Rust code to the same datacenter and send you back a binary.
Little shocked that Anthropic isn't offering this.
Rust compile speeds will matter less and less as hardware gets faster.
> On Thursday, Friday and Saturday, at the All-Hands and Unconf, we expect all attendees to test themselves in the morning.
I thought Covid is long gone. What did I miss?
[0] https://2026.rustweek.org/covid-policy-all-hands-and-unconf/
It is no longer a pandemic which is killing tens of thousands of people, but covid is very much still around, and there's no true long-term vaccine for it. A lot of people with it are going to be more-or-less asymptomatic.
However, for a small bunch of immunocompromised people it is still very much life-altering or even deadly. For them catching it is just Not An Option, so if you want them at a large-scale meetup like this you'll have to ask all attendants to make the offer of spending a few seconds taking the $2 test.
Anonymous moderators? That's scary.