Live data from Hacker News

Rust All Hands 2026 Retrospective

blog.rust-lang.org

41–50 of 63 posts

Re: Rust All Hands 2026 Retrospective

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

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

I'm quite often working in a Jupyter notebook where the imported modules are reloaded. I can have x in memory, change method y of X and then call x.y() and get the new definition.

It feels almost criminal that it works, but it's quite nice.

Re: Rust All Hands 2026 Retrospective

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

Compile times are being worked on: https://rust-lang.github.io/rust-project-goals/2026/roadmap-...

Re: Rust All Hands 2026 Retrospective

#43
post #40

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?

Many would agree with you. For me, the main selling point is the overall pro/con balance of the language. It's just a nice language overall, especially when you place it only with other languages capable of running fast and low-level code.

I don't see rust and think "I have to write using Safe abstractions, traits etc because they're the rust way". There are many reasons to choose (or not depending on your preferences) rust beyond that. For example: "I am choosing rust here because Python's slow and its module system is a mess" or, "I'm choosing Rust here because its enum and struct syntax is fantastic" or "I'm choosing rust here because I can install the toolchain with a single command, and compile + flash with another without getting frustrated". Or "I'm choosing rust here because it makes it easy to architect complicated programs, and has really nice copmile-time error messages".

Stated another way: > Why use Rust over another language if you’re not using its main features?

It depends on the use case and what language you're comparing it to.

Re: Rust All Hands 2026 Retrospective

#44
post #39

Earlier quoted context omitted.

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.

Sure, I don't disagree. It's just not clear to me that developers actually index that heavily on hot reloading to begin with.

Re: Rust All Hands 2026 Retrospective

#45

Earlier quoted context omitted.

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, per…

I'm on an M4 Macbook. I use Codex, gpt, and Claude in various configurations, including Fable, xhigh, medium, high, ultracode, etc.

Re: Rust All Hands 2026 Retrospective

#46
post #34

Earlier quoted context omitted.

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?

M2 air. Pay to play brotha

Re: Rust All Hands 2026 Retrospective

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

> I think it's the best language for LLMs

because of the type system? i work in ~dynamically typed language and the llms almost never make a type error.

Re: Rust All Hands 2026 Retrospective

#48

Earlier quoted context omitted.

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.

> I think it's the best language for LLMs because of the type system? i work in ~dynamically typed language and the llms almost never make a type error.

The type system is great and gives extremely fast feedback. The performance wins are also incredible, it just feels like you're throwing 100s of megabytes of RAM away and 10x latency when you don't choose rust now, and for little reason. The testing tooling is really solid - property testing, fuzzing, mutation testing, etc, is all easy to use. Code structure with nice abstractions that don't become spaghetti is nice (traits, enums, etc). Static binaries as a production artifact is really nice. Supply chain story is pretty solid with cargo-vet.

It's hard to come up with anything where I think Rust isn't "best in class" other than compile times.

Re: Rust All Hands 2026 Retrospective

#49

Earlier quoted context omitted.

> I think it's the best language for LLMs because of the type system? i work in ~dynamically typed language and the llms almost never make a type error.

The type system is great and gives extremely fast feedback. The performance wins are also incredible, it just feels like you're throwing 100s of megabytes of RAM away and 10x latency when you don't choose rust now, and for little reason. The testing tooling is really solid - property testing, fuzzing, mutation testing, etc, is all easy to use. Code structure with nice abstractions that don't become spaghetti is nice…

i think rusts composition is problematic. you can have two abstractions that if you mix them the outcomes are not what you expect unless you have a deep understanding of the details, (e.g. clone/iter) and rust is all about hiding details from you.

Re: Rust All Hands 2026 Retrospective

#50

Earlier quoted context omitted.

The type system is great and gives extremely fast feedback. The performance wins are also incredible, it just feels like you're throwing 100s of megabytes of RAM away and 10x latency when you don't choose rust now, and for little reason. The testing tooling is really solid - property testing, fuzzing, mutation testing, etc, is all easy to use. Code structure with nice abstractions that don't become spaghetti is nice…

i think rusts composition is problematic. you can have two abstractions that if you mix them the outcomes are not what you expect unless you have a deep understanding of the details, (e.g. clone/iter) and rust is all about hiding details from you.

I really couldn't disagree more. Rust doesn't hide those details at all. APIs tend to be extremely explicit. I have never run into the issue you're describing in rust, I have run into it far more in other languages where mutability and sharing are implicit.
Post reply on HN