CUDA Rust closes the gap between Rust and the GPU kernel

Rust has been moving deeper into the systems layer of AI, but GPU kernels have remained an awkward boundary.

NVIDIA is now trying to remove that boundary.

On September 8, the company introduced CUDA Rust as two native paths for writing GPU kernels in Rust. The key word is native: the kernel itself can be written in Rust and compiled into PTX instead of using Rust only as host code around a kernel written somewhere else.

NVIDIA is starting with two programming models. `cuda-oxide` follows the familiar SIMT style used by CUDA C++, where the programmer thinks in threads and blocks. `cutile-rs` works at a higher level, where the programmer describes operations over tiles of data and the compiler decides how those tiles map onto the GPU.

Both end up inside the CUDA ecosystem. They simply give Rust developers two different levels of control.

cuda-oxide brings Rust into the SIMT model

The lower-level track is `cuda-oxide`, a custom Rust compiler backend from NVIDIA’s NVLabs.

A function marked as a GPU kernel moves through Rust MIR, NVIDIA’s Rust-based Pliron IR framework, LLVM IR, and finally into PTX. The rest of the program can continue through the standard Rust backend.

That gives developers a programming model that feels close to CUDA C++: define what one thread does, choose the launch geometry, and let thousands of threads execute the same kernel across the data.

NVIDIA’s example is a vector-add kernel over 1,024 floating-point values. The device code is written in Rust, compiled to PTX, launched through a Rust host API, and checked against the expected output.

The interesting part is that the function signature is doing real safety work before the kernel ever reaches the GPU.

Rust’s ownership model reaches into kernel safety

GPU code has always had to care about aliasing, indexing, and which thread is allowed to write to which part of memory.

CUDA Rust turns some of those rules into types.

In the `cuda-oxide` example, shared input slices are ordinary Rust references. The writable output uses `DisjointSlice`, a type that gives each thread exclusive access to its own element instead of pretending every thread owns the same mutable slice.

Thread indexing is typed as well. The kernel receives an index value designed for the launch domain, and an out-of-bounds access comes back as an `Option` that the program has to handle.

Launch geometry also becomes part of the contract. A `#[launch_contract]` declaration describes how the kernel is expected to be launched, and the generated host-side API checks the requested launch configuration before exposing the safe path.

That is a very Rust-like way to approach GPU programming: move assumptions out of comments and into things the compiler and runtime can validate.

cutile-rs takes the tile route instead

The second track, `cutile-rs`, starts from a different abstraction.

Instead of writing what one GPU thread should do, the kernel operates on a tile — a chunk of a tensor. CUDA Tile IR then decides how that work maps onto the actual GPU threads and memory layout.

The Rust code stays compact because the programmer does not manually manage thread indexing for the tile.

NVIDIA’s example performs the same elementwise addition as the SIMT version, but the inputs and outputs are expressed as tensors. The output is partitioned into non-overlapping writable chunks, and each tile receives one exclusive region.

The compiler owns the mapping from that logical tile to the hardware.

NVIDIA recommends reaching for the Tile path first when that abstraction fits the workload, then dropping to SIMT when an application needs direct control over threads, memory, or architecture-specific behavior.

Stable Rust can now reach CUDA Tile IR

One of the cleanest parts of the Tile path is the toolchain.

`cutile-rs` works with stable Rust 1.89 or newer and JIT-compiles kernels through CUDA Tile IR when they are first needed. The kernel’s abstract syntax tree is embedded in the host binary, then compiled for the GPU at runtime.

For developers already living in Cargo and crates.io, that gives CUDA programming a much more familiar entry point.

The library is published as a Rust crate, and NVIDIA’s examples can be built with standard Cargo commands. The current toolchain targets NVIDIA GPUs with compute capability 8.0 or later and uses modern CUDA Tile IR support.

That means a Rust project can keep its host code, kernel code, package management, and ownership model inside one language ecosystem while still producing code for NVIDIA GPUs.

The Tile and SIMT paths can work in the same pipeline

The two tracks are not meant to live in separate worlds.

