The Token Economics of Programming Languages

I started counting tokens instead of lines of code. The results made me mass-delete some opinions I used to have.

TL;DR: When LLMs write your code, every language has a price tag measured in tokens. Go costs the least per feature, Java costs the most, and the gap is big enough to change which languages make economic sense. The cheapest language to generate is now the cheapest language to build with.

The cost nobody talks about

We've been comparing languages forever. Performance, syntax, ecosystem, hiring pool. But here's a comparison nobody was making five years ago: how many tokens does it cost to generate a working feature in this language?

That question matters now. If you're using Claude or GPT to write most of your code (and increasingly, most of us are) then the token cost of your language choice is a real line item. Not metaphorical. Actual dollars.

I started measuring this after noticing something. When I asked an LLM to build the same REST endpoint in Go and in Java, the Go version came back in one shot. The Java version needed three rounds of back-and-forth, produced five files, and still had a Spring annotation wrong. Same feature. Five times the tokens.

Let's count

Here's a simple exercise. Take a basic CRUD endpoint: accept JSON, validate it, write to a database, return a response. Nothing fancy. Every backend developer writes this ten times a week.

Go:

• One file
• ~40 lines
• ~300 tokens generated
• Compiles in under a second
• First attempt usually works

Python (FastAPI):

• One file
• ~30 lines
• ~250 tokens generated
• No compile step
• First attempt usually works, but type bugs hide until runtime

TypeScript (Express):

• One or two files
• ~50 lines
• ~400 tokens generated
• No compile step (or tsc in ~2 seconds)
• First attempt usually works

Java (Spring Boot):

• Controller, Service, Repository, DTO, maybe a config class
• ~150 lines across 4-5 files
• ~1,200 tokens generated
• Compile in 15-30 seconds
• First attempt often has annotation or dependency issues, needs 1-2 retries

Rust:

• One or two files
• ~60 lines
• ~500 tokens generated
• Compiles in 5-15 seconds
• First attempt sometimes fights the borrow checker, may need 1 retry

Now multiply by a real project. A service with 20 endpoints, auth, middleware, database migrations. The Go project costs you maybe 8,000 tokens to generate. The Java project costs 30,000+. And that's before the retries.

It's not just the generation, it's the feedback loop

Token count is the obvious metric. But the real multiplier is the feedback loop:

generate → compile → test → fix → repeat

Each cycle costs tokens and time. Here's where languages diverge dramatically:

These are rough observations from my own usage, not benchmarks. Your numbers will vary by task complexity and model. But the relative ordering is consistent.

Go's fast compiler means you know in under a second whether the generation worked. If it didn't, the error message is one line, not a stack trace. The LLM fixes it in one shot. Total cost of a failure: maybe 100 extra tokens and two seconds.

Java's slow build means you wait 30 seconds to discover a Spring context failure. The error is 40 lines of stack trace. The LLM has to reason about dependency injection, bean lifecycle, annotation processing. The fix often introduces a new error. Total cost: 500+ extra tokens and two minutes. Per retry.

Why Go wins this game

Go wasn't designed for LLMs. It was designed for simplicity, readability, and fast compilation. But those goals accidentally made it the perfect language for AI-generated code:

One way to do things. There's no debate about patterns. HTTP handler? http.HandleFunc. JSON? encoding/json. Error? Return it. The LLM doesn't need to choose between three frameworks and four patterns. There's one answer.

Minimal syntax. No annotations, no decorators, no generics gymnastics (mostly), no inheritance hierarchies. Fewer decisions means fewer wrong decisions.

Fast feedback. Sub-second compile. The generate-check loop is almost instant.

Explicit everything. No magic. No hidden method calls triggered by annotations. What the LLM writes is what runs. If it's wrong, you can see why by reading the code.

Training data density. Go's stdlib covers most needs, so the patterns in training data are consistent. The LLM isn't choosing between Express, Fastify, Hono, and Koa. It's using net/http every time.

The Java problem

I've written about the money argument for Go over Java from a cloud cost perspective. But the token economics make it even worse.

Java's verbosity isn't just annoying to humans. It's expensive for machines:

• Boilerplate is token waste. Every getter, setter, constructor, builder. Pure overhead that communicates nothing the LLM didn't already know
• Framework complexity burns retries. Spring's annotation-driven magic means the LLM is guessing at runtime behavior it can't see in the code
• Long build times kill iteration speed. Every retry costs 30+ seconds of wall clock time
• Multiple files per feature. The LLM has to maintain coherence across controller, service, repository, DTO. Each seam is a place to get something wrong

