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

31–40 of 63 posts

Re: Rust All Hands 2026 Retrospective

#31

Post by slopinthebag »

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.

My rust compiles in the time it takes to switch from my editor to my browser to see the changes incremental recompiles are fast enough imo. Dioxus has hot reloading if you want to go faster and Bevy uses it for hot reloading as well.

Re: Rust All Hands 2026 Retrospective

#32

Post by pjmlp »

woodruffw wrote: post #18
pjmlp wrote: post #14

Earlier quoted context omitted.

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.

SwiftUI has an incremental compiler with interactive workflows.

Re: Rust All Hands 2026 Retrospective

#33

Post by pjmlp »

Klonoar wrote: post #17
pjmlp wrote: post #14

Earlier quoted context omitted.

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.

I am aware, still far away from what something like C++ Builder was already offering in the 1990's, let alone other more modern alternatives.

Re: Rust All Hands 2026 Retrospective

#34

Post by pjmlp »

slopinthebag wrote: post #31
pjmlp wrote: post #14

Earlier quoted context omitted.

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.

My rust compiles in the time it takes to switch from my editor to my browser to see the changes incremental recompiles are fast enough imo. Dioxus has hot reloading if you want to go faster and Bevy uses it for hot reloading as well.

With a beefy desktop, or some Apple wonder CPU, right?

Re: Rust All Hands 2026 Retrospective

#35

Post by J_Shelby_J »

est31 wrote: post #29
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…

cargo check is useful to verify the code compiles (it's extremely rare to have compilation errors that survive cargo check). But cargo build is required if you want to actually try out the code you wrote, e.g. in order to run a test that you or the LLM wrote.

Yeah but like, tests encode behavior… sometimes I go all day without running a test. Sometimes multiple days. I’ve been using unit tests less and debug asserts more and more now days anyways. Encoding behavior as close the relevant code as possible. And using types and type state to minimize invariants. Idk, but it seems like such a smell when my coding agent drops 10 unit tests for a 300 LoC module. It means it did a bad job of writing the code in the first place.

Anyways, if the code compiles, but the behavior is wrong, a test might be useful. But so is reading the code… so I’m skeptical of rerunning tests constantly.

Re: Rust All Hands 2026 Retrospective

#36

Post by embedding-shape »

insanitybit wrote: post #21
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.

I use LLMs and rust and compile times are absolutely a significant area of degradation. I love rust, I think it's the best language for LLMs, but the biggest win Rust could get for agentic development is to speed up the compiler.

Neither of you talk about what sort of machine you're sitting on. Back when I used a netbook, I'd agree with you, for developing quick off programs, the compile times are horrible. But as someone on a workstation now, compilation times are the least of my problems, and disk space is more of a concern for me.

You also don't share what LLM you use, some of them reason a lot, some of them nothing, some a bit. Again, personally I use LLMs with their maximum reasoning always, trading quality for speed/waiting every single time, and even compiling the Linux kernel would be faster than most LLM responses I get nowadays, for me, on a workstation.

Re: Rust All Hands 2026 Retrospective

#37

Post by embedding-shape »

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.

> I dont really like Python but the ability to make some changes then run it instantly is wild for me.

You'll love Clojure, gets you even closer; you can make changes while your program is running, by changing source code then applying just that function you changed, while your editor is connected to your program and can show what the new results are.

Re: Rust All Hands 2026 Retrospective

#38

Post by woodruffw »

pjmlp wrote: post #32
woodruffw wrote: post #18

Earlier quoted context omitted.

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.

SwiftUI has an incremental compiler with interactive workflows.

Rust has an incremental compiler. And TMU SwiftUI’s live preview is essentially a very rough approximation of what the actual build would produce; it’s not a suitable replacement for a real build when developing a non-trivial UI.

Re: Rust All Hands 2026 Retrospective

#39

Post by pjmlp »

woodruffw wrote: post #38
pjmlp wrote: post #32

Earlier quoted context omitted.

SwiftUI has an incremental compiler with interactive workflows.

Rust has an incremental compiler. And TMU SwiftUI’s live preview is essentially a very rough approximation of what the actual build would produce; it’s not a suitable replacement for a real build when developing a non-trivial UI.

The experiences still fails short of XCode or Playground, hence why Slint has its own scripting language.

Re: Rust All Hands 2026 Retrospective

#40

Post by dabinat »

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…

> ownership, generics, safety, Async

Aren’t they the main selling points of Rust? Why use Rust over another language if you’re not using its main features?

Post reply on HN