NVIDIA has already published an interoperability example where a `cutile-rs` Tile kernel performs a row-wise softmax and a `cuda-oxide` SIMT kernel applies a custom threshold-and-scale step afterward.

Both kernels run in one host process, on the same CUDA stream, over shared device allocations.

The Tile stage handles the tensor-shaped operation. The SIMT stage handles a thread-oriented post-processing step where direct control is useful.

That is a strong example of why NVIDIA is treating the programming model and the programming language as separate choices. A Rust application can use the high-level Tile model where the compiler can take over more of the mapping, then use SIMT where the kernel needs a lower-level shape.

The result is one Rust GPU pipeline rather than a forced choice between two isolated toolchains.

NVIDIA is building CUDA Rust into the wider CUDA ecosystem

NVIDIA says this is part of a longer CUDA Rust push extending into 2027 and beyond.

The company also plans interoperability across CUDA Rust, CUDA C++, and CUDA Python so choosing Rust at one layer does not isolate a project from the rest of the CUDA stack.

That direction fits what is already happening elsewhere in NVIDIA’s software.

The Nova Linux driver is written in Rust. NVIDIA Dynamo uses a Rust core. NVTX has Rust bindings. Rust has become increasingly common in the infrastructure around AI systems because it combines systems-level control with compile-time memory guarantees.

CUDA Rust brings that same language closer to the place where the parallel compute actually runs.

For developers building inference engines, runtimes, compilers, or performance-sensitive AI infrastructure, that closes a meaningful gap in the stack.

The Upgrade Feeling

The headline is not that Rust can call CUDA. Rust could already sit on the host side of GPU applications.

The change is that Rust can now own the kernel too.

`cuda-oxide` gives developers a native SIMT path to PTX. `cutile-rs` gives them a stable-Rust path into CUDA Tile IR. Ownership and type design are being used to make launch geometry, writable memory, and tensor partitioning more explicit before the program reaches the GPU.

That is a much bigger shift than another language binding.

NVIDIA is trying to make Rust a first-class way to express GPU work — from the system around the model all the way down to the kernel that runs on the accelerator.

Can Rust Replace C/C++ in Safety-Critical Embedded Systems? Sonair Just Put It Through Certification

A programming language can look ready for embedded systems long before a certification process agrees.

Sonair has now pushed that question into a real product.

On August 31, 2026, the Norwegian robotics company published a detailed engineering account of how it built the safety functions inside ADAR One in Rust and took the complete sensor through functional-safety certification. Sonair describes ADAR One as the first safety-certified embedded system built in Rust.

That wording matters.

Rust itself was not suddenly certified as a complete language for every safety-critical application. ADAR One was assessed as a complete system. Its safety functions are written in Rust, those functions are compiled with the qualified Ferrocene toolchain, and the surrounding hardware and software architecture was built around the same certification process.

So the interesting question is not whether Rust has already replaced C or C++.

It is whether a Rust-based embedded stack can now make the full trip from source code to deterministic hardware, qualified tooling, controlled dependencies and an independently assessed safety system.

Sonair just gave us a real case to study.

Start With the Sensor, Not the Language

ADAR One is a 3D ultrasonic sensor for robots and industrial machine-safety applications.

ADAR stands for acoustic detection and ranging. The sensor sends ultrasound into the space around a machine, records the returning echoes across multiple transducers and processes those measurements into 3D spatial information.

If a person or object enters a configured protective zone, the sensor can provide the safety signal used by the wider control system to slow or stop machinery.

Sonair lists a 180-degree by 180-degree field of view and a sensing range of up to four meters for the current product. The company also says ADAR One is rated SIL 2 and PL d and was assessed as a human-protection sensor against IEC 61496, alongside IEC 61508 and ISO 13849 requirements.

This is useful context because the software is not sitting behind a dashboard or waiting for a user to click something.

It is inside a sensor that has to measure the physical world, process the result within a known time budget and produce predictable behavior.

That is the environment Rust had to enter.

The First Constraint Comes From Physics

Before certification enters the picture, ADAR already has a timing problem set by the speed of sound.

