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

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

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

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

reply
Sure, but when we're talking single-digit seconds it feels not that significant regardless?
reply
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.
reply
> 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)

The worst case that would approach a non-incremental build time would be if you were editing a leaf crate. But in almost all cases the leaf crates are 3rd-party dependencies that you would never edit directly.

A real-world worst case is probably more like ~10-20% of an non-incremental builds.

reply
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.
reply
deleted
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?

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

reply
The cost of verbose compiler output surely cannot compare to the cost of shipping bugs that would've been caught at build time.
reply
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.
reply
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.
reply
Your agent doesn't know how to use grep?
reply
> 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.

reply
Can you explain a bit about why token costs would favor Go and not Rust?
reply
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.

reply
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

reply
> However in an agentic world go will win

This is Silicon Valley fantasy.

reply
It's a good thing then, that the AI hype is dying outside of ycombinator, the silicon valley and the US
reply
Surely
reply
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!
reply
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!

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

reply
So you're not using a shovel to maintain your garden?!
reply
I am, but I am no part of any shovel cult.
reply
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.
reply
[dead]
reply
lol no
reply