[theLiminator]

That's the power of a strong test suite. LLMs excel when you have verifiable rewards. I imagine we'll get a lot more rewritten in rust projects in the future. Rust is also an ideal target for such rewrites as it offers a lot of verification (via its type system) and is low overhead with zero-gc. There's less and less reason to use GC'd languages in the agentic coding era.

I think Rust is a locally optimal target for LLM coding, we might see a better language in the future, but I think Rust will dominate for quite some time.

[lifthrasiir]

> There's less and less reason to use GC'd languages in the agentic coding era.

Faster iteration, maybe? Rust's safety guarantee isn't exactly free (while still being very excellent) and does affect iteration time. I have a private project (>300K LoC) that has been translated from Python to TypeScript and the reason we couldn't use Rust was definitely the iteration time.

[talloaktrees]

I like using Odin with LLMs for this. it's a simple statically typed language with no GC and very fast compile

[jjice]

But then you have to deal with manual memory management. Not a bad thing, but it's the big win you get from GC languages and Rust.

[gpm]

Eh... rust's safety isn't free, but not having it and wasting time on "oh I forgot to change this call site" also isn't free. On the whole I'd say the safety assists in iteration time.

What costs rust in iteration time in my opinion is the low level (by default) nature of it. There's a faster-to-iterate language that has yet to be created which is rust but we sacrifice performance (and memory fiddling ergonomics for the odd person who does that) so we don't have to worry about things like whether a variable is stack or heap allocated. Which is in the direction of a GCed language but retains the mutable-xor-aliasable semantics.

Between rust and current GCed languages though... I guess I agree with "maybe" in both directions.

[lifthrasiir]

The project in question needed lots of near-instant human judgements and the iteration loop had to be extremely tight. Maybe Rust should be reconsidered once it gets stabilized enough, but not right now.

[theLiminator]

Maybe something like Hylo? But personally I don't see anything displacing rust for the next few years, as I think there's enough rust in the training data for it to be the best "serious" language for agentic systems-level development.

It's really the only systems language in its exact niche.

[gpm]

I'm not very familiar with Hylo, but I think it's in the opposite direction from rust than what I'm suggesting.

I'm suggesting a language where there's no difference between Box<u32> and u32. &Vec<u8> and &[u8] are the same thing. I don't need to write Box::new(...) around my closures to pass them to functions that take a function pointer. This comes with overhead, but in exchange we get simpler less verbose code. I.e. a language that isn't systems level, and isn't particularly machine-empathetic. But still has all the lightweight-formal-methods power of rust with lifetimes and mutable vs shared borrows (and thus references to references) and so on.

My impression of Hylo is that it's purpose is to be a similarly low level systems language to rust, just with a less complicated, and as a consequence less expressive, lightweight formal methods system for proving correctness.

I agree I don't expect rust to be displaced anytime soon. It creates a lot of time to create a good compiler, and a lot more to create the ecosystem of code, tools, and community around it.