Sonair uses a five-meter example in its engineering write-up. A sound pulse traveling to an object five meters away and returning takes about 29.4 milliseconds under the conditions used in the company’s calculation.

The robot still needs time to act on what the sensor finds.

Sonair says its target is to know about an obstacle within roughly 100 milliseconds, leaving only part of that window for signal processing after the acoustic travel time is accounted for.

This is where the architecture becomes more interesting than a language comparison.

The firmware cannot simply collect a large recording, wait, and then begin all computation. Sonair says it starts processing as soon as the first samples arrive through DMA. In its implementation, that moved the effective start of processing from roughly 30 milliseconds to around 3 milliseconds.

The result is more computation time without changing the physics.

Rust is operating inside that timing strategy, not outside it.

DMA Turns Waiting Time Into Processing Time

DMA is doing more than moving bytes here.

It changes when useful work can begin.

Instead of treating data acquisition and signal processing as two completely separate blocks, Sonair overlaps them. Samples start arriving. Processing starts early. The rest of the recording continues while computation is already underway.

That is a practical embedded-systems move because the useful resource is not only CPU performance. It is the time between the physical event and the final safety decision.

Sonair says this approach leaves a much larger computation window for its signal-processing pipeline.

There is also a broader point.

A language can provide compile-time checks, ownership rules and a strong type system, but none of those remove real-time engineering. The firmware still needs a scheduling model, memory layout, hardware interfaces and timing behavior that fit the physical system.

ADAR One is a useful Rust example precisely because the language is being used inside those ordinary embedded constraints.

The interesting part is not that Rust avoided the hard engineering.

It had to participate in it.

Sonair Chose Rust Before Certification Was the Main Reason

Sonair says the team began with experienced C and C++ embedded developers.

That makes the language choice more useful to examine. This was not a team arriving from a completely different software world and selecting Rust by default.

According to Sonair, Rust was chosen early for the type system, compile-time guarantees, package tooling and the embedded ecosystem that was available around common microcontrollers.

The company has given a simple example: hardware APIs can encode states in types, so trying to use an input pin as an output can become a compile-time error instead of a runtime surprise.

That does not make C or C++ irrelevant. It explains what Sonair wanted from Rust.

The project later added a much harder requirement: functional-safety certification.

At that point, the question changed.

It was no longer only whether the team could write efficient firmware in Rust. The compiler, standard-library subset, dependencies, generated low-level code, hardware partitioning and verification evidence all had to fit the certification process.

That is the part that turns this from a language preference into an engineering case study.

Certification Changes What Counts as a Toolchain

Normal embedded development can treat the compiler as infrastructure.

Safety-critical development has to account for it much more explicitly.

Sonair builds the safety-related Rust code with Ferrocene, Ferrous Systems’ qualified Rust toolchain. Ferrous Systems says Ferrocene is qualified for IEC 61508 and ISO 26262 use, and its 25.11 release added an IEC 61508 SIL 2 certified subset of Rust’s core library.

That second part matters because a compiler alone is not enough.

Embedded Rust code still depends on basic language and library functionality: integers, arithmetic, arrays, slices and other pieces exposed through `core` in `no_std` environments.

Sonair says it worked with Ferrous Systems to identify the subset required by its firmware and test its code against the certified surface.

The model is intentionally narrow. If a function is outside the certified subset, the safety build should not quietly treat it as approved.

That creates a very different relationship with the toolchain.

The compiler and core library are not just how the binary gets produced.

They become part of the evidence behind the binary.

Ferrocene Is the Bridge Between Rust and the Safety Process

Rust’s memory-safety model gets most of the attention, but Sonair’s certification story depends heavily on qualified tooling.

Ferrous Systems first announced formal qualification of Ferrocene for ISO 26262 and IEC 61508 in 2023. The toolchain has continued to evolve since then, including the certified `core` subset released with Ferrocene 25.11.

That gives projects a documented compiler path instead of asking each team to solve the compiler-suitability problem from the beginning.

It also shows why the question in the title needs a careful answer.

