CUDA Rust: two tracks, neither production-ready

What it does

Problem. Rust already shows up in NVIDIA's stack narrative (Nova driver, Dynamo core, NVTX bindings). Host-side launch from Rust was possible. The kernel body usually was not: you wrote C++/CUDA or another frontend and called in.

CUDA Rust claim. Write the kernel in Rust; compile natively toward GPU IR.

Two programming models, matching CUDA's own split:

1. SIMT (cuda-oxide). You write what one thread does. Launch geometry is explicit. Safety argument centers on DisjointSlice (per-thread exclusive mutable access) and #[launch_contract] checked against live device limits before a safe launch method runs. Host and device code can live in one file via #[cuda_module].
2. Tile (cutile-rs). You write what one tile of data does. The Tile IR compiler owns thread mapping and much of the memory layout. Host-side .partition([...]) creates exclusive sub-tensors for mutable outputs; ownership crosses the launch boundary. Kernels JIT through CUDA Tile IR on first need. Lazy host API until .sync_on(&stream).

Both demos in the blog are the same 1,024-float elementwise add. Both print PASSED when the environment is right.

Why now

• Systems AI (inference engines, serving, agent runtimes) keeps moving into Rust for compile-time bug classes without giving up performance.
• NVIDIA wants CUDA frontends to follow the languages operators already use, with planned inter-language interop so Rust is not a silo.
• Community Rust-GPU work (rust-cuda, Rust-GPU, CubeCL, cudarc) already existed. What is new, per NVIDIA, is first-party engineering weight and a stated 2027+ maturation path for CUDA Rust beside CUDA C++ and CUDA Python.
• Blog points to Melih Elibol's RustConf 2026 talk ("Fearless Concurrency on the GPU") and a paper of the same name.

Maturity (as of the 8 Sep 2026 primary)

	cuda-oxide (SIMT)	cutile-rs (Tile)
Stage	Early alpha	Further along; still early
Toolchain	Pinned nightly (nightly-2026-04-03 in the blog install line)	Stable Rust 1.89+
CUDA	12.x+; own LLVM/clang path	13.3; no custom LLVM
Distribution	Git install of cargo-oxide	crates.io cutile
External use cited	Not claimed as production	Hugging Face Grout; mistral.rs
GitHub heat (audit fetch)	~3.5k stars	~1.0k stars
NVIDIA line	Not production-ready	Not production-ready

APIs will move. Coverage is incomplete. That is NVIDIA's text, not a Frontier gloss.

Pick vs

Default (NVIDIA's own): Tile first when the algorithm fits tile thinking and you want stable Rust + crates.io ergonomics.

Choose cuda-oxide / SIMT when:

• you need explicit thread indexing, launch bounds, or SIMT-shaped ports from existing CUDA C++ kernels;
• you are willing to pin nightly and pay the first-build codegen cost;
• you accept that fast shared-memory paths still require unsafe today.

Choose cutile-rs / Tile when:

• you can express the work as tile loads/stores over tensors;
• you want ownership-checked launches without a custom rustc backend;
• you are already on CUDA 13.3 and stable Rust.

Stay on CUDA C++ / Python when:

• you need production maturity, full library coverage, or team fluency that Rust does not yet buy;
• you are shipping a kernel path that cannot absorb alpha API churn.

Language choice and model choice are separate axes. Interop is promised so picking Rust now should not block calling C++/Python CUDA later. Delivery date for that interop is UNKNOWN beyond "planned."

Failure modes

1. Toolchain gravity. cuda-oxide's pinned nightly + LLVM/clang requirements will break CI that expects stable only. cargo oxide doctor exists; it does not remove the pin.
2. False safety. Compile-time aliasing catches (E0502 / E0382 examples in the blog) are real. They do not make early-alpha codegen, Tile IR coverage holes, or unsafe shared memory disappear.
3. API churn. "Neither is production-ready" means pinning a git SHA and budgeting rewrites. crates.io presence for cutile is not a stability promise.
4. Model mismatch. Forcing a scalar SIMT algorithm into Tile (or the reverse) will cost more than staying in CUDA C++ for one more quarter.
5. Ecosystem split. Parallel community stacks (rust-cuda and others) still matter. NVIDIA maps them in the cuda-oxide book appendix; duplication and divergence risk remains until interop and coverage catch up.
6. Hardware floor. Both tracks want compute capability 8.0+ and Linux in the getting-started path. Older GPUs and non-Linux hosts are out of the blog's quickstart.

Operator read

Prototype on cutile-rs if you are Rust-native and Tile-shaped. Keep cuda-oxide on a spike branch if you are porting SIMT kernels and can absorb nightly. Do not rewrite a revenue kernel path onto either track until NVIDIA's own "not production-ready" line changes in a dated primary. File issues upstream; that is explicitly requested.