Comment by amazingamazing
21 hours ago
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.
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.
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.
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.
7 replies →
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.
1 reply →
> 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?
> 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.
The cost of verbose compiler output surely cannot compare to the cost of shipping bugs that would've been caught at build time.
2 replies →
Your agent doesn't know how to use grep?
> 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.
Can you explain a bit about why token costs would favor Go and not Rust?
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.
Waiting longer for tests / builds doesn't have effect on token usage..
Rust's compile time is longer because the compiler does much more. And therefore the binaries are often smaller, start and run faster than Go
> However in an agentic world go will win
This is Silicon Valley fantasy.
lol no
It's a good thing then, that the AI hype is dying outside of ycombinator, the silicon valley and the US
Surely
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!
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!
3 replies →
The capabilities are very much deniable. They do not exist. Using LLMs to write code is either going to make you slower (as you have to review all that code), or make your software suck (because they write bad code and you're choosing to not review it). There's no actual win to be had here.
[dead]