Nvidia published CUDA Rust on September 8, the opening day of RustConf 2026 in Montréal. It is two toolchains for writing GPU kernels in Rust, and both compile straight to PTX. The next day the Rust Foundation announced Nvidia as a Platinum member, the top tier, which costs $325,000 a year and comes with a board seat. The story sat for a week and then hit the top of Hacker News on September 17 with 944 points and 395 comments.

I write Rust when I can and I run GPUs when I have to. So I read the whole announcement, and the requirements section is the part that decides whether any of this ships.

Two tracks, two sets of requirements

The first track is cuda-oxide. It is a custom rustc codegen backend. Your kernel goes through Rust's MIR, then through an IR framework called Pliron, then LLVM, then out as PTX. This is the SIMT model, the one CUDA C++ programmers already know: you manage threads, blocks and shared memory yourself. Nvidia calls it "early alpha" and the docs tell you to "expect bugs, incomplete features, and API breakage."

The requirements for cuda-oxide:

  • Linux only
  • A pinned nightly toolchain, nightly-2026-04-03
  • CUDA 12.x or newer, plus clang with the libclang headers
  • A GPU with compute capability 8.0 or later

The second track is cutile-rs. Kernels are written against tiles instead of threads, and the CUDA Tile IR compiler decides the thread mapping and memory layout at runtime, JIT compiling the kernel the first time it's needed. Nvidia's line on it: "Tile gives you no shared memory or thread indexing to get wrong, because the compiler owns both."

The requirements for cutile-rs:

  • Linux only
  • Stable Rust 1.89 or newer, no nightly, no custom LLVM
  • CUDA 13.3
  • A GPU with compute capability 8.0 or later

cutile-rs is on crates.io under Apache 2.0, and Nvidia says it is already in use outside the company in Hugging Face's Grout inference engine and in mistral.rs. cuda-oxide is at version 0.1.0.

Both tracks reject aliasing at compile time. In the SIMT example, borrowing the same device buffer as both an input and an output fails with E0502, the standard "cannot borrow as mutable because it is also borrowed as immutable" error. In the Tile example, passing a tensor you have already handed off fails with E0382, use of moved value. Those are the same errors you get in host Rust. That's the point. A kernel that reads and writes the same buffer through two pointers doesn't crash. It produces wrong numbers, sometimes only at certain launch sizes, and you find out a week later when the output looks off. Turning that into a build error is the most useful thing in the whole announcement.

Compute capability 8.0 is Ampere. A100 and the RTX 30 series qualify. T4 is 7.5 and V100 is 7.0, so neither one does. There are a lot of T4s in cloud accounts running inference because they're cheap and the g4dn instances never went away. None of that hardware can run either track.

CUDA 13.3 for cutile-rs means a current driver on every host that JIT compiles a kernel. CUDA 13 already dropped Maxwell, Pascal and Volta when it shipped. If you maintain a mixed fleet with older driver branches pinned for some other reason, this is a fleet upgrade before it is a language choice.

Linux only is fine for servers. It rules out workstation development on Windows, which is where a fair share of CUDA developers sit.

The pinned nightly on cuda-oxide is the one I'd refuse to put in a build pipeline. A nightly from April 2026 means every upstream compiler change can break the backend, and Nvidia has to chase rustc internals to keep it building. Nvidia says as much. Until cuda-oxide is on stable, it's a research toolchain, and a research toolchain doesn't go in a Dockerfile that production depends on.

The community projects that got here first

Nvidia's blog credits the people who did this before them: rust-cuda, Rust-GPU and CubeCL. That credit is earned. The Rust CUDA project shipped its v0.3 in February 2022 and then went quiet for three years. Christian Legnitto and Jorge Ortega rebooted it in January 2025 under the Rust GPU organization, on volunteer time, and within a few months had merged more than 20 pull requests from new contributors. It is also a rustc codegen backend targeting PTX. Nvidia's own docs admit the two look alike, and draw the distinction as rust-cuda "bringing Rust to NVIDIA GPUs" (Rust ergonomics on the device, including the standard library) versus cuda-oxide "bringing CUDA into Rust" (the CUDA model expressed in safe Rust). Nvidia says it has been working with the rust-cuda maintainers.

I believe the collaboration is real. I've also watched enough vendors enter a space where volunteers had been working for years. The vendor's version gets the blog post, the conference keynote, the Platinum membership and the documentation with the Nvidia logo on it. The volunteer version keeps the ergonomics and loses the attention. Two backends targeting the same PTX from the same compiler is one too many, and I expect them to merge or one to fade by the end of 2027, whatever both sides say today.

One small thing. A crate named cuda-oxide already existed on crates.io before Nvidia picked the name. It was unmaintained, and a commenter on Nvidia's own forum pointed out the collision on September 16. A company paying $325,000 a year for a foundation seat could have checked the registry.

The lock-in argument, again

Most of the Hacker News thread was a fight about whether it's worth writing kernels against a proprietary target at all. One side: CUDA's compiler enforces correctness and its launch syntax is the best in the business, and every alternative (Vulkan's descriptor sets, WebGPU) is more verbose for the same work. The other side: a kernel written in Rust that compiles only to PTX is CUDA with a borrow checker, and Rust's pitch was portability.

Both are right. Rust in this announcement gets you memory safety on the device. It does not get you off Nvidia hardware. CubeCL, which compiles one kernel to CUDA, ROCm and WGPU, is the project that gets you off Nvidia hardware, and it does so by restricting what you can write. You can have safety on Nvidia hardware or portability with a smaller language. Nobody sells both with native performance, and Nvidia has no reason to build the version that does.

The split into two tracks is also the same split Nvidia made for Python. cuTile Python and the CUDA Tile IR shipped with CUDA 13.1 in December 2025. Tile is the model Nvidia wants new code written in, because the compiler owns the hardware details and Nvidia can change those details under you when the next architecture ships. The SIMT track exists for people who need to hand tune, and those people are still mostly writing C++.

What I'd do with it

If you have a Rust inference service today, keep the kernels where they are and keep calling them through cudarc. cudarc is Rust bindings to the CUDA driver API on the host, it's stable, and Nvidia's own docs list it as compatible with cuda-oxide's PTX output. That leaves you a path later without a rewrite now.

If you're starting something new and you own the hardware, cutile-rs is the one to prototype. Stable Rust, Apache 2.0, two outside projects already using it. The Tile model also removes the class of bug that costs the most time in kernel work, which is getting shared memory wrong.

Skip cuda-oxide until it builds on a stable toolchain. Nvidia says it will be "growing and maturing CUDA Rust into 2027 and beyond." I read that as cuda-oxide staying alpha through most of next year. My prediction: cutile-rs becomes the track that matters, cuda-oxide is folded into whatever comes out of the rust-cuda collaboration, and the Ampere floor stays where it is. Hardware floors at Nvidia only move up.