83 - NVIDIA Brings Rust to the GPU Kernel.
This edition is about who decides where your work runs. NVIDIA now lets you write the GPU kernel in Rust, a first set of principles for fast Tokio applications explains why your scheduler, not your code, is often the thing to measure, and Veloren's core developers show what an ECS buys you once 500 players are connected at once. The Rust project also has a security warning worth two minutes of your time.
Featured sponsor
|
NVIDIA Brings Rust to the GPU Kernel
Rust is creeping into NVIDIA's stack for a while now, e.g. the Nova Linux driver, a Rust core inside NVIDIA Dynamo, Rust bindings for NVTX. The kernel itself was the missing link in that story, since you could launch one from Rust but had to write it in something else. On 8 September NVIDIA closed the gap with CUDA Rust, compiling kernels written in Rust natively to PTX.
There are two tracks, mirroring CUDA's own. cuda-oxide is a custom rustc codegen backend for the familiar SIMT model, where you say what one thread does and launch thousands. cutile-rs takes the newer Tile model, where you describe what one tile of data does and the compiler decides how tiles map onto each architecture. NVIDIA's advice is to reach for Tile first and drop to SIMT when you need the control.
The maturity gap is the practical detail. cutile-rs runs on stable Rust 1.89 and above with CUDA 13.3, needs no custom LLVM, and is already used inside HuggingFace's Grout inference engine and mistral.rs. cuda-oxide needs a pinned nightly toolchain plus LLVM and is still early alpha.
Takeaways:
- GPU kernels in Rust, compiled to PTX, not a wrapper around code written elsewhere
- Both tracks enforce memory safety at compile time, through DisjointSlice and launch contracts or through tensor partitioning and ownership
- cutile-rs is the one to try today: stable Rust, already in production inference engines
- NVIDIA plans interoperability with CUDA C++ and CUDA Python, so choosing Rust should not lock you out
The First Real Principles for Fast Tokio Applications
Async performance advice usually arrives as folklore. Russell, who works on the dial9 tracing tool, has started writing it down instead, in principles for fast Tokio applications, drawn from a debugging and benchmarking discussion at the RustConf Unconf and his own production experience.
The honest framing, there are few hard rules, because a workload's performance depends on what else is running on the runtime at that moment, which is why these problems surface only in production. His first principle is to check whether you have a problem at all: go looking for red flags and you will find them, since almost every real application has polls far longer than the 10 to 100 microseconds Alice Ryhl recommends, and plenty of them are benign. Work backward from a metric you care about.
From there it is trade-offs rather than rules. Split for latency, batch for throughput. Yield more often when latency matters. Beware global resources, be careful with mutexes, constrain parallelism, isolate Tokio workers from other threads. Then the exceptions, for when you know better: blocking the executor can be fine, multiple runtimes can isolate workloads by priority, and spinning can be worth it to keep control.
Takeaways:
- Schedule latency, the gap between a task being ready and Tokio polling it, is the most useful single metric, and it now has a histogram
- Most async performance problems live in application code and in how components interact, not in Tokio
- It is a living document, so send a PR if your production experience differs
What an ECS Actually Buys You, Measured in Players
Veloren is an open-world multiplayer game in Rust, and a core developer has written up the unusual choices behind it. The headline one, taken in 2018 when it was still rare outside demos, was to build on an ECS (Entity Component System) rather than a class hierarchy.
The payoff is a number worth quoting: the server hits 50 percent core utilisation on a 48 thread machine with over 500 players connected and tens of thousands of entities interacting. Most MMOs reach those figures only by cutting cross-entity interaction or sharding players into separate world spaces.
The quirks are just as instructive. With an ECS, polymorphism is the default and an entity taxonomy is something you opt into, which produces bugs a class hierarchy would have made impossible. A botched loot transition once gave players an ItemDrop component, so nearby players could pick each other up, which dropped the target's entity and kicked them off the server.
The second choice is stricter than most games manage: players and NPCs (Non-Player Characters) are the same thing. Both go through one Controller component, a virtual gamepad fed by keyboard and mouse for players and by the agent decision tree for NPCs. NPCs cannot teleport or phase through blocks, and an agent that ignores momentum will walk its NPC off a cliff.
Takeaways:
- An ECS is what lets one server hold 500 players and tens of thousands of interacting entities without sharding
- Default polymorphism is the cost: entity taxonomy is opt-in, and the bugs that follow are strange ones
- Running NPCs through the same physics and control path as players makes bad agent code visible immediately
A Pokedex in the Terminal, and the Async Underneath It
Not everything worth reading is infrastructure. rotomdex is a Pokedex TUI, and its author describes it as their first substantial programming project. It renders an overview, an evolution tree, abilities and movesets for every version of the mainline games, inside an 80 by 24 terminal, with animated sprites drawn in the terminal itself.
What makes it relevant here is what sits underneath: assets fetched asynchronously and on demand, hot swappable versions, and a working offline mode. That is the same concurrency machinery the rest of this edition is about, doing unglamorous work in a small program, which is where most developers meet it first.
There is a web demo if you want to try it without installing anything, and the source is on GitHub.
Takeaways:
- Demand-driven async fetching with a real offline mode is a proper design
- Terminal UIs remain one of the friendliest on-ramps to Rust: small scope, fast feedback, no web stack to fight
- A first project shipping a web demo and install instructions beats plenty of mature crates on developer experience
Snippets
Be alert: targeted attacks on prominent Rustaceans The Rust project warns of a campaign targeting rust-lang members and popular crate owners, using video calls set up under a pretext to get the target to run something. The arrayref crate fell to it last month. Check your MFA and logins.
A visual guide to Rust async Sixteen steps tracing one tiny program down to the state machine the compiler builds: why an async fn becomes an enum with one variant per pause point, and why the thread does nothing at all while the future waits.
Rust debugging survey 2026 results The compiler team's first debugging survey, with over 2,300 responses: fewer than half of respondents use a debugger with Rust at all. Read it next to the Tokio piece above, on measuring rather than guessing.
Why building a Rust LSP is hard Rust Glancer's author on rust-analyzer's architecture and their own server. An LSP has to answer from partial information, which is what turns the easy-looking parts hard.
We are thrilled to have you as part of our growing community of Rust enthusiasts! If you found value in this newsletter, don't keep it to yourself — share it with your network and let's grow the Rust community together.
👉 Take Action Now:
Share: Forward this email to share this newsletter with your colleagues and friends.
Engage: Have thoughts or questions? Reply to this email.
Subscribe: Not a subscriber yet? Click here to never miss an update from Rust Trends.
Cheers,
Bob Peters
Want to sponsor Rust Trends? We reach thousands of Rust developers biweekly. Get in touch!