Replacing one language with another in a safety-critical product is not a source-code substitution.

The surrounding assurance stack has to move too.

Compiler qualification, library coverage, requirements, tests, architecture and traceability all sit around the application code.

Sonair’s work is interesting because those layers finally meet in a shipping embedded product.

Rust provides the language model. Ferrocene provides a qualified toolchain path. Sonair still has to prove the behavior and structure of its own system.

No single layer replaces the others.

The Hardware Had to Be Fast Enough Before Anything Else Mattered

Sonair did not begin and end with one processor choice.

Its current architecture uses a Texas Instruments Sitara AM62x family platform with four Cortex-A53 application cores plus isolated microcontroller-class cores.

The reason is straightforward: the signal-processing workload needs enough compute to finish inside the timing budget.

Once the team moved to that platform, another problem appeared. The Rust ecosystem around the chip was not the same as the ecosystem Sonair had used on other microcontrollers.

Sonair says it did not have the peripheral-access crate or SVD support it needed for this target. TI did provide XML register descriptions, so the team wrote a conversion tool called `tixml2svd`, generated an SVD representation, and then used `svd2rust` to generate low-level peripheral-access code.

That is a very embedded kind of problem.

The language can be ready while a specific chip ecosystem is still uneven.

Sonair solved the gap by generating the interface layer it needed rather than changing the overall architecture.

Bare Metal Kept the Safety Boundary Under the Team's Control

The four A53 cores run the safety functions without a conventional operating system in that domain.

Sonair evaluated operating-system paths during development, then chose a bare-metal design for the safety-relevant A53 workload.

The important point is not that one operating system is universally better or worse for safety work.

Certification depends on the complete system, the evidence available for each component and the boundaries a project chooses to own.

For Sonair, bare metal kept the scheduling model and the safety-relevant software surface inside an architecture the team could document directly.

That choice came with work.

The team had to build its own multicore scheduling approach instead of relying on a general-purpose scheduler.

But it also made the execution model very explicit.

Data acquisition happens. Analysis is divided across cores. Results converge into a conclusion.

There are fewer hidden layers between the application logic and the hardware timing that has to be demonstrated.

In a certification project, that visibility can be as important as convenience.

Four A53 Cores Share the Analysis Without Locks

Sonair divides its processing pipeline into recording and pre-processing, analysis, and conclusion.

The analysis phase is the compute-heavy part, so work is distributed across the extra A53 cores.

Core 0 coordinates acquisition and makes work available. The other cores claim pieces of that work and process them in parallel.

Sonair says the scheduler uses atomics rather than blocking locks or mutexes. Counters track which data is ready, which work has been claimed and which pieces are complete.

The exact implementation matters less than the reason behind it.

The team wanted predictable worst-case timing.

A safety function has to be understandable not only when the machine is lightly loaded, but when the system is operating at the edge of its expected conditions.

This is where Rust’s concurrency primitives meet ordinary real-time design.

The language can help express ownership and atomic operations clearly. The architecture still has to define who produces data, who consumes it, when work finishes and how the final result is reached.

Determinism is built from both sides.

The Safety Boundary Extends Into the Chip

ADAR One is not a single-core Rust program sitting alone on a microcontroller.

Sonair partitions responsibilities across the compute platform.

The company says the safety functions run on the four A53 cores in Rust. An integrity function runs on an isolated M4 core, also in Rust. Non-safety workloads run on an R5 core using FreeRTOS and C based on TI reference code.

That detail is important for the C/C++ question.

This product is not evidence that every existing language disappears when Rust enters a safety system. It is evidence that different software domains can coexist inside one product with clearly defined responsibilities.

Sonair also uses memory-management and protection hardware plus a device firewall to separate those domains.

So the safety boundary is not created by the programming language alone.

It is reinforced by the processor architecture, memory protection, device access rules and the way workloads are assigned to cores.

That is probably the most useful lesson in the entire system.

Software safety is an architecture, not a syntax feature.

Third-Party Crates Become an Evidence Problem

Cargo makes adding a Rust dependency easy.

