Rust is great. However in an agentic world go will win. Look no further than incremental build times. This, combined with high token costs mean that for a given application it simply will cost more to to write it in Rust than Go.

This can easily be justified for many usecases, but for your vanilla crud app, do you really need Rust?

Per the article, you are getting 20-50% better more performance with Rust. Not worth it unless your team was already fluent in Rust. Now consider a scenario where your team uses AI exclusively to code, now you are spending more time and tokens waiting around to consume large rust builds. As far as I know this is an inherent property of Rust to have its safety guarantees.

I think Rust makes sense for a lot of cases, but for a small web service, overkill and unnecessary imho. If someone ported their crud app from Go to Rust I would question their priorities.

Again I am speaking more in terms of software engineering economics than anything else. Yes, I know in a perfect world Rust binaries are smaller, performance is better and code more “correct”, but the world is hardly perfect. People have to push code quickly, iterate quickly. Teams have churn, Rust, frankly is alien for many, etc.

▲

natsucks 2 hours ago | parent | next [-]

Because the agentic world involves the generation of so much code that gets harder to review, I would think the compile-time guarantees of Rust would make it a better option.

▲

amazingamazing 2 hours ago | parent [-]

This is true if the token budget and time are not taken into account. In practice though, waiting minutes instead of seconds per build multiplied by prompt and again by change adds up very fast.

▲

nicoburns 2 hours ago | parent | next [-]

Incremental Rust builds are almost never minutes (on recentish hardware)

A quick measurement on my web browser project with almost 600 dependencies:

- A clean "cargo check" was 31s

- An incremental "cargo check" with a meaningful change was 1.5s

Building is a little slower:

- A clean "cargo build" was 56.01s

- An incremental "cargo build" was 4s

But I find that LLMs are mostly calling "check" on Rust code.

---

That's on an Apple M1 Pro. The latest M4/M5 machines as ~twice as fast.

▲

amazingamazing 2 hours ago | parent [-]

I mean i wouldnt call a 100% a little slower wrt check vs build. In any case, the more you change the longer the incremental check or build will take.

▲

nicoburns 2 hours ago | parent | next [-]

Sure, but when we're talking single-digit seconds it feels not that significant regardless?

	▲	amazingamazing an hour ago \| parent [-]
		My point is that it isn't necessarily that fast. It is relative to the amount of changes and where they were made. For a fair comparison you would also have to present the worst case incremental build time which approaches the full build time (this goes for Go too), which per your own example is nearly a minute for rust.

▲

J_Shelby_J 2 hours ago | parent | prev [-]

1.5s for a massive project, on a laptop,like the OP said is still barely anything in the context of agentic coding. It’s less than a single percentage point of the total time in the loop, even if the agent has to compile multiple times.

This is cope.

I do give you that rust is more verbose and thus more token heavy. However that verbosity is meaningful and the LLM would have to spend tokens thinking about the code to understand less verbose languages. So I’d consider that a wash - in some cases it hurts and in some it helps.

▲

amazingamazing an hour ago | parent [-]

We don’t know how massive the project is, but in any case building and immediately building again of course will be fast. How fast is it if all files have a single line changed, for example refactoring a log message?

Not to mention we haven't even gotten to discussing tests.

	▲	nicoburns 16 minutes ago \| parent [-]
		> in any case building and immediately building again of course will be fast FWIW, the compile time test above was done comparing consecutive commits. Which in this case happened to have ~3-4 lines changed.

▲

natsucks 2 hours ago | parent | prev [-]

When everyone is armed with Mythos-like hacking ability, it's hard for me to imagine people wouldn't make the tradeoff of security over price.

	▲	2 hours ago \| parent [-]
		[deleted]

▲

nicoburns 2 hours ago | parent | prev | next [-]

> As far as I know this is an inherent property of Rust to have its safety guarantees.

From what I've seen, Rust's strictness is actually a huge win for LLMs, as they get much better feedback on what's wrong with the code. Things like null checking that would be a runtime error in Go are implied by the types / evident in the syntax in Rust.

▲

crabmusket 2 hours ago | parent | prev | next [-]

> spending more time and tokens waiting around

Can you clarify how you're spending tokens on waiting? My understanding is that the LLM isn't actually necessarily doing anything while a build runs. The whole process end to end may take longer for sure (ignoring things like the compiler catching more errors, that's really hard to factor in) but how does that correlate to more tokens?

▲

amazingamazing 2 hours ago | parent [-]

> The whole process end to end may take longer for sure (ignoring things like the compiler catching more errors, that's really hard to factor in) but how does that correlate to more tokens?

This. rust emits more information both in its output and the syntax itself more complicated requires more tokens.

▲

kajman 2 hours ago | parent [-]

The cost of verbose compiler output surely cannot compare to the cost of shipping bugs that would've been caught at build time.

▲

amazingamazing 2 hours ago | parent [-]

Indeed, but is it the case that all bugs you have are those in which would be caught by the compiler? It’s not like rust code inherently is bug free.

	▲	kajman 2 hours ago \| parent [-]
		Of course, there's plenty of bugs in Rust code still. The fact that safe Rust should be able to statically guarantee entire classes of bugs like data races are impossible is a huge deal, though. We're totally free to have different values when it comes to what matters, but compile time and a verbose toolchain are not high costs for that, to me. I personally would first consider other things like the cognitive overhead of learning to work with the borrow checker.

▲

johnfn 2 hours ago | parent | prev | next [-]

Can you explain a bit about why token costs would favor Go and not Rust?

	▲	amazingamazing 2 hours ago \| parent [-]
		Go is more verbose, but Rust have more complex syntax which in practice require more tokens. The big thing though is because builds are slower, you will end up waiting longer as tests are modified, rebuilt and run. This difference piles up fast.

▲

the__alchemist 2 hours ago | parent | prev | next [-]

> However in an agentic world go will win

This is Silicon Valley fantasy.

▲

OtomotO 2 hours ago | parent | prev [-]

It's a good thing then, that the AI hype is dying outside of ycombinator, the silicon valley and the US

▲

amarant 2 hours ago | parent | next [-]

As someone with a background of consulting in the Stockholm based gaming industry for the last decade+, I have to respectfully disagree. Nearly everyone I know is very much on the hype train. And for good reason too! The capabilities are undeniable!

▲

OtomotO 2 hours ago | parent [-]

As is the hype.

You know, shovels are useful, they are just more useful to the shovel manufacturer than the gold diggers.

But in the end it's a cool tool that made it way easier to dig holes and tend to your garden!

	▲	amarant an hour ago \| parent [-]
		Oh yeah, definitely. There has indeed been a lot of hype overestimating the capabilities. People thinking you can one-shot big complex applications with a few paragraphs of descriptions for example. There has also been a lot of anti-hype, or whatever you call it when people seem to believe LLMs don't provide any value for software Dev, basically writing all capabilities off as pure hype. The truth of course is somewhere in the middle. It's difficult to tell what people mean when they say hype sometimes.

▲

jdw64 2 hours ago | parent | prev [-]

[dead]