Live data from Hacker News

Rust All Hands 2026 Retrospective

blog.rust-lang.org

1–10 of 63 posts

Re: Rust All Hands 2026 Retrospective

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

Re: Rust All Hands 2026 Retrospective

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

Re: Rust All Hands 2026 Retrospective

#5
post #4
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 don't doubt this is true for many projects currently (though it's not for a bevy project I'm working on).

Have you tried Cerebras, Groq, Taalas, et al? It was a paradigm shift for me.

Re: Rust All Hands 2026 Retrospective

#6
post #5
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 don't doubt this is true for many projects currently (though it's not for a bevy project I'm working on). Have you tried Cerebras, Groq, Taalas, et al? It was a paradigm shift for me.

I have, but even with the high token generation speed, incremental Rust compile times were not a bottleneck.

I was disagreeing with the concept that incremental compile times could be a bottleneck. LLMs are even better at doing large swaths of work at once and having it compile first or second try than a human.

Re: Rust All Hands 2026 Retrospective

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

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.

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.

Re: Rust All Hands 2026 Retrospective

#8
post #6
post #5

Earlier quoted context omitted.

I don't doubt this is true for many projects currently (though it's not for a bevy project I'm working on). Have you tried Cerebras, Groq, Taalas, et al? It was a paradigm shift for me.

I have, but even with the high token generation speed, incremental Rust compile times were not a bottleneck. I was disagreeing with the concept that incremental compile times could be a bottleneck. LLMs are even better at doing large swaths of work at once and having it compile first or second try than a human.

Oh are you saying the human remains the bottleneck?

Re: Rust All Hands 2026 Retrospective

#9
post #6
post #5

Earlier quoted context omitted.

I don't doubt this is true for many projects currently (though it's not for a bevy project I'm working on). Have you tried Cerebras, Groq, Taalas, et al? It was a paradigm shift for me.

I have, but even with the high token generation speed, incremental Rust compile times were not a bottleneck. I was disagreeing with the concept that incremental compile times could be a bottleneck. LLMs are even better at doing large swaths of work at once and having it compile first or second try than a human.

[dead]

Re: Rust All Hands 2026 Retrospective

#10
post #4
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.

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.
Post reply on HN