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

21–30 of 63 posts

Re: Rust All Hands 2026 Retrospective

#21

Post by insanitybit »

Aurornis wrote: post #4
apitman wrote: post #3

I could see Rust becoming the language for coding agents, because it has such solid guardrails built in. 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 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.

Re: Rust All Hands 2026 Retrospective

#22

Post by kolanos »

fishfasell wrote: post #2

Rust is such an incredible language. I really hope it becomes more widely adopted in the future.

Agree. I've been delving deep into Rust for some personal projects, and while there are some sharp edges (that likely won't go away) the tooling, ecosystem and general ergonomics more than make up for it. Hoping I'm not in the minority of relative newcomers and that the language continues to thrive.

Re: Rust All Hands 2026 Retrospective

#23

Post by majormajor »

Aurornis wrote: post #20
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.

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.

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

This entirely depends on (a) what a step/prompt/turn is trying to do and (b) tooling and rate limiting and various other aspects of your model and/or access to it.

If you have high rate limits and aren't using an Opus-or-larger sized model you can get a LOT of changes done in 10 seconds.

And this is especially true for "oh not all the tests are passing yet, let me change..." iterations where the change attempts are often low-single-digit seconds.

Re: Rust All Hands 2026 Retrospective

#24

Post by ReactiveJelly »

apitman wrote: post #3

I could see Rust becoming the language for coding agents, because it has such solid guardrails built in. 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.

Just run Rust compiles in the cloud.

Really, if you're using a SaaSS LLM like Claude or Copilot or ChatGPT, which already sends all your code to someone else's computer to run on a beefy GPU, they should just send the Rust code to the same datacenter and send you back a binary.

Little shocked that Anthropic isn't offering this.

Rust compile speeds will matter less and less as hardware gets faster.

Re: Rust All Hands 2026 Retrospective

#25

Post by MrBuddyCasino »

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…

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

Co-signed.

Re: Rust All Hands 2026 Retrospective

#26

Post by Animats »

kolanos wrote: post #22
fishfasell wrote: post #2

Rust is such an incredible language. I really hope it becomes more widely adopted in the future.

Agree. I've been delving deep into Rust for some personal projects, and while there are some sharp edges (that likely won't go away) the tooling, ecosystem and general ergonomics more than make up for it. Hoping I'm not in the minority of relative newcomers and that the language continues to thrive.

Delve alert!

Re: Rust All Hands 2026 Retrospective

#27

Post by Animats »

"The moderation panel provided a safe space for Rust moderators to discuss the challenges they face, with support from Q (head moderator of Hachyderm). The Project culture discussion examined sources of disempowerment for maintainers and contributors, and ways to address them. The sessions on Project Goals, north stars, and funding looked at improving how the Project coordinates and communicates work."

Anonymous moderators? That's scary.

Re: Rust All Hands 2026 Retrospective

#28

Post by panstromek »

Animats wrote: post #27

"The moderation panel provided a safe space for Rust moderators to discuss the challenges they face, with support from Q (head moderator of Hachyderm). The Project culture discussion examined sources of disempowerment for maintainers and contributors, and ways to address them. The sessions on Project Goals, north stars, and funding looked at improving how the Project coordinates and communicates work." Anonymous mode…

Rust moderators are not anonymous.

Re: Rust All Hands 2026 Retrospective

#29

Post by est31 »

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…

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.

Re: Rust All Hands 2026 Retrospective

#30

Post by woodruffw »

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, I mean more for the iteration half -- YMMV, but I find that I make the LLMs most productive when I have them design the typestates first, ensure they compile, and then work on tests after that (rather than stacking tests through the process).
Post reply on HN