Certification makes the question behind that dependency much larger.

Sonair says safety-relevant third-party code has to meet the process expectations applied to the rest of the system: requirements, design information, architecture and test evidence.

That changes how a team looks at an otherwise useful crate.

The issue is not whether open-source code is good or bad. The issue is whether the project can produce the evidence required for the safety case around the exact code that executes.

Sonair therefore limits dependencies in safety-relevant paths and has modified some dependencies so they can fit its process.

This may become one of the more important areas for safety-critical Rust over time.

A language ecosystem becomes easier to use in certified products when reusable libraries arrive with stronger assurance artifacts, not only source code.

Ferrocene solved a large part of the compiler problem.

The next layer is making more of the library ecosystem practical inside the same evidence model.

The FFT Example Shows Why Performance Claims Need Context

Sonair also gives a useful example from its signal-processing code.

The team initially considered using Arm’s CMSIS-DSP implementation through an FFI boundary for some math-heavy work. During development, it tested the Rust `rustfft` crate on its own workload and target hardware.

Sonair reports that `rustfft` was faster for that particular use case.

The company explicitly says this is not a universal benchmark result.

That qualification is the interesting part.

Embedded performance depends on the algorithm, data shape, compiler, target architecture, memory behavior and surrounding implementation. One result on one device does not turn into a general language ranking.

For ADAR One, the practical benefit was simpler: the team could keep that FFT path in Rust and avoid an FFI boundary inside the safety function.

That is a better way to read the result.

Not Rust versus C.

One measured implementation decision inside one certified system.

What Was Actually Certified?

This is the section that keeps the headline honest.

According to Sonair, ADAR One was assessed and type-approved as a complete system. The company says it is rated SIL 2 and PL d, was assessed as a human-protection sensor against IEC 61496, and meets IEC 61508 and ISO 13849 requirements relevant to the product.

Sonair also says exida issued the EC type-examination certificate under the European Machinery Directive framework used for the assessment.

The certification is not a declaration that every Rust program is safety-certified.

It is not a blanket certification of every crate in the Rust ecosystem.

And it does not mean another company can copy the language choice and inherit Sonair’s certification.

The certified object is the engineered system and the evidence around it.

Rust is a significant part of that system because the safety functions are written in it and compiled through Ferrocene.

That is already a meaningful milestone without stretching the claim any further.

So Can Rust Replace C/C++ in Safety-Critical Embedded Systems?

Sonair’s answer is more useful than a simple yes or no.

ADAR One shows that Rust can now sit inside a real safety-critical embedded product, run deterministic real-time workloads, use qualified compiler infrastructure and survive the much larger documentation and verification process around functional safety.

That removes one old uncertainty.

Rust is no longer only a language that looks promising for this class of work. There is now a shipping case where safety functions written in Rust are part of an independently assessed system.

But replacement is a much bigger word.

C and C++ already exist across enormous embedded codebases, certified platforms, vendor SDKs, toolchains and engineering teams. ADAR One itself still uses C and FreeRTOS in its non-safety R5 domain.

The more accurate change is that teams now have another credible architecture available.

They can evaluate Rust for safety-relevant embedded work without treating certification as a purely theoretical future problem.

That is different from saying every existing stack should move.

The Real Upgrade Is a Complete Rust Safety Path

The most important part of Sonair’s story is not one compiler feature.

It is the chain.

A Rust application runs on a multicore embedded platform. Samples arrive through DMA. Signal processing begins before acquisition is finished. Work is distributed across A53 cores with a deterministic scheduler. Safety and non-safety domains are separated in hardware. The Rust code is built with Ferrocene. The usable `core` surface is constrained to certified functionality. Dependencies are pulled into the same evidence process. Then the complete product goes through external assessment.

That is what changed.

Rust now has a documented route through a problem that used to end with a question mark: what happens when memory-safe systems programming meets actual functional-safety certification?

Sonair’s answer is not that the language does everything for you.

It is almost the opposite.

The language becomes one strong layer inside a much larger engineering system.

And now we know that system can reach production.