Here's the thing that really gets me: Java developers often defend this structure as "clean architecture." But when you're paying per token and per retry, that "clean" separation is just expensive indirection. The abstraction layers don't help the LLM. They confuse it.

What about Rust?

Rust is interesting. It's not verbose in the Java sense. It's dense and meaningful. But the borrow checker creates a unique problem for LLMs.

The model often generates code that's logically correct but ownership-invalid. It knows what it wants to do. It just can't satisfy the compiler on the first try. That means retries, and Rust retries are expensive because:

1. The error messages are long (more input tokens)
2. The fix often restructures the code (more output tokens)
3. Compile times are longer (slower feedback)

Rust earns this cost when you need its guarantees: systems code, performance-critical paths, memory safety without GC. But for a web service? You're paying a token premium for guarantees you might not need.

What about Python?

Python is worth addressing because on paper it looks like it should win. It's the most concise mainstream language. No compile step. LLMs are extremely good at it (massive training data). A CRUD endpoint in Flask or FastAPI might be 30 lines and 250 tokens.

So why doesn't Python win? Two reasons.

No compile-time safety net. When the LLM generates Go, the compiler catches type mismatches, missing returns, unused imports instantly. With Python, bugs hide until runtime. A typo in a variable name, a wrong dict key, a None where you expected a list. These don't surface until you actually hit that code path. That means more retries per subtle bug, and each retry is more expensive because the error is "it crashed on line 47" not "type mismatch on line 47."

Dynamic typing compounds at scale. For a single script or small service, Python's token cost is excellent. But as a project grows past a few files, the LLM starts losing track of what types flow where. It returns a dict where you expected a dataclass, or passes a string where an int was needed. Go's type system makes these impossible. Python makes them invisible until production.

For scripting, data work, and small services, Python's token economics are competitive with Go. For anything bigger, the retry cost eats the savings.

TypeScript: the other cheap option

TypeScript lands close to Go in token economics for web-related work:

• Concise syntax
• Huge training data (it's everywhere)
• Fast type checking
• LLMs are very good at it

The difference is the ecosystem. TypeScript pulls in dependencies aggressively. A Go project might use the stdlib and one router. A TypeScript project has 50 dependencies in package.json, each with its own API surface the LLM has to get right.

For fullstack web work, TypeScript still wins on total cost because you share types between frontend and backend. But for standalone services, Go's smaller surface area means fewer tokens.

The compounding effect

Here's where it gets interesting at scale. These per-feature differences compound:

• A 50-endpoint service in Go: ~15,000 tokens to generate, maybe 2,000 in retries
• The same service in Java: ~60,000 tokens to generate, maybe 15,000 in retries

That's 17,000 vs 75,000 tokens. At current API pricing, it's the difference between a few dollars and actual money. For a team generating code all day, it's the difference between hundreds and thousands per month.

But money isn't even the biggest cost. Time is. The Go service is generated and working in an afternoon. The Java service takes days of back-and-forth, debugging annotation issues, fixing dependency conflicts, waiting for builds.

The training data flywheel

There's a self-reinforcing loop here that most people miss:

1. Go is cheap to generate → developers use LLMs to write more Go
2. More Go code gets written → more Go in future training data
3. Better training data → LLMs get even better at Go
4. Even better generation → Go becomes even cheaper

Java has the opposite dynamic. It's expensive to generate, so developers increasingly choose alternatives, so less new Java gets written relative to Go and TypeScript, so the gap widens.

This doesn't mean Java disappears. Legacy codebases are massive. But for new projects, the economics push you away from it with increasing force every year.

The rule

When you're choosing a language in 2026, add this to your criteria:

What's the total token cost to build and iterate on this project?

That means:

• Tokens per feature (verbosity)
• Retries per feature (LLM correctness × compile speed)
• Tokens per retry (error clarity × fix complexity)

Optimize for all three and you end up at Go for services, TypeScript for anything touching a browser, Python for scripts and data work, and Rust or C only when you genuinely need their specific guarantees.

Everything else is paying a premium for something the cheaper option already gives you. I wrote about this language selection framework in more detail in which language to pick when AI writes the code. The token economics are the underlying reason that framework works.

So what?

If you're starting a new project today, the language choice has a measurable cost that didn't exist five years ago. It's not just "what's the team comfortable with" anymore. It's "how many tokens will this decision cost us over the life of the project."

Go wins that calculation for backend services. Not because it's the "best" language in some abstract sense. Because it's the cheapest to generate correctly, the fastest to verify, and the simplest to iterate on.

The best language is the one that costs the least to think in. For humans and machines alike.