Devil's advocate from the description at the top of relevant groups speaking. The two in areas I'm familiar with are areas I'm excited about seeing rust take off in the future, and are already a great use of it. I don't think those groups are the ones that will (or should) do it.<p>Rust-GPU: This is the org responsible for Rust CUDA, which was a historically non-working library I spent too much time trying to get working. Instead, Cudarc is a simple, "just-works" library with a responsive maintainer. For grpahics, WGPU and Vulkan bindings are good paths. To watch: Nvidia's official Cuda-Oxide, which uses Cudarc's style API for Host, and its own native Rust kernels. (Early/WIP stage on that). It is surprising to see "Rust GPU" there instead of WGPU, Nvidia/Cuda-Oxide, or Cudarc there, as it's the least viable of the set.<p>Embedded is a fantastic area for Rust to excel in, and it's already excellent thanks to the general language tooling, Cargo, and the Knurling tools Probe-RS and defmt. I'm not sold on the embedded working group's history and style. E.g. Embedded HAL is a poor fit for practical firmware and integrations. ESP on Rust was great but turned into a mess 1 - 1.5 years ago due to mismanagement, and letting a new maintainer rewrite large chunks of the HAL. I'm comfortable using Rust on STM32 and nRF, and have built working aerobatic quadcopter firmware in Rust, but have never seen eye-to-eye with the working group. In general, they trend towards complicated APIs which focus on Traits, safe abstractions, Async etc. My pref: Use Rust as a nice overall language, and write low-friction APIs, vs the abstractions.<p>I disconnected from the Embedded rust OSS scene; It's still my top choice for new hardware, and use it at work. It seemed like no one wanted to talk about projects and building things with rust; instead it was about using ownership, generics, safety, Async models etc to make clunky APIs.
Maintainer of rust-gpu and rust-cuda here.<p>1. Rust CUDA is over 5 years years old, was dead for 2(?) years, but was rebooted and works. It enables both rust on the GPU and controlling the GPU from the host. The host library (cust) predates cudarc. If it was started today it would just use cudarc for the host side (and indeed, you can use the device side with cudarc). Rust-cuda is based on nvvm, which was the supported layer in the past but Nvidia is moving away from.<p>2. Rust-gpu (vulkan) works but isn't 100% complete of course. The dimforge folks are using, there are some crypto folks using, and we have llms written in it. Rust-gpu is only the "running rust on GPU part", the host is left to wgpu or ash or whatever.<p>The Nvidia projects are great (we gave pre-release feedback on them), but they were not announced when the call for presentations went out. They were also released as experimental with only 2 people working on them so Nvidia was cautious about marketing and over-committing.<p>We are the only people trying to bring rust natively to the GPU rather than just making the GPU work with rust (which others like cubecl, wgpu, cuda-oxide handle well). This has some interesting considerations from a rust language and compiler standpoint, which is what was talked about at the conf.<p>We sponsored an unconf room and got as many folks from all the various GPU projects together, including nvidia. The big problems right now are a) everybody has different needs, b) there are very few people working in the space c) the entire rust project is generally indifferent to GPUs. I expect this to change in the next year or two.
That is great context and promising for the ecosystem as a whole. I owe it to myself and you to try it again. I think I will take an existing code base (I have a molecular dynamics engine in rust) that uses CUDARC, and I will write similar Cuda Oxide and Rust-Cuda implementations to compare. Would love to see what each does well. (Bearing in mind Cuda Oxide in particular may change its API heavily; IIRC I had an issue installing it in the past which blocked me, but I don't recall what specifically)<p>There is also a Cuda-Tile rust lib which I have been meaning to try, but I haven't used tiles so far.
Quite honestly I would use cuda-oxide over rust-cuda for anything new right now....while rust-cuda is more complete, cuda-oxide is more aligned with nvidia's future direction (when we were rebooting rust-cuda we were told to by nvidia to stay with the nvvm layer but their plans changed and it is clearly not where their focus is). It's of course just rust so you could just feature-gate off differences as 80% will probably be the same if you wanted to try both projects.<p>cuda-tile is great...I would use it for anything written from scratch as it is closer to how the hardware (and projects like triton) work. But there are tradeoffs as it requries your code to be structured a certain way.
> <i>In general, they trend towards complicated APIs which focus on Traits, safe abstractions, Async etc. My pref: Use Rust as a nice overall language, and write low-friction APIs, vs the abstractions.</i><p>Co-signed.