Which Programming Language Should You Use with Claude Code?

At one time, we tooled lines of code to calculate workload; later, we calculated workload based on tokens

A few weeks ago, a fascinating benchmark appeared on GitHub: mame/ai-coding-lang-bench. The author — a self-declared Ruby committer — ran Claude Code against 13 programming languages to implement a simplified Git system. 600 total runs. Hard numbers. Reproducible methodology.

The results are eye-opening, and if you’re a Go engineer, they’re worth your attention.

The Experiment

The methodology is elegant in its simplicity:

• Task: Implement a simplified Git-like version control system
• Two phases: v1 (basic features) + v2 (feature extensions)
• Languages: 13 total, each tested 20 times
• Metrics: Time, cost (API tokens), and lines of code generated
• 600 total runs, with results averaged

One clever design choice: the author used a custom hash algorithm rather than SHA-256 to avoid differences in library dependencies across languages. This isolates pure language-level generation characteristics — the same problem, just expressed differently.

The benchmark measures something we rarely quantify: how efficiently a language lets an AI coding agent think.

The Rankings: Dynamic Languages Win, Handily

The numbers don’t lie:

Ruby, Python, and JavaScript dominate. They’re fastest, cheapest, and most stable.

Then notice TypeScript — a statically typed superset of JavaScript. It takes nearly 2× as long and costs 60% more than plain JavaScript. The same underlying logic, but dramatically different AI coding performance.

Isn’t it fascinating?

The Type-Checking Tax

The most striking finding is that adding type checkers significantly penalizes AI coding performance.

• Python + mypy: 1.6–1.7× slower than plain Python
• Ruby + Steep: 2.0–3.2× slower than plain Ruby

This makes intuitive sense once you think about it. Static type systems require the AI to satisfy multiple constraints simultaneously: type correctness + business logic + API compatibility + compiler happiness. More constraints = more reasoning steps = more tokens = more time = more money.

This is not a flaw in type systems. It’s a fundamental property of constraint satisfaction during code generation. The model has to solve a harder problem.

The implication is sharp: when you add a type checker, you’re not just adding safety — you’re adding a tax that scales with AI generation complexity.

The Compactness Paradox

Here’s where it gets counterintuitive.

OCaml and Haskell produce the most compact code — around 216–224 lines. Functionally, this is impressive. Yet they ranked mid-to-low in generation speed.

Why? Concise code in expressive languages often requires more sophisticated reasoning. Generating idiomatic Haskell means the model must reason about type classes, monadic composition, and lazy evaluation simultaneously. The model “thinks harder” to produce less code.

Cognitive density costs tokens. More lines of verbose code can be cheaper to generate than fewer lines of dense, idiomatic code.

This runs counter to a common intuition: we often assume that more expressive languages are “simpler” to use. For humans, maybe. For AI generation models, not necessarily.

What About Reliability?

Across 600 total runs, only 3 failures occurred:

• Rust: 2 failures
• Haskell: 1 failure

The conventional wisdom says “static types prevent bugs.” But in this benchmark, every failure happened in a statically typed language. This doesn’t mean static typing is bad — but it challenges the assumption that type systems make AI-generated code automatically more reliable.

The model’s failure modes are different from human failure modes. Types guide human reasoning; they may constrain AI generation in ways that occasionally cause cascading failures.

So… Where Does Go Stand?

Go wasn’t explicitly highlighted in the summarized data, but its position is easy to reason about from first principles.

Go is statically typed with explicit type declarations, similar to TypeScript and Rust. Based on observed patterns:

1. Go likely sits in the middle tier — slower than Ruby/Python, but probably faster than TypeScript due to Go’s deliberate language simplicity
2. Go’s lack of generics complexity helps — before Go 1.18, and even after, Go avoids the advanced type system features that challenge AI reasoning
3. Go’s verbose error handling hurts — if err != nil chains are repetitive but necessary, inflating token count with boilerplate

The key insight: Go’s simplicity is a relative advantage in the AI coding era, compared to languages with more complex type systems (Rust, Haskell, TypeScript with advanced generics).

The Strategic Playbook for Go Engineers

The author’s conclusion resonates deeply:

“The traditional strategy — prototype with dynamic languages, then migrate to static ones — remains strategically sound, especially as AI systems improve at cross-language translation.”

For Go engineers, this translates to a concrete workflow:

Phase 1: Prototype with Python or Ruby Use AI to rapidly explore the problem space — data structures, API contracts, edge cases. Dynamic languages let the model iterate fast and cheaply.

Phase 2: Harden the API contract Once you understand what you’re building, the types become the specification. This is where static typing pays off.

Phase 3: Migrate to Go with AI assistance As AI models improve at cross-language translation, this step is increasingly cheap. You bring Go’s strengths — goroutines, single binary, memory efficiency, robust standard library — into a well-understood problem domain.

This isn’t a knock on Go. The benchmark measures AI generation speed for prototyping-scale tasks. Go’s advantages exist at a different layer of the value stack: production reliability, operational simplicity, and team scalability.

The Bigger Picture

What this benchmark reveals is that AI coding performance is now a first-class language property — as real as runtime performance or developer ergonomics.

Just as we benchmark HTTP servers and database clients, we should factor in AI generation efficiency when making our language and toolchain choices. The metric is different: not RPS, but dollars per feature.

As Claude Code, Cursor, and Copilot become primary development surfaces, language design will increasingly be evaluated along a new axis: how efficiently can an AI reason in this language?

The languages that win in the AI era may not be the same ones that win in the runtime era. Understanding both dimensions is the new engineering literacy.

Summary

1. Dynamic languages (Ruby, Python, JS) dominate AI-assisted prototyping — fastest, cheapest, most stable
2. Type-checking overhead is real — mypy costs 1.6–1.7×, Steep costs 2–3.2× more time
3. Code compactness ≠ generation speed — expressive languages (OCaml, Haskell) can be slower despite producing less code
4. Static types don’t prevent AI failures — the only 3 failures across 600 runs were in statically typed languages
5. For Go engineers: prototype with dynamic languages, migrate to Go for production — AI translation is improving fast
6. AI coding performance is now a language selection criterion alongside runtime performance and ecosystem maturity

The playing field is shifting. The wisest move is to understand it clearly, not to resist it.

Reference

• mame/ai-coding-lang-bench — Full benchmark data, code, and methodology