Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust All Hands 2026 Retrospective

blog.rust-lang.org

Post reply on HN
Print view View original

11–20 of 63 posts

Re: Rust All Hands 2026 Retrospective

#11

Post by woodruffw »

rr808 wrote: post #10
Aurornis wrote: post #4

Earlier quoted context omitted.

> I could also see it slipping into obscurity as LLMs get faster and compile times become a more and more obvious bottleneck on iteration speeds. I’ve worked on some very large Rust projects. The incremental compile times are nowhere near the same order of magnitude of a bottleneck as an LLM turn.

How long does a compile take? Because this was the biggest issue for me. I dont really like Python but the ability to make some changes then run it instantly is wild for me.

You probably already know this, but I figure it bears repeating: most people should be running `cargo check` during development, not `cargo build`. The latter is only necessary when you actually need the built binary; the former is sufficient for type- and borrow-checking.

(On my local machine, `cargo check` is roughly 2x faster than `cargo build`. It's still slower than hot-reloaded Python, but it's rarely my development bottleneck.)

Re: Rust All Hands 2026 Retrospective

#12

Post by LegNeato »

the__alchemist wrote: post #7

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. 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 worki…

Maintainer of rust-gpu and rust-cuda here.

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.

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.

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.

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.

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.

Re: Rust All Hands 2026 Retrospective

#13

Post by the__alchemist »

LegNeato wrote: post #12
the__alchemist wrote: post #7

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. 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 worki…

Maintainer of rust-gpu and rust-cuda here. 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 supporte…

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)

There is also a Cuda-Tile rust lib which I have been meaning to try, but I haven't used tiles so far.

Re: Rust All Hands 2026 Retrospective

#14

Post by pjmlp »

woodruffw wrote: post #11
rr808 wrote: post #10

Earlier quoted context omitted.

How long does a compile take? Because this was the biggest issue for me. I dont really like Python but the ability to make some changes then run it instantly is wild for me.

You probably already know this, but I figure it bears repeating: most people should be running `cargo check` during development, not `cargo build`. The latter is only necessary when you actually need the built binary; the former is sufficient for type- and borrow-checking. (On my local machine, `cargo check` is roughly 2x faster than `cargo build`. It's still slower than hot-reloaded Python, but it's rarely my develo…

A non starter for anything related to graphics or UI development, which is kind of most Rust stuff are CLIs or TUIs, like being back on curses heyday, Turbo Vision and Clipper.

Re: Rust All Hands 2026 Retrospective

#15

Post by LegNeato »

the__alchemist wrote: post #13
LegNeato wrote: post #12

Earlier quoted context omitted.

Maintainer of rust-gpu and rust-cuda here. 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 supporte…

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 issu…

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.

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.

Re: Rust All Hands 2026 Retrospective

#17

Post by Klonoar »

pjmlp wrote: post #14
woodruffw wrote: post #11

Earlier quoted context omitted.

You probably already know this, but I figure it bears repeating: most people should be running `cargo check` during development, not `cargo build`. The latter is only necessary when you actually need the built binary; the former is sufficient for type- and borrow-checking. (On my local machine, `cargo check` is roughly 2x faster than `cargo build`. It's still slower than hot-reloaded Python, but it's rarely my develo…

A non starter for anything related to graphics or UI development, which is kind of most Rust stuff are CLIs or TUIs, like being back on curses heyday, Turbo Vision and Clipper.

Various Rust UI projects have been working towards hot-reloadable capabilities, based on the work from the Dioxus team.

IME it's just not really that big of a deal at this point. YMMV, etc.

Re: Rust All Hands 2026 Retrospective

#18

Post by woodruffw »

pjmlp wrote: post #14
woodruffw wrote: post #11

Earlier quoted context omitted.

You probably already know this, but I figure it bears repeating: most people should be running `cargo check` during development, not `cargo build`. The latter is only necessary when you actually need the built binary; the former is sufficient for type- and borrow-checking. (On my local machine, `cargo check` is roughly 2x faster than `cargo build`. It's still slower than hot-reloaded Python, but it's rarely my develo…

A non starter for anything related to graphics or UI development, which is kind of most Rust stuff are CLIs or TUIs, like being back on curses heyday, Turbo Vision and Clipper.

Is it? An immense amount of the world’s graphical software is written for native graphical targets like SwiftUI, where the iteration cycle is similarly bound to build times. It’s certainly painful, but I don’t think it’s a non-starter.

Re: Rust All Hands 2026 Retrospective

#19

Post by 7e »

The multithreaded front end crashes left and right with different features. No testing done. Won’t accept AI PRs so it will stay broken outside of my personal tree forever.

Re: Rust All Hands 2026 Retrospective

#20

Post by Aurornis »

rr808 wrote: post #10
Aurornis wrote: post #4

Earlier quoted context omitted.

> I could also see it slipping into obscurity as LLMs get faster and compile times become a more and more obvious bottleneck on iteration speeds. I’ve worked on some very large Rust projects. The incremental compile times are nowhere near the same order of magnitude of a bottleneck as an LLM turn.

How long does a compile take? Because this was the biggest issue for me. I dont really like Python but the ability to make some changes then run it instantly is wild for me.

Initial compilation and incremental compilation are very different.

Large Rust projects are broken up into modules. If you change one module you don’t have recompile the whole project.

Remember we’re talking about compensation time versus LLM turns in this thread. Even a 10 second incremental compile is orders of magnitude faster than an LLM turn.

Post reply on HN