There Is No Best Language for Coding Agents

For about a year, a tidy piece of folk wisdom has been circulating: if AI agents are writing your code, you should pick a terse language, because tokens are money. Dynamic and functional languages supposedly cost half to a third as much as Rust or C++, and array languages like J looked like the ultimate cheat code. Dan Luu just spent months building serious evals to test that claim, and his results are blunt: the effect mostly evaporates the moment agents do real work.

That matters because the original claim wasn't fringe. It's cited widely enough that LLM-backed search engines now repeat it as settled fact — which is exactly how folk wisdom calcifies into architecture decisions.

Where the terse-language theory came from

The strongest version of the claim traces to Martin Alderson's January analysis of Rosetta Code solutions across 19 languages, tokenized with a GPT-4 tokenizer. The numbers were striking: a 2.6x spread between Clojure (~109 tokens per task) and C (~283), with J averaging around 70. Haskell and F# punched above their static-typed weight thanks to type inference. The inference people drew: context windows are scarce, output tokens are billed, so terse languages should make agents cheaper and maybe better.

The problem is what was being measured. Rosetta Code tasks are a few hundred tokens of code — FizzBuzz-adjacent exercises where boilerplate dominates. In a 20-line program, C's includes and type declarations are a huge fraction of the total. In a 5,000-line decoder, they're noise. Extrapolating from one to the other is like benchmarking database engines on a ten-row table.

What happens on real tasks

Luu's evals are the kind of thing almost nobody bothers to build. In one, agents got the zstd RFC and errata and had to implement a working zstd decoder from the spec, with no tests to lean on. In another, they implemented Pandoc functionality test-driven against a holdout suite. Both ran across a spread of dynamic and static languages, at two effort levels, on Claude and GPT models. He pre-registered his predictions, which is more epistemic hygiene than this debate has ever seen.

The headline result: no language class dominates. At medium effort on the zstd task, dynamic languages clustered slightly ahead on cost-versus-correctness. At high effort, results were mixed, with static languages doing as well or better. On Pandoc, neither type won. The dramatic 2–3x ratios from the toy benchmarks simply don't survive contact with tasks where most tokens go to logic, debugging, and iteration rather than syntax.

The obscure-language dream fared worse. Luu gave 98% odds that J-style "dense language supremacy" wouldn't hold up, and it didn't. What he found instead was a weak-to-moderate correlation with popularity: mainstream languages tended to produce solutions that were both more correct and cheaper. Individual languages showed wild task-to-task variance — Clojure face-planted on zstd's byte-level manipulation (36 of 40 medium-effort runs failed) and then performed genuinely well on Pandoc — which is exactly why he refuses to crown any single winner from two tasks.

An independent line of evidence points the same way. A July arXiv paper from Zixuan Wu, Carolyn Jane Anderson, and Arjun Guha ran about 2,000 agent sessions across Python, Java, Rust, and OCaml and found agents burned 1.28–1.69x more tokens in OCaml than Python — not because OCaml is verbose (it isn't), but because agents flail in lower-resource languages: repeated non-compiling attempts, syntax struggles, even prototyping in Python and translating afterward. Token cost, it turns out, is dominated by how much the model has to iterate, not how terse the final file is. That mechanism predicts exactly what Luu observed: training-data depth beats syntax density.

The part that should worry you more

The most valuable section of Luu's post isn't the results — it's the confession. While building the zstd eval he found and fixed over 100 bugs in his own harness: broken build specs that quietly handicapped specific languages, a test where both branches returned "pass," toolchain restrictions nobody intended. His conclusion is that if you find a bug every time you look, you haven't found the last one. And a third planned eval — implementing a board game with genuinely ambiguous rules — scored roughly zero across every language and model, a reminder that spec complexity swamps language choice entirely.

Hold that against the ecosystem producing agent-language advice. If a careful, adversarial-to-himself engineer ships 100+ harness bugs on one task, what's the defect rate in the blog posts confidently ranking languages off a handful of runs? Most of what you've read on this topic is built on evals flimsier than the ones Luu is apologizing for.

What to actually do with this

If you were considering an exotic or ultra-terse language to save agent tokens: don't. The savings are a mirage at real scale, and you pay for them twice — once in the model's weaker command of the language, and again in your own ability to review what it writes. Agent-generated code you can't fluently audit is a liability, and your reviewers are much more likely to be fluent in Go than in J.

If you're already on Python, TypeScript, Go, Rust, or Java: language choice is close to a non-issue, so stop relitigating it. The popularity correlation says mainstream is a mild tailwind; nothing says any mainstream language is a meaningful edge over another. The variables that actually move agent outcomes are the ones Luu points at for future work: fast, trustworthy test suites the agent can iterate against; build and type-check feedback that fails quickly and loudly; specs that don't contradict themselves. His board-game eval is the proof — when the spec is ambiguous, every language scores zero.

That's the real reallocation this post should trigger. The hours teams have spent debating agent-friendly languages are hours not spent on the harness: tests, CI latency, docs the agent can retrieve, architecture that keeps changes local. Those are boring, unglamorous, and — unlike language choice — actually supported by the evidence.