Nvidia lets you write CUDA kernels in Rust - but read the fine print first

Nvidia has published two ways to write GPU kernels directly in Rust rather than bolting Rust onto code written in something else. It’s a genuine gap being closed, not a rebrand — but the two routes on offer are at very different stages of readiness, and neither changes anything for people who just use software that happens to run on GPUs.

What’s actually being announced

Until now, Rust code could launch a CUDA kernel, but the kernel itself — the bit of code that actually runs on the GPU — generally had to be written in CUDA C++ or CUDA Python. Nvidia’s new blog post lays out two projects that close that gap.

The first, cuda-oxide, is a custom backend for the Rust compiler that turns SIMT-style kernels (the classic “one thread does this” CUDA model) into PTX code via LLVM and an intermediate representation called Pliron. It needs a pinned nightly build of the Rust compiler plus LLVM, and Nvidia itself describes it as early alpha.

The second, cutile-rs, targets the newer “Tile” programming model, where you describe what happens to a block of data and the compiler works out how to map that onto the hardware. It runs on stable Rust 1.89 or newer with CUDA 13.3, needs no custom LLVM build, and is already published on crates.io. According to Nvidia, it’s in use inside HuggingFace’s Grout inference engine and the mistral.rs project.

Both are pitched as enforcing memory safety at compile time — cuda-oxide via a mechanism called DisjointSlice and “launch contracts”, cutile-rs via ownership rules over data partitions — so that a class of GPU bugs (overlapping memory access, dangling pointers) gets caught before the code ever runs.

So who is actually affected

Essentially nobody outside people who write GPU kernels for a living. This is not a consumer feature, a driver update, or anything that changes performance or compatibility for existing CUDA software. It’s aimed squarely at the systems-programming layer underneath AI inference engines, serving stacks and driver code — the sort of place Nvidia notes Rust is already creeping in, citing its own Nova Linux driver and the Dynamo project as examples.

If you use an app or a game that happens to run on an Nvidia GPU, nothing here touches you directly. The people it matters to are the engineers building the inference and serving infrastructure that AI products sit on top of.

The catch

Nvidia’s framing — “CUDA Rust closes that gap” — is aspirational as much as descriptive. cuda-oxide, the track that mirrors the classic and most widely used CUDA programming style, is explicitly alpha software requiring a pinned nightly compiler, which is not a small ask for teams used to stable toolchains. Only cutile-rs, tied to the newer and less universally adopted Tile model, is stable and already shipping in real projects.

Reaction on Hacker News was mixed rather than glowing. The top-voted comment on the thread wasn’t really about Rust at all — it was a broader complaint about CUDA itself, arguing that tying kernel code to Nvidia’s proprietary stack creates lock-in regardless of which language wraps it, and suggesting that GPU-specific DSLs like Triton already do the ergonomics job better. That’s a fair caveat: writing kernels in Rust doesn’t loosen Nvidia’s grip on the ecosystem, it just changes the syntax you use inside it.

The takeaway

This is a real, checkable engineering move — two working (if unevenly mature) toolchains, one already used in production inference software. It’s a meaningful convenience for GPU-kernel authors chasing compile-time safety, not a shift that changes anything for ordinary users, and not, yet, an escape from Nvidia’s walled garden.