Don’t get me wrong, I like this aspect of Rust, but I can’t make heads or tails as to whether it helps or if they just have to iterate more to figure out how to make something work. LLMs already do pretty well with a comment “this value can’t be zero” in my experience, so I’m unsure how much value the static typing provides. Maybe it lets you get by with a lower quality model, but that model will likely just spend more tokens on iteration so I can’t discern an obvious win. (shrug) I hope I’m wrong though—if I can have super fast code with the ease of LLM generation then I’m happy.

> Rust reduces memory management to local reasoning (via the borrow checker). This means that it performs well even as context grows, because checks in one function/module are well-encapsulated to that function/module.

I don’t think this is true, right? Changing a single lifetime in a function signature can easily propagate across your entire program. Maybe I’m just a Rust noob, but any time I change a field from owned to borrowed or vice versa I have to propagate that change pretty broadly, which to my mind implies consuming a lot of the context window. Garbage collection (I know, ewww, shame on me, etc) allows for local reasoning in a much more meaningful way however morally impure it may be. :)

All good. It happens in every community, but it seems like Rust has more of these problems where there are N ways to do something and none of them are obvious. Reminds me of Python where everyone swears they have a package manager that will fix all previous problems and then you invest a bunch of time into their suggestion only to find that it introduces half a dozen new glaring problems (e.g., pipenv taking 30 minutes to resolve a lock file for a relatively small project).

> The problems are trivial once you've used Rust for n hours, for some value n.

Heh, I've been taking a real stab at Rust every year since 2014. `n` can be a pretty large value! I'm optimistic that Claude and friends will help me get there though.

> Being forced to emit an Option<T> or Result<T,E> and then having to actually use syntax to get at the goods forces the code to deal with errors the appropriate way, clearly, idiomatically, and typically in a good flow that is amenable to readability and easy refactoring. Other languages without Option, Result, and sum types baked into the language so fundamentally do not have this advantage.

Honestly I use Go as my daily driver these days and while I wish it had sum types for error handling, it's really not a problem. It's more aesthetics than anything, and LLMs do just fine with managing errors in Go. There may be other advantages for LLMs with respect to Rust's rigorous type system, but I could easily see it going the other way as well (additional constraints for the LLM to focus on, taking more of its context budget that could go to the fundamental product constraints). I really don't know what the right answer is here--I suppose time will tell.