8 ms·
Nvidia announces native GPU programming in Rust
- nonmaskable 19d ago[dead]
- ReshamJoshi 19d ago[dead]
- the__alchemist 19d agoI'm looking forward to trying these when they stabilize! I currently use WGPU for graphics, and cudarc for CUDA. Note: Cuda-oxide is similar to Cudarc's host component, but uses a rust-style kernel dialect. Advantage: Share structs between host and device. Disadvantage: Trading standard Cuda kernels for a new, WIP dialect. I haven't tried the tile API yet; looking forward to it. The last time I checked, Cuda Oxide was Linux only, and required Async; these are why I haven't tried it yet.
- melihelibol 18d agoIt's still linux-only but doesn't require async. You should be able to execute and compose kernels synchronously.
- embedding-shape 19d agocudarc been great for me, because it's easy to look up existing examples and references, and it maps 1-to-1 with what I see. I'm already having a tough time with CUDA itself, a dialect of it makes a tad harder to rely on previous work. Seems more ergonomic in general though, both approaches they share, compared to cudarc, and less build infrastructure and fiddling with environments, which is great.
- dllu 19d agoSince NVIDIA owns huggingface now and huggingface has the excellent Candle [1] crate for inference on Rust, this seems like a good step towards nice native Rust kernels. [1] https://github.com/huggingface/candle https://github.com/huggingface/candle
- jacobgorm 19d agoNobody cares if kernels are written in Rust. Kernels were meant to be written in C, but if you want to go more high-level try Triton or a similar DSL that nicely abstract tile sizes etc.
- deleted 19d ago[deleted]
- cpill 19d agooh no no no, this is going to break the CPP hold on AI and game dev.
- pjmlp 19d agoNah, Rust compiler still needs C++ to be built in first place, and everyone on AI uses LLVM as infrastructure.
- keithnz 19d agokernels aren't meant to be written by any defined language. C is just a traditionally good default language that took over from assembly. No particular reason we have to stick with C.
- chadcmulligan 19d agoAnd quite a few reasons that something better than C should be used. Rust seems a good candidate.
- jacobgorm 18d agoWhat reasons would you have to prefer Rust over C for compute kernels? I am a great fan of Rust, but I don't see any benefit for kernels, due to their relatively simple nature.
- 18d ago
- claiir 19d ago> The launch is checked rather than trusted. Damn even Nvidia is putting out fully Claude-written articles.
- bayindirh 19d agoThat's actually a magnificent observation. This is not only an indication of a keen eye, but a trained brilliant mind as well.
- hitekker 19d agoYou’re absolutely right!
- jubilanti 19d agoOne might even say it is load-bearing on the seam!
- lioeters 19d agoWhy this is important: it's the honest take.
- pbkompasz 19d agoI hate this
- bayindirh 18d agoGenuinely, why?
- efilife 18d agothis is literally a reddit comment chain
- bayindirh 18d agoWe do this wicked sin called having fun once in a blue moon here. Slashdot's spirit shall live somewhere, no? Rent is all-time high and it can only afford here, for now.
- rvz 19d agoFirst of all, this is a pre-1.0 release that requires a nightly Rust compiler (if you choose the SIMT track with cuda-oxide) so that one is going to be unstable software. Secondly, When an issue occurs with a kernel or you want to write your own custom kernel in Rust, now we need to diagnose if the problem came from either cuda-oxide (SIMT), Rust's side, CUDA or Tile (If you decide to choose the Tile track). Another dependency into the list and course everything is open source except CUDA itself. So any issue that happens on the CUDA level, you are forced to wait for them to fix it.
- LarsDu88 19d agoIn this age of LLM written everything which has softly killed my motivation for learning Rust somewhat, this has revived my interest if not only for the fact the LLMs haven't yet been trained on this yet!
- impulser_ 19d agoLLM don't need to be trained in a library to use it well. It's just Rust which they know well.
- w4yai 19d agoAnd what prevent you exactly ? There were humans far superior than you for writting Rust before LLM, now there's a LLM. The only difference is price and time execution. You get an awesome teacher (LLM) ready to answer all your questions about Rust. And you still find excuses not to learn it ? At some point, just realize you've been lazy to learn it and LLMs are just an excuse.
- afavour 19d agoI think OP’s point is that the payoff in learning a new language has diminished in this AI era. You can call that lazy, I’d consider it smart to consider whether you could be doing other, better, things with your time.
- w4yai 19d agoIf the sole motivation for learning things are payoff, then sure.
- frogperson 19d agothe sole motivation is feeding and sheltering my family. in the time BC (before Clankers), rust was a better way to do that.
- wartywhoa23 18d ago
- nicebyte 19d agowhat this article tells me is that no one at Nvidia actually cares about this project whatsoever. otherwise, they would have had a person actually write the announcement.
- jacobgorm 19d agoI strongly dislike CUDA. Once you have allowed that proprietary cr*p into your C++ codebase, it is very hard to get rid, and you end up with code that is either tied to a single vendor or an #ifdef hell, probably both. The best way to program GPUs is face up to the reality that they are not the same machine as the CPU, write your kernels in separate files, and launch them manually, like in Metal, OpenCL, and D3D12, etc. These days we even have DSLs like Triton that make kernel writing much more ergonomic than anything you would hope to achieve in Rust.
- bigyabai 19d agoIs this satire? D3D12 and Metal aren't any less proprietary than CUDA.
- deleted 19d ago[deleted]
- jacobgorm 18d agoYou can call their APIs without needing to compile your code with a proprietary compiler or adopt a bastardized version of C++.
- bigyabai 18d agoSounds like a C problem, not a CUDA problem.
- pjmlp 18d agoActually no. You need Objective-C, Swift, and Metal is a C++14 dialect with extensions. You may refer to the C++ bindings, which still not obviate the need for the C++14 dialect in the shaders, and it only works, because there is a shim to call the Objective-C runtime from C++. Likewise there are DirectX COM interfaces that are really only usable from Visual C++ COM extensions, and the HLSL semantics depend very much on which compiler is being used, hence why there is finally a language reboot going on.
- pavon 19d ago
- manyatoms 19d agoHow does this compare to vectorware? (https://www.vectorware.com/blog/ https://www.vectorware.com/blog/)
- LegNeato 19d agoVectorWare founder here. We are working with them and stoked they are investing more in Rust. I just gave a talk at RustConf about our different takes (https://rustconf2026.sched.com/event/2KNQj/making-gpus-feel-native-in-rust https://rustconf2026.sched.com/event/2KNQj/making-gpus-feel-...). The video isn't up yet but you should check it out when it is. The efforts are complementary.
- binarybana 19d agoTowards the end of the post, we (NVIDIA) mention that this work was done in collaboration with Vectorware and others in the Rust community. And we can't wait to build further with the community.
- khaliostr 18d ago[dead]
- bt1a 19d agoWill it then be possible to query TJunc hotspot temps on linux?
- mococa 19d agoThe world is unsafe
- Xeoncross 19d agoRust just makes you sign a waiver first.
- mococa 19d agoAI slop article, how can I trust on this?
- pjmlp 19d agoThe same way as people trust AI sloppy on their code.
- westurner 19d ago[dead]
- shmerl 19d agoNvidia only? Typical. This is more promising: https://github.com/Rust-GPU/rust-gpu/ https://github.com/Rust-GPU/rust-gpu/
- anon291 19d agoOnce again... There's literally no point to a low level shader language for heterogenous back ends.
- hobofan 18d agoWhy? The point of a shader language is to define a function that outputs some graphics. Why should that not be portable between GPUs/CPUs of different vendors?
- shmerl 18d agoMore generally any GPU computation, not necessarily graphics. The above argument could go that there is no point in high level languages for CPUs either and everyone should just always use assembly, which is obviously false. Same can go for GPUs.
- anon291 18d agoI mean if you're worried about high performance compute on cpus, then the argument also applies. That's why there so much hand written assembler with dynamic dispatch on CPU features... It's just that gpus have no general purpose usage .. for ai, it's basically all about perf. Of course some cross platform stuff can be made for modest acceleration, but the state of the art is always going to be out of reach.
- shmerl 17d agoNah, I don't buy it. There is room for assembly usage, yes, but the claim that it's the only way to do things is clearly false and compilers from high level languages in most cases are enough.
- dunlin 19d agoRust for GPU programming? My CUDA debugging sessions just got a whole lot less painful, hopefully.
- bcjdjsndon 19d agoThere's a lot of unsafe code at that level... Rust probably makes it more painful for little gain
- Driftbench 19d agoBeen waiting for something like this. CUDA C++ is a pain; Rust's safety for kernel programming could be a game changer.
- evaltoken 19d agoInteresting direction from Nvidia. Anything that makes writing reliable GPU code less painful is definitely a good thing.
- nullbio 19d agoMakes me sad that Go doesn't get love. I feel like Go is perfect for LLMs.
- winwang 19d agoReally exciting but it reads like Claude instead of what Nvidia posts have generally been like in the past. I don't need nor want my tech blogs to sound like a young adult novel.
- aabhay 19d agoI’ve had this happen to me several time over the past weeks and it’s gone from quaint to humorous to farcical to outright “is-the-world-gaslighting-me” insane. Just today I was reading Stanley Druckenmiller’s op ed in WSJ. This dude is like 80 and has made billions of dollars, and he got Claude to write his op ed??? Unbelievable. And the tells are so obvious, yet people still love the Claude-like quips and odd grammatical choices that read like halfway asshole halfway mid-sentence confusion.
- sebmellen 19d agoThat op ed was absurd. I respect Druckenmiller a lot and am always impressed with his lucidity in interviews. The Claude “ick” was all over his writing.
- IshKebab 19d agoYeah definitely Claude. Lazy authors, if you're going to get AI to write for you please use Astra instead - it makes way less annoying prose than Claude.
- boonzeet 18d agoNVIDIA is part of that shift NVIDIA CUDA Rust closes that gap
- salsa_catsup 19d agoDoes this mean I can write shaders in Rust for use with WGPU or Vulkan?
- ivanjermakov 19d agoWGPU/Vulkan don't work with PTX shaders by default, additional translation would be needed. On a side note, Vulkan has extension to launch CUDA kernels: https://docs.vulkan.org/refpages/latest/refpages/source/VK_NV_cuda_kernel_launch.html https://docs.vulkan.org/refpages/latest/refpages/source/VK_N...
- berkes 19d agoThe way I understood it, rust would become an option next to Vulkan, WGPU (and opengl etc?). But only for compute tasks. So, practically an alternative language to write compute shaders in.
- PudgePacket 18d agoYou have been able to for a while with rust-gpu https://github.com/Rust-GPU/rust-gpu https://github.com/Rust-GPU/rust-gpu.
- laggui 18d agoFor compute shaders, you can already do this with CubeCL: https://github.com/tracel-ai/cubecl https://github.com/tracel-ai/cubecl You write kernels in a Rust DSL using #[cube], it supports WebGPU through WGSL and Vulkan through SPIR-V, along with CUDA, AMD via ROCm, and Metal. (disclosure: I am a contributor)
- jauntywundrkind 19d agoWorth mentioning that Nvidia open sourced CUDA Tile IR ~8 months ago. And yes the code is open source too. https://news.ycombinator.com/item?id=46330732 https://news.ycombinator.com/item?id=46330732
- Danox 19d agoThe recent circular moves that Nvidia is making is designed to wrap things around them, anything to keep the AI model party going.
- lsofzz 19d agoI read this the other day - definitely think it is the right direction Nvidia is taking. Thank you NVIDIA - for once (not twice though - you've given us nothing but despair for Linux+GPU).
- jtfrench 19d agoI wonder how many parallels there are between CUDA's Tile abstraction and that of Metal.
- HexDecOctBin 19d agoAnyone know when Rust's std::autodiff will become stable? Assuming this Rust support expands to other GPU vendors, autograd will probably be the only reason to use Slang instead of Rust anymore.
- minraws 19d agoNot in 2026.
- chkmr 19d agoI was told in the 2025 LLVM dev meeting that it will always stay in nightly because it's not practical for them to provide long-term stability guarantees that is expected of stable Rust.
- HexDecOctBin 18d agoThat's a shame
- calini 19d agoDo it in Go and I’m interested
- jrhey 18d agoGo is simply not feasible for CUDA work mainly because of the go runtime that manages GC, allocation, scheduling etc GPU kernels want explicit memory control and as little go-runtime like overhead as possible
- michalsustr 19d agoNot a cuda programmer, but since they’re making a new API, why would they already make it inconsistent at start? :-/ I’m referring to the examples a,b,c vs z,x,y (different ordering of output elements)
- m00dy 19d agoThank you Nvidia !! You're in the right path.
- Swiffy0 19d agoMy understanding is not so deep regarding GPU programming or Rust... Does this mean anything regarding Nvidia GPUs and WebAssembly / WebGPU?
- onion2k 19d agoNo. Rust is a non-web programming language.
- kalikingkorea 19d agohmmm interesting
- amelius 18d agoDoes this weld Rust to CUDA? Can we use the Rust code to run on other archs?
- singularity2001 18d agoyikes, I prefer python taichi similar to @fast def calc(x,y):pass
- deleted 18d ago[deleted]
- aquavoplumbing 18d ago[dead]
- lambdaone 18d agoThe momentum behind rust seems absolutely unstoppable at the moment, in the light of this, the adoption of Rust into the Linux kernel, and the adoption of for formally verified software by Amazon and Microsoft.
- ModernMech 18d agoDeservedly so.
- fhn 18d agonot too long ago, commenters on HN hated Rust and would never use anything written in Rust. So, now that Rust is in Linux, they shouldn't be using Linux either.
- loup-vaillant 18d agoOkay, so, GPUs are taking one more step towards being general purpose massively parallel machines. That's cool. What would be even cooler though would be for GPU vendors to start giving us the user manual. An I mean the real user manual, that explains how to use their piece of metal when all you have is that piece of metal. That means a precise description of the wire protocols, the data format of the buffers we send to & get from the GPU, the ISA of the cores we have access to, the relevant performance characteristics… In other words, enough information to write a state-of-the-art driver for any OS. That would be cool.
- surajrmal 18d agoThey don't need to do that to sell their hardware so why would they do that? On the other hand, they have strong incentives to not give you that level of access and information. The only way this will change is by having some disruption by way of a competitor who sells hardware with that feature as being a major reason why it takes off.
- loup-vaillant 18d agoOr we could regulate. One hammer I'm tempted to use is to simply forbid sales and importation of hardware made by companies that also distribute software. That way the only way to sell you hardware is to make sure its interfaces are both simple and thoroughly documented. We could possibly make an exception for open source software, or only forbid the distribution of the relevant drivers, or limit the applicability of that law to specific hardware: hard drives, mice, printers, web cams... or GPUs. Anyway, that should be disruption enough.
- laughingcurve 18d agoGPGPU https://en.wikipedia.org/wiki/General-purpose_computing_on_graphics_processing_units https://en.wikipedia.org/wiki/General-purpose_computing_on_g...
- floil 18d agoThey don't release it because exposing a stable instruction set would kill their ability to quickly iterate, to release silicon with bugs that can be papered over with software fixes, as fixing bugs in chips is very expensive in terms of time to market, and undoubtedly to charge more for what looks like a hardware feature but actually is a software feature. It's been this way for 25 years and I don't see it changing.
- soleveloper 18d agoSo now every already written kernel can be re-written in Rust and have competitive performance to the cpp version? If so, that's really big. And to add the Next natural strp - custom codegen for simulating gpu compute and memory without Nvidia gpu.
- revengerwizard 18d agoI think it would be much nicer, although unrealistic at the moment given the number of combinations of GPU vendors and variety of hardware, to directly target the underneath GPU ISA machine code. Since I can write a simple compiler to target x64 machine code, it should be possible to write one to target my GPU. Though, I'm certain that vendor lock is probably more profitable for them.
- matthewfcarlson 18d agoI don’t know for sure but I’m pretty sure the ISA changes quite frequently for Nvidia.
- cmrdporcupine 18d agoMy thoughts on this, as a person who has recently coming around to working in this space is that up to now the convenience and "simplicity" of working in CUDA as it is has been a giant moat for NVIDIA. Having a whole toolchain with a C++ dialect and a giant extant pile of code out there that looked familiar to people meant they've "won" the AI wars. And in that context NVIDIA had every motivation to keep their SDK somewhat abstracted higher up the chain and fully under their control and then be free to innovate in the lower bits. And this served them well as well as their customers. My sense is that now with agent driven development this is basically evaporating. Agents are capable of at least prototyping/writing kernels for any hardware and ISA. e.g. OpenAI built their own custom hardware and ISA for it and then set agents loose on it writing kernels and claims great success. At least they're claiming this. And from my own experiences as a n00b entering this space, I can believe it. TLDR I don't think vendor lock on the software side is going to work out for them as a strategy. But luckily for them they continue to have really good hardware and good access to semiconductor fabrication. But just look at HotChips 2026 a couple weeks ago and look at the huge variety of new inference hardware coming down the pipe which looks completely unlike NVIDIA/CUDA.
- jtrn 18d ago[dead]
- deleted 18d ago[deleted]
- thetwentyone 18d agoI've been enjoying writing Julia code and then having it run on the GPU via the packages at https://juliagpu.org https://juliagpu.org
- Ericson2314 18d agoTo everyone skeptical of people saying that it's better to separate CPU and GPU code into separate files, riddle me this: With this system, how do we specify whether dependencies are needed to be compiled for the CPU, GPU, or both? ---- Technically I don't know really care whether it's multiple files or one, I just want to make sure we are not reinventing a shittier version of CFG. What they are providing looks to me like: 1. explicitly annotate some things as `cfg(GPU)` or ungated (both) 2. unlabeled means annotated `cfg(not(GPU))` by definitely Put this way, this has nothing to do with GPUs, and just has to do with creating some crate-local CFG shorthanded. Great! Let's do that first, get a solid foundation, and then come back to whatever is remaining for CUDA Rust.
- orangelimetea 18d ago[dead]
- adityazero 17d agoRust/C/C++ all have a similar memory model, they were designed for a linear memory model. a `float` does not carry the provenance (a float out of cudaMalloc or a malloc look the same to the rest of the program). This is the fundamental problem that very few (e.g., Vx vxlang.org) are trying to address.
- poppafuze 15d agoNobody wants to write 'let' all day.