There Is No Best Language for Coding Agents

Dan Luu's large-scale evaluations show that the token-efficiency advantage of terse programming languages for AI coding agents largely disappears on real tasks, contradicting a widely cited claim. In tests where agents implemented a zstd decoder from spec and Pandoc functionality, no language class dominated, and mainstream languages tended to produce more correct and cheaper solutions. An independent arXiv paper by Zixuan Wu, Carolyn Jane Anderson, and Arjun Guha found agents burned 1.28–1.69x more tokens in OCaml than Python due to flailing in lower-resource languages.

AI https://sourcefeed.dev/c/ai Article There Is No Best Language for Coding Agents Dan Luu's large-scale evals show the token-efficiency case for terse languages collapses on real tasks. Rachel Goldstein https://sourcefeed.dev/u/rachel goldstein 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 https://danluu.com/pl-tokens/ 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 https://clojure.org/ ~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 https://facebook.github.io/zstd/ decoder from the spec, with no tests to lean on. In another, they implemented Pandoc https://pandoc.org/ 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. Sources & further reading - What's the best programming language for coding agents? https://danluu.com/pl-tokens/ — danluu.com - What's the best programming language for coding agents? https://news.ycombinator.com/item?id=49245936 — news.ycombinator.com - Which programming languages are most token-efficient? https://martinalderson.com/posts/which-programming-languages-are-most-token-efficient/ — martinalderson.com - The Best Programming Language for Tokenmaxxing: An Investigation of Coding Agent Behavior Across Programming Languages https://arxiv.org/abs/2607.22807 — arxiv.org Rachel Goldstein https://sourcefeed.dev/u/rachel goldstein · Dev Tools Editor Rachel has been embedded in the developer tooling ecosystem for nearly eight years, covering everything from IDE wars and package-manager drama to the quiet rise of AI-assisted coding. She has a soft spot for open-source maintainers and an unhealthy number of terminal emulators installed on a single laptop. Discussion 0 No comments yet Be the first to weigh in.