HN Debrief

What's the best programming language for coding agents?

  • AI
  • Programming
  • Developer Tools
  • Open Source

The post benchmarks how well coding agents handle different languages on tasks like implementing a Zstandard decoder and a Pandoc-like converter, looking at token usage, speed, and how close outputs get to correct behavior. The headline question is "best language for coding agents," but the article itself is much less decisive than that. Several commenters pointed out that the variance is high, the task choice is narrow, and the results mostly do not support sweeping claims about one language being intrinsically better for LLMs. Python and JavaScript looked strong on some charts, oddballs like J and Factor often struggled, and the safer conclusion was that modern models already generalize across many languages better than people expected.

Choose a language stack that gives agents fast, reliable checks like compilers, linters, tests, and strong conventions, then optimize your repo and workflows around those loops. Treat language-level token efficiency as a weak signal unless your tasks, tooling, and libraries match the benchmark closely.

Discussion mood

Interested but skeptical. People liked the question, distrusted the article's certainty, and kept steering the conversation toward real-world concerns like tooling, verification, framework conventions, and maintainability rather than raw token efficiency.

Key insights

  1. 01

    MirrorCode found little language effect

    A newer benchmark on long-horizon tasks reported little difference in solve rates across Python, C, Rust, Go, OCaml, and Ada, with only modest token differences among successful runs. That sharply lowers the odds that syntax or training-data volume alone explains day-to-day agent performance, and it strengthens the idea that current models transfer programming ability across languages better than many people assume.

    Do not redesign your stack around claims that one mainstream language is categorically best for agents. If you want evidence, look for benchmarks that match your task length, dependency model, and tool access.

      Attribution:
    • tadamcz #1
    • internet_points #1
  2. 02

    Tooling and standard libraries beat syntax

    Go and C# got praised less for their syntax than for the fact that they narrow the agent's search space. A curated standard library, fast builds, analyzers, and easy introspection mean the model spends less effort picking libraries and more effort closing a working loop. That also explains why "batteries included" ecosystems punch above their weight even when they are not the most concise on paper.

    Bias toward ecosystems where common tasks can stay inside the standard library or a small curated set of packages. Add analyzers and easy inspection tools so the agent can verify choices without dragging in more dependencies.

      Attribution:
    • michaelteter #1
    • YuechenLi #1
    • bob1029 #1
    • xnorswap #1
  3. 03

    Framework conventions create strong rails

    People who had good results in Python often named constrained environments like Django, uv, Ruff, Pyright, or a project with hooks wired into every edit. The point was not that Python magically works. It was that strong conventions and automatic checks turn a messy language into a much more reliable target. Similar praise went to Flutter and OCaml when the surrounding tooling and structure were opinionated enough.

    If you keep a flexible language, force consistency at the repo level. Bake linting, typing, test hooks, and framework conventions into the edit loop so the model cannot wander into local style inventions.

      Attribution:
    • win311fwg #1
    • JodieBenitez #1
    • janpeuker #1
    • gostsamo #1
    • owaislone #1
    • agentcoops #1
  4. 04

    Static checks reduce babysitting

    The most convincing case for Rust and other strict languages was operational, not ideological. They shift failures from runtime into compile time, let types stand in for part of the spec, and give the agent clearer error signals than dynamic stacks do. That reduces the amount of code a human has to read just to discover what the agent meant, which matters more over repeated sessions than a small token win on first draft generation.

    For systems that will evolve over many agent passes, optimize for fast, explicit failure modes. Strong compile-time checks often pay back more in reduced review and debugging than they cost in verbosity.

      Attribution:
    • lowbloodsugar #1
    • gr_norm #1
    • genxy #1
    • jillesvangurp #1
    • SwellJoe #1
  5. 05

    Benchmarks understate real agent advantages

    Several comments argued that air-gapped evals miss how agents actually work. In practice they search docs, inspect source, download libraries, run probes, and use bespoke harnesses. Restricting that can turn the benchmark into a test of memory and corpus retrieval, especially for famous artifacts like the educational Zstandard decoder, instead of a test of productive coding in a live environment.

    When you evaluate coding agents internally, let them use the same search, docs, and throwaway execution tools they would have in production. Otherwise you may optimize for a benchmark behavior that does not map to real output quality.

      Attribution:
    • gr_norm #1
    • eterm #1
    • lowbloodsugar #1
  6. 06

    Architecture matters more than language purity

    A cleanly componentized system with sharp contracts can make a supposedly weaker language easier for agents than a giant monolith in a stricter one. Separating layers by module or even by language gives the model smaller contexts and clearer boundaries, which cuts accidental cross-layer edits and makes verification more local.

    Invest in boundaries before chasing language wins. Smaller modules, explicit contracts, and separated layers will usually improve agent reliability faster than a rewrite into the currently fashionable language.

      Attribution:
    • kayashaolu2 #1
    • imagent #1

