“Rust is better. It just is.”

That is the top-ranked comment among the 317 on Hacker News, aimed at Google’s official declaration yesterday (August 11): Go is the ideal language for AI-assisted software engineering.

The two sides fought all day. Our judgment: both are fighting the wrong fight — they are counting the cost of writing code, while the money you actually spend goes to reviewing it.

This article does not take sides. It gives you three things: the ledger as we recompute it, the language picks that follow from it, and a controlled experiment you can run tonight to test our claim.

quote-card

Our take: Google got half of it right — and did the math in the wrong place

Position first. What follows is our opinion; the evidence sits in the next two sections.

The half Google got right: the metric for a language’s productivity really has changed. When a coding agent emits hundreds of syntactically valid lines in seconds, typing speed stops mattering; reviewing, verifying, and maintaining are what remain. The bottleneck moved from generation to verification. That frame is the one genuinely new idea in Google’s post.

The half it got wrong: Google’s conclusion from that frame is “Go is ideal.” Follow the verification-cost math all the way down and you cannot land there. Verification cost has three components, and each has a different winner:

Verification-cost factorWinnerWhy
Error classes killed at compile timeRustBorrow checker plus exhaustive matching — whole categories never reach runtime
Cost of one agent self-correction loopGoFast compiles, direct errors, one built-in toolchain: the cheapest generate-compile-fix cycle
Human review loadGoOne idiom, uniform style — cheap for reviewers and for the model

The three-factor verification-cost ledger: compile-time elimination favors Rust; loop cost and review load favor Go

So our conclusion: there is no “ideal language for AI coding,” but verification cost is a real ledger. Whichever component dominates your project picks your language. That is the right question to ask.

One honest note for our Rust readers: this site has published dozens of Rust tutorials, but the first row of the ledger carries a risk — if LLMs do not make the human mistakes the borrow checker guards against, part of what it protects shrinks. Someone in the HN thread made that point for us; we quote it below. The ledger of language advantages is due for a recount.

What Google actually said (and what it left unsaid)

The post is co-authored by Cameron Balahan (Group Product Manager for Go) and Richard Seroter (Chief Evangelist at Google Cloud). Stripped of advocacy, it makes four arguments — which we re-file under our ledger:

  1. A built-in end-to-end toolchain (files under: loop cost). gofmt, tests, dependency management, govulncheck all ship standard. The post itself admits the key fact: an agent refactoring iteratively without external validation degrades fast — errors compound, the context window gets polluted, tokens burn. The built-in toolchain is a cheap validator for the agent.
  2. One uniform style (files under: review load). gofmt enforces a single format; “you can never tell who wrote the code”; hallucinated API calls are easier to catch by eye.
  3. Static types plus fast compiles (touches two rows). Type errors are rejected at compile time; compile speed is claimed to be “orders of magnitude faster than Java, C#, Rust” — note, that is rhetoric, not a benchmark.
  4. The compatibility promise and static binaries (long-term maintenance). Go 1.0 code still compiles; “there will never be a Go 2.0”; zero-dependency single binaries; one-command cross-compilation.

What it leaves unsaid: three of those four arguments are served even better by a stronger type system — Rust kills far more at compile time than Go does. Google never engages that point. HN did it for them.

The six comments out of 317 actually worth reading

The thread split into four camps, but most of it is noise. Only six comments add real weight to our ledger (every quote verified against the original thread):

For “compile-time elimination matters” — @Havoc:

The whole fussy compiler & errors surface at compile time seems IDEAL for LLMs for me. Hammering compile with tokens is a way better strategy than trying to deduce where stuff may fail at run time and try to catch it via tests. Tokens are cheap, surprises at runtime are not.

That lands squarely on row one of our ledger.

For “loop cost matters” — @throwitaway222’s field report: “Fewest glitches for AI generated code… Doesn’t seem to burn tokens as much as other languages.” Row two.

The most valuable warning for Rust fans — @YuechenLi: LLMs do not make the human mistakes the borrow checker was designed to prevent, so they “spend more time fighting Rust’s infrastructure than writing code.” If this holds, row one’s weight drops. That is exactly why we called it a risk rather than a verdict — nobody has systematically tested it, and you can test it yourself with the experiment below.

Go’s boundary, drawn by a Go advocate — @kstenerud praises the tooling (forbidigo for file-access restriction, the coverage tool’s nocover marker, mature lints) and then concedes: “Rust is better for error paths because you’re not allowed to ignore them.”

The sharpest jab at motive — @tpoacher: ““Oreo cookies are the tastiest cookies currently in the market!” ~ Oreo cookie company.” The authors are Go’s product manager and Google Cloud’s chief evangelist; the stance is printed on the badge. Keep that in mind when reading the original.

The thread’s epilogue — @pianopatrick: “Seems to me the ideal language for AI has not been created yet.” And @WalterGR’s discovery: the same debate ran five months ago, 203 points and 304 comments. This fight is cyclical — next time you see “language X is best for AI,” just apply our three-factor ledger.

Our picks, by verification cost

Once you count verification cost, the decision rule is straightforward:

  • Internal tools, network services, CLIs, anything the standard library covers — pick Go. Fast loops, fewer tokens, low team review load. HN’s positive field reports cluster exactly in this category.
  • Performance-sensitive, correctness-sensitive systems where error paths must not fail — pick Rust. The most errors eliminated at compile time, at the price of a slower, more token-hungry agent loop.
  • Prototypes, scripts, data work — Python is likely still the most token-efficient; @mg cites Dan Luu’s pl-tokens test in the thread. We reserve judgment on the strength of that evidence, but the direction is reasonable.
  • In every case — pick the language you least mind reviewing, not the one that is most fun to write. In the AI era, writing is no longer your job.

A controlled experiment you can run tonight

You do not have to take our word for the ledger. Test it tonight:

  1. Pick a moderately complex requirement you know well — e.g. “implement a concurrent task queue with rate limiting, priorities, and graceful shutdown.”
  2. Same agent, same model, same prompt — once asking for Go, once for Rust.
  3. Record four numbers: rounds of dialogue to a clean build, total tokens consumed, your review minutes, and first-pass test rate.
  4. If you can, run each three times and take medians; single runs are noisy.

The four metrics to record in the experiment: compile rounds, token cost, review minutes, test pass rate

Know the boundary: this only answers “for my project, my agent, my model, which language costs less to verify.” It proves nothing universal. Anyone who waves a single run to declare total victory is repeating the mistake of Google’s post.

FAQ

How should you pick a language in the AI-coding era?

Our view: by verification cost — how many error classes the compiler kills, what one agent self-correction loop costs, and how heavy human review feels. Pick whichever language makes verification cheapest for your project.

So Go or Rust?

Follow where your verification cost lives: internal tools, network services, anything the standard library covers — Go, for fast loops and fewer tokens. Performance-sensitive systems where error paths must not fail — Rust, for the most errors caught at compile time.

Why does Google say Go fits AI coding?

Four reasons: a built-in end-to-end toolchain; uniform style that eases review; static typing plus fast compiles for a cheap self-correction loop; and the compatibility promise plus static binaries. What it does not say: pushed to its conclusion, that logic favors even stronger type systems.

How do I verify which language fits my project?

Same agent, same prompt; generate a Go and a Rust implementation; record rounds to a clean build, tokens, review minutes, and first-pass test rate; run three times and take medians. Single runs are noisy, and the conclusion only holds for your context.

Sources

If language choice in the AI era interests you, these pieces may too:

Which camp are you in

This debate compresses into three positions. Pick yours:

  • A. Team Go: fast builds, one unified toolchain, one idiom — cheap for AI to generate and for humans to review
  • B. Team Rust: the stricter the compiler, the more reliable the AI’s self-correction loop, and the fewer runtime surprises
  • C. Neither matters: by our ledger, you first locate where your verification cost lives — then talk languages

Tell us your pick and why in the comments. We especially want to hear from people who have actually run AI-generated Go or Rust in production — one real data point from you is worth ten paragraphs of argument from either side.

If you cannot decide, run the experiment above tonight and post your four numbers (rounds / tokens / review minutes / test pass rate) in the comments. Next week we will compile readers’ results into a follow-up.

If this ledger helps your team, forward it to the colleague still stuck on “which language for the next project.”

About 「全栈之巅-梦兽编程」 (Rexai Programming): deep content on AI programming and full-stack engineering. Follow our WeChat official account 「梦兽编程」 for more Rust and AI programming tutorials.