Rust & AI Weekly #12: who is paying for this
Welcome back to Rust & AI Weekly, the curated, vetted Rust newsletter on the crates and tools showing up where Rust meets AI. Today's issue: NVIDIA put its name and a 2027 roadmap behind CUDA Rust, GPU kernels written in Rust itself, and the paper I marked Assess in June is now a crate with two adopters, Rustls turned ten and explained how a TLS library ships 43 releases without breaking anyone, and Oracle's official pure-Rust database driver reached its third beta the same week Go Weekly celebrated Go's, and nobody in Rust noticed. The theme this week is who is paying for this: every entry below moved, up or down, for a reason that has nothing to do with code quality and everything to do with who is funding the maintainer and for how long. Last week I ended on Wasmi's funding cliff. This week the ecosystem handed me three examples of the opposite, and one small crate whose future depends on a decision its author does not get to make.
(Status lines reflect public signals as of September 14, 2026; stars and downloads are approximate and move fast.)
This week's radar: four new entries and one verdict upgrade, bringing it to 77 tools. Explore the interactive version.
The week's anchor
NVIDIA announced CUDA Rust on September 8, written by Sri Koundinyan, Melih Elibol and Jonathan Bentz. The first sentence of the post is the one that matters for anyone planning a roadmap: NVIDIA "will be growing and maturing CUDA Rust into 2027 and beyond." Not a research group's side project, not a labs demo, a platform commitment with a date attached, published on the same blog that announces CUDA toolkit releases.
The framing they chose is worth noting because it is unusually honest about where Rust sits. Rust already runs the Nova Linux driver, the core of NVIDIA Dynamo, and the NVTX bindings. The kernel was the exception: you could launch one from Rust, but you wrote it in something else. Two projects close that gap, one per CUDA programming model. The post ranks them for you: reach for Tile first, drop to SIMT when you need the control. Both catch the classic aliasing mistake at compile time. Passing a kernel's output buffer as one of its own inputs is error[E0502] on one track and error[E0382] on the other, and the post makes the point that Tile's version is the stronger claim because ownership follows the tensor across the launch boundary rather than being checked per call.
I want to be careful about what did and did not change this week. The code was public before. cutile has been on crates.io since March and Rust Bytes flagged cuda-oxide back in May. What changed is the steward stepped out from behind the repo and said, in the corporate voice, that CUDA Rust is a product direction. That is the difference between a thing you can try and a thing you can put in an ADR, and it is why the lead entry below moves.
Pick of the week
cuTile Rust 0.3.1 — an upgrade, and a verdict arc worth spelling out. In issue #2, in June, this was an arXiv paper called Fearless Concurrency on the GPU by Melih Elibol, Jared Roesch, Isaac Gelado, Eric Buehler and Michael Garland, with a repo attached and B200 benchmarks that looked too good to trust from a preprint. I put it at Assess with the note "watch this space, not yet a crate." Today it is cargo add cutile on stable Rust 1.89, version 0.3.1 (changelog dated September 2, on crates.io two days later, the ninth version since March), roughly 900 stars, and two named adopters outside NVIDIA: Hugging Face's Grout, a Qwen3 inference engine that runs its 25-kernel default path with zero unchecked kernels and reaches 171 tokens/s on an RTX 5090 for Qwen3-4B, and Eric Buehler's mistral.rs, which has been on this radar since issue #2 as well. The model is simple to state and hard to build: you partition a mutable output tensor into disjoint chunks on the host, that partition fixes the launch grid and hands each tile block exclusive ownership of one chunk, and the compiler proves there is nothing to race. Inputs are shared and read-only. The kernel body is Rust, captured as an AST by #[cutile::module] and JIT-compiled through CUDA Tile IR the first time it launches. 0.3.0 in August made the safety cheap: every partition access walks a proof ladder (axis provenance, static folding, declared preconditions, host-side launch checks) and only pays an in-kernel assert if nothing higher up discharged it, and the fully checked flash-attention prefill kernel lands within 2.5% of the unchecked floor. deny_in_kernel_checks = true turns any remaining check into a compile error, so an assert-free kernel becomes a build contract rather than an audit finding.
Now the part that keeps this at Trial rather than Adopt. 0.3.1 is a patch release that ships breaking changes, and the changelog says so in the second paragraph: a September audit found soundness holes, so load_module_from_bytes and the *_tko pointer ops became unsafe fn, DType became an unsafe trait, and the async allocation functions return Result instead of panicking. Kernel programs that used return below the function body or break inside for were being silently miscompiled and are now compile errors; integer division now rounds toward zero like Rust rather than toward negative infinity. Every one of those is the right fix. Every one of them also lands under a version number that tells caret-range dependents nothing happened, which is the same story as rmcp 1.8.0 last week with a better excuse. The 0.1.0 notes reserved breaking changes for exactly this case, correctness, so they kept their word; the lesson for you is that "we do not plan further breaking changes" and "pin exact" are compatible sentences. Go deeper with the paper itself, Fearless Concurrency on the GPU, which is the design rationale the blog post compresses, and if you want the SIMT side, the ecosystem appendix of the cuda-oxide book is NVIDIA's own map of where it sits relative to Rust-GPU, rust-cuda and CubeCL, written with the maintainers of those projects rather than about them.
Maintenance: actively developed (NVIDIA / NVlabs; Melih Elibol and team); five releases since May 16, 2026 · Latest: cutile 0.3.1 (Sep 2, 2026); CUDA Rust announced Sep 8 · Adoption: Trial, upgraded from Assess at #2; the cost is NVIDIA-only, CUDA 13.3, Linux and sm_80+, and the exit cost is a Rust DSL you cannot take to another vendor, softened by Tile IR being the same target the C++ and Python frontends compile to
GPU kernels in Rust
cuda-oxide — the other CUDA Rust track, entered separately because the verdict is different. This is a custom rustc codegen backend: #[kernel] functions go through Rust MIR, the community Pliron IR framework, LLVM IR and out as PTX, while everything else goes to the standard backend, so host and device live in one file and build with one cargo oxide build. The safety story is DisjointSlice<T>, which splits one &mut [T] into per-thread exclusive pieces, and #[launch_contract], which lets the generated prepare_vecadd validate your launch config against the kernel's declared geometry and hand back a token the safe launch method requires; kernels without a contract only expose unsafe launches, which is the correct default. About 3,000 stars and 827 commits, and NVIDIA calls it early alpha without hedging. The toolchain is the cost: a pinned nightly-2026-04-03, LLVM 21 or newer because it emits TMA and tcgen05 intrinsics older llc cannot handle, clang headers for bindgen, Linux only, and shared memory in SIMT still requires unsafe. The post says the nightly pin is "exactly the kind of thing we would like to stop asking you for," which is the right thing to say and also a roadmap item, not a release.
Maintenance: actively developed (NVIDIA / NVlabs); no tagged release, install from git · Latest: main as of Sep 2026, pinned nightly-2026-04-03 · Adoption: Assess; run the vecadd, read the gemm_sol_final example if you want to see what a Blackwell GEMM looks like in Rust, and do not ship it
Foundations
rustls 0.23.44 — Rustls turned ten, Joe Birr-Pixton wrote the retrospective from his RustConf talk, and it is on the radar for the first time this week because the stewardship story is the argument of the issue. First commit May 2, 2016; interoperating with most of the web by June 5; 0.1.0 on August 27. Then eight years of API refinement to 0.23, and since February 29, 2024 the 0.23 line has shipped 43 non-breaking releases while adding a FIPS-certified crypto option, certificate compression, Encrypted ClientHello and post-quantum key exchange. That is what "stable" means when someone is paid to make it mean that: Birr-Pixton is full-time on Rustls via ISRG's Prossimo initiative, Dirkjan Ochtman's first paid contributions were a Prossimo robustness contract in 2021, and the 2020 Cure53 audit was funded by CNCF at Buoyant's request. 0.23.44 landed September 7. The reason to read the post rather than just bump the patch is 0.24, the next breaking line, which is already at 0.24.0-dev.1. Buffering moves outside the library: TLS input arrives through a TlsInputBuffer trait, output appends to a &mut Vec<u8> you own, and plaintext is decrypted in place and returned as a borrow, so the extra copies and the no_std awkwardness go away together. The handshake becomes session types (NeedsInput to Accepted to VerifyClientIdentity to Complete) so async, blocking and completion-based callers share one API without waiting on async dyn traits. Post-handshake send and receive split into two Send objects, so a full-duplex workload can run them on different threads and, they claim, double throughput; that feature was first requested in 2019. And crypto providers move out to rustls-aws-lc-rs and rustls-ring crates, which kills the feature-unification panics. After 0.24 bakes, 1.0.
Maintenance: actively maintained and funded (Joe Birr-Pixton, Dirkjan Ochtman, Daniel McCarney; ISRG Prossimo); ~7.6k stars; OpenSSF best-practices badge · Latest: v0.23.44 (Sep 7, 2026); 0.24.0-dev.1 (Jul 23) · Adoption: Adopt for the 0.23 line, which is what your HTTP stack already pulls in; treat 0.24 as a real port and plan it, because the I/O model changes
Concurrency
tokio_rcu 0.1.3 — This Week in Rust 668's Crate of the Week, self-suggested by Roee Shoshani, a one-line mention in Rust Bytes last Sunday, and the small crate in this issue whose fate is decided elsewhere. It is user-space read-copy-update built around tokio's semantics, and the design choice is the interesting part: the quiescent state is tokio's on_after_task_poll hook. That works because the crate forbids holding an RCU-protected pointer across an .await, so when the hook fires on a worker thread, that thread provably holds none, and a writer waiting for a grace period only has to see every worker pass through the hook once. Readers pay a single atomic load plus a thread-local write used to catch misuse. Shoshani's divan benchmarks against arc-swap on a 12700 show reads about three times faster and, more usefully, flat as reader count grows and flat while writers are active, where arc-swap's read time scales with contention. Writes are about three times slower, mostly because they sleep through the grace period rather than because they burn CPU. If you keep a routing table, a feature-flag set or a model registry that is read on every request and rewritten every few minutes, this is the shape you want. The catch is upstream: it requires tokio_unstable because the hook is not stable, it is Linux and Windows only because it needs membarrier or FlushProcessWriteBuffers, and it assumes one runtime per process. Whether this crate can ever be stable is a tokio decision, not the author's.
Maintenance: brand new, solo (Roee Shoshani); 157 commits; 8 stars; MIT · Latest: v0.1.3 (Sep 11, 2026) · Adoption: Assess; well-reasoned, honestly benchmarked, and gated on a runtime flag you may not be allowed to turn on
Data plumbing
oracledb 26.0.0-beta.3 — surfaced by the newsletter scan rather than by anyone in Rust talking about it, which is itself a signal. Go Weekly 617 flagged go-oracledb, Oracle's first official pure-Go driver, as interesting-because-Oracle. The same organisation has been publishing a pure-Rust one since mid-August: beta.1 about a month ago, beta.2 on August 20, beta.3 on September 8, all by Anthony Tuininga, who wrote python-oracledb's thin mode and is the right person to be doing this. As of this writing the GitHub repo has 7 stars and 9 commits. It speaks TNS directly, so no Instant Client and no OCI, supports Oracle 12 through 26ai, needs Rust 1.89, and the feature list reads like a vendor knows what its customers ask for: compressed fetch, statement caching with auto-tuning, DRCP, array DML, VECTOR and JSON types, and an optional arrow feature that returns a query as a RecordBatch, which is the one AI-adjacent teams will care about because it puts Oracle tables one hop from Polars, DataFusion and Lance. The crates.io history is the part I would read twice. The oracledb name was Muhammed Durakovic's community thin driver from June 14; his 0.5 through 0.9.1 releases are now yanked, Oracle publishes under the name, and his driver continues as oraclemcp-driver-cx. That is the best case for a vendor adopting an ecosystem: the community author's work becomes the official driver and the original keeps its own name as a fallback. It is also a reminder that the fallback exists because vendors lose interest. Sync API only for now.
Maintenance: brand new under Oracle Corporation (Anthony Tuininga); 9 public commits; three betas in four weeks; replaces Muhammed Durakovic's community driver · Latest: v26.0.0-beta.3 (Sep 8, 2026) · Adoption: Assess; an official driver at beta.3 is a stewardship signal and a maturity warning in one sentence, and the Arrow path is the reason to try it first
Language watch
cargo installnow uses the packaged lockfile by default — Cargo PR 17388 by gmemuriuki was still listed in final comment period when This Week in Rust 668 went out on Wednesday; Ed Page merged it on September 11. Until nowcargo install fooresolved fresh unless you passed--locked, so the binary you installed was not the one the author tested;--lockedis now a no-op and a package without a lockfile falls back to normal resolution. After a month of supply-chain entries in this section, this is the next cheap default, and it lands in the toolchain without you doing anything.- The never type is stabilized, and this time I checked. In issue #11 I corrected #10: the implementation had merged but the T-types decision had not. That decision has now been made. Issue 161925, the T-types final comment period, finished with a disposition to merge and is closed, and the stabilization PR itself, 155499 by WaffleLapkin, merged on August 24:
!is nameable,Infallibleis an alias for it, and never-type fallback goes to!on every edition. It rides the trains to stable from here. Rust Bytes led with this last Sunday, so I am closing the loop rather than reopening the story. - Smart pointer
mapfunctions are stabilized — PR 160534 merged this week, alongside custom-allocator support formapandtry_maponUniqueArcandUniqueRc(PR 161893). - Cargo feature descriptions are an accepted RFC — RFC 3485, approved this week. Features get documentation in
Cargo.toml, which is the prerequisite for docs.rs andcargo addexplaining what--features arrowactually does. Also approved: Rustdoc LaTeX math. - Still in final comment period:
core::mem::DropGuard(PR 161520), the 8-byteRawWakerVTablealignment guarantee (PR 158186), stabilizing the RISC-Vdandftarget features, and a reference PR titled, with admirable directness, "UB does not time travel". And Clippy soft-renamedclippy::alltoclippy::default; the old name keeps working.
In brief
Rust 1.98.1 — a point release on September 3 fixing a vtable miscompilation in 1.98.0 where rustc emitted a null pointer where a function pointer belonged; found by Glen De Cauwsemaecker running rama, issue #9's Trial entry, on aarch64-apple-darwin, and if you are on 1.98.0 this is not optional · mold is being rewritten in Rust — Rui Ueyama says mold 3.0 will be a Rust rewrite with full linker-script support so it can link kernels and firmware, with the stated goal of becoming the default linker on Linux distributions; 2.42.1 is likely the last C++ release · Rust debugging survey 2026 results — over 2,300 responses, more than half of whom do not use a debugger at all; of those who do, 74% name poor value representation as the pain, with enums, HashMap and Vec showing implementation details instead of contents · Rust/C++ Interop Initiative progress update — the Foundation's engineer Teor is tracking 40 interop problems with 8 analysed in depth, a draft roadmap, and a "splat" overloading experiment for ergonomic C++ FFI with Outreachy interns; funded by Google · The State of Allocators in 2026, six months later by cetra3 · Searching through 150 GiB of text per second with SIMD · What Does a Governed Data Runtime Cost? TeaQL vs Diesel and SeaORM on MusicBrainz — a vendor benchmark, read it as one, but SeaORM sits at Trial on this radar and it is useful to see it measured · Nine Rules for Compile-Time Work with Rust const fn, Part 2 by Carl Kadie, continuing last week's entry · Microcontrollers with good support for Rust by Sylvain Kerkour · Speeding up gearhash on ARM64 (2x faster) · Safely generating legal chess moves at 475,000,000 nodes/s · Let's build a compressor from scratch by Adolfo Ochagavía · A Design Space Exploration of Async/Await from Brown's PL group · Stabilizing Rust's never type on LWN, which is the long version of my correction in issue #11 · Awesome Rust Migrations by Kevin Couton, a list of public rewrite stories, which is the evidence base you want when someone asks "who else has done this" · compiler perf triage by @JonathanBrouwer: 3 regressions, 2 improvements, 8 mixed across 33 comparisons, primary mean +0.1%, plus a 75% memory reduction compiling bevy_render under the next trait solver · and lib.rs's notable-releases list this week included wasmtime, syd, cudarc, clap, crypto-bigint and picoserve, none of which I have verified individually this run.
Elsewhere
- Go's module jail just converged on the Rust approach. Go Weekly 617 led its tools section with gomodjail 2.0 by Akihiro Suda, creator of Lima and nerdctl: mark a dependency
// gomodjail:confinedingo.modand the tool refuses to let it reach the filesystem, the network, process execution, raw syscalls or cgo. What is new in 2.0 is how. The 1.x design enforced that at runtime, with seccomp and stack unwinding to work out which module made a syscall; 2.0 moves the focus to static analysis, sogomodjail analyze ./...fails the build if a confined module's code can reach a denied capability, and the runtime mode is now labelled legacy. That is the shape of cargo-acl (Cackle), issue #10's lead, which has always decided at build time by analysing which API categories each crate reaches, with an optional bubblewrap sandbox for build scripts. Two ecosystems, two solo maintainers, and they arrived at the same answer from opposite directions, which is decent evidence it is the right answer. Cackle's honest caveat is that a determined author can evade static detection; gomodjail's is that it cannot protect a module that importsunsafe,reflector cgo, which is the same caveat in a different type system. Verdict on Cackle holds at Trial. The interesting question is why neither package manager has made this first-party. - Oracle shipped official pure-language drivers for Go and Rust in the same breath, and only one got noticed. Go Weekly covered go-oracledb as beta-but-official. The Rust one is in the Data plumbing entry above, three betas in and my point in pairing them is that the Rust community's information supply chain missed it entirely: no TWiR mention, no Rust Bytes mention, no Reddit thread I could find, seven stars on the repo. If your team runs Oracle and Rust, you found out here.
- Ben Boyter got out-run by a Rust code counter and wrote up the recovery. Sloc Cloc and Code: Did I just get Buster Scrugged? is the story of Petros Subamanis's mezura, written in Rust, counting the Linux kernel 2.56x faster than Boyter's Go
scc. What makes it worth your time is not the language rivalry, which Boyter explicitly declines to have. It is the method:strace -f -con both, noticesccmaking 2.6x the syscalls for 28% more files, find that Go'sos.Opencosts five syscalls before the first byte because it offers every file to epoll and gets refused, and fix the pipeline.scc4.1.0 now edges mezura by 8%, with a Claude-written per-language state machine behind a flag taking it to 22%. His subtitle is the leadership lesson: treat faster tools as a profile, not an insult.
A thought for the week
Every crate in your lock file has a payroll. You should know whose.
This issue is four stewardship stories wearing different clothes. NVIDIA took a research artifact that already worked and did the one thing a repo cannot do for itself: it said, in public, with a date, that the company intends to keep paying for it. That sentence is what moved cuTile from Assess to Trial. The code was roughly as good in June. Rustls has shipped 43 releases in thirty months without breaking a caller because a nonprofit pays one person to make that his job, and two more got paid contracts at the moments that mattered. Oracle took a community author's thin driver and made it the official one, which is the best outcome that author could have hoped for, and also means the driver's future is now tied to a vendor's product priorities rather than his enthusiasm. And tokio_rcu is a careful, well-benchmarked primitive whose stability is not the author's to decide, because it sits on a tokio hook that tokio has not committed to.
The engineering-leadership version of this is uncomfortable, because we are trained to evaluate dependencies on what they do. Problem fit, API quality, benchmarks, test coverage. Those are real, and they are also the things that stay roughly constant. What changes, and what actually determines whether the crate is still there in three years, is who is paying the maintainer and whether that arrangement outlives the current quarter. Wasmi's code did not get worse last week; its funding did. cuTile's code did not get better this week; its steward did.
So add a line to the ADR template. Not "is it maintained," which every README claims. Ask: who is paid to maintain this, by whom, until when, and what happens to the project if that stops? For rustls the answer is a foundation with a mission and a track record. For cuTile it is NVIDIA's platform roadmap. For tokio_rcu it is one person's evenings and a tokio decision. None of those answers is disqualifying. All of them belong in the document, because the person who inherits your system will want to know which of your dependencies came with a payroll and which came with a hope.
Before I go
Oxidize is in Berlin today through Tuesday, and I deliberately did not lead with RustConf's talks because the recordings are not out yet; when they are, Melih Elibol's Fearless Concurrency on the GPU is the one to pair with this issue's lead, and Joe Birr-Pixton's Rustls decade talk is the one to pair with the Foundations entry. Rust Bytes #135 led with the never type last Sunday and ran tokio_rcu as a one-liner, which is why the never type is a closing line in Language watch here rather than a lead, and why the tokio_rcu entry is a verdict rather than an announcement. Nothing else in this issue had run there.
Two things I would like to hear about. First, if you are running Oracle in production from Rust, on the community driver or the new official one, I want to know what the migration looked like; the driver is a week old and nobody has written that up. Second, tokio_rcu: if you are on the tokio team or know the status of on_after_task_poll, whether that hook has a path to stable decides whether this crate has a future, and I would rather report the answer than speculate.
That's the issue. Got a Rust+AI crate or tool I should feature next week? Reply and tell me; reader picks shape the list.
Keep shipping, Decebal