Against the grain

  1. 01

    Go can be miserable to review

    The pro-Go consensus got a real objection from someone who finds generated Go too verbose to inspect at scale. In that view, the lack of expressive types like Option and the amount of boilerplate make large agent-written diffs harder to reason about, which cancels out some of the tooling advantage.

    Do not assume agent-friendly generation also means human-friendly review. Pilot on real diffs and maintenance tasks, not just greenfield prompts, before standardizing on Go.

      Attribution:
    • nojvek #1
  2. 02

    Minor languages work fine with agent harnesses

    The idea that a language needs huge training-set presence took a hit from reports about Gleam, Lustre, Roc, and even unreleased custom languages working well when the model is inside a proper harness. The caveat was important. Autocomplete remains weak, but slower agentic loops that compile, lint, and retry can succeed even in ecosystems with tiny public corpora.

    If your team likes a niche language, test it with a full agent harness before writing it off. Training-data size matters less once the model can compile, lint, and iteratively repair its own output.

      Attribution:
    • jdiff #1
    • MichaelNolan #1
    • brabel #1
  3. 03

    The article's metrics are too thin

    Some commenters thought the whole setup was pointed at the wrong target. Token counts and one-shot correctness on toyish tasks do not capture the parts of software work that dominate cost in practice, like library leverage, non-functional requirements, iterative feature work, tracing, dependency injection, and incident rates after repeated changes.

    Use benchmark results as a hint, not a purchasing decision. If you care about agent productivity, build evaluations around the maintenance and integration work your team actually does.

      Attribution:
    • michaelbarton #1
    • tadamcz #1
    • ffsm8 #1

In plain english

Ada ↩
A statically typed programming language used heavily in safety-critical systems such as aerospace and defense software.
C# ↩
A programming language in the .NET ecosystem designed for general-purpose software development.
Django ↩
A popular Python web framework with strong conventions about project structure and application design.
Gleam ↩
A statically typed functional language that runs on the Erlang virtual machine and JavaScript.
Lustre ↩
A Gleam web framework for building applications with a functional style.
OCaml ↩
A statically typed functional programming language known for type inference and strong tooling.
Pandoc ↩
A widely used document conversion tool that transforms files between markup and publishing formats.
Pyright ↩
A static type checker for Python that analyzes code without running it to catch type-related errors.
Roc ↩
An emerging functional programming language focused on reliability and developer ergonomics.
Ruff ↩
A fast linter and formatter for Python that checks code style and some classes of mistakes automatically.
uv ↩
A Python package and environment management tool designed to be fast and reproducible.
Zstandard ↩
A modern compression algorithm, often shortened to zstd, designed for good speed and compression.

Reference links

Benchmarks and evaluations

  • MirrorCode paper
    Long-horizon benchmark cited to argue that solve rates differ little across several programming languages
  • MirrorCode leaderboard
    Ongoing leaderboard comparing recent models, mentioned as a more current reference point
  • AutoCodeBench
    Benchmark referenced alongside Elixir-specific claims about coding agents

Language and ecosystem references

Elixir and agentic coding

Python and syntax discussion

Examples and implementation details

Developer tools and tutorials