I kept asking "which language should I use?" and the answer kept changing. Then I realized the question was wrong.
TL;DR: Go and TypeScript are the two defaults. Rust, Python, and Kotlin are specialists you bring in for a specific need. When an LLM writes most of the code, you optimize for cheap, correct generation, not for what's easy to hire for.
The question that wouldn't sit still
A few weeks ago I was picking a stack for a new project. Simple question, right? Which language for the backend?
So I started narrowing it down. Fullstack web app? One answer. Just a REST service? A different answer. A CLI tool? Different again. gRPC instead of REST? It moved one more time.
Every time I changed the shape of the project, the "best" language changed with it. That's annoying. But then it clicked. The language was never the real variable. The thing deciding it was something people don't really talk about yet.
What changes when the AI writes the code
Here's the shift. For most of my career you picked a language based on your team. Who can maintain it? Who can we hire? What's still readable in five years?
Those things still matter. But when an LLM generates most of the code, a new priority jumps to the front: what does the model produce most cheaply and most correctly?
Think about what that means. You're paying per token. Every retry loop costs money. So the language that wins is the one that:
- Shows up a lot in training data, so the first attempt is usually right
- Has a compiler that catches errors before runtime, so fewer expensive retries
- Isn't verbose, so fewer tokens per feature
- Keeps everything in one context, so the model carries less in its head
That list quietly rules out a lot of "safe enterprise" choices. And it explains why my answer kept moving.
The scenarios, and where each one lands
Fullstack web app. The frontend is TypeScript, no argument. So make the backend TypeScript too. You share types end to end. The model writes one language, not two. There's no serialization glue to get wrong. That's the cheapest path by a mile.
A standalone REST service. Now the frontend argument disappears. This is Go's home turf. HTTP is in the standard library, the patterns are all over the training data, and the model gets them right on the first try. It's cheap to run too.
A CLI tool. Go again, or Rust if it has to be fast. Both compile to a single binary with no runtime to install. For a tool people download and run, that's the whole game.
gRPC or GraphQL. These are schema-first, so the schema becomes your spec and code generation does the cross-language work. gRPC pulls you toward Go, which is basically its native ecosystem. GraphQL pulls you toward TypeScript, where the tooling lives.
Notice the pattern? Two names keep showing up.
The two defaults, and three specialists
After all that, here's where I land.
Go and TypeScript are the defaults. TypeScript when there's a browser. Go for services and tools. You'll reach for these most of the time.
Rust, Python, and Kotlin are specialists. You bring them in when the job demands it, not by default:
- Rust when speed or memory is the actual point. A hot path, heavy processing, no garbage-collection pauses.
- Python for anything AI or data. Training, inference, pipelines. Below the API line, it's the only real choice.
- Kotlin for Android, or when you're already deep in the JVM world.
What about Java? Honestly, in this world it doesn't win a slot. It's verbose, which costs tokens, and it gives you nothing the defaults don't. If you're on the JVM anyway, Kotlin does the same job with less code.
The one rule underneath all of it
Strip away the scenarios and it comes down to this. Optimize for what the model generates cheapest and most correctly. Then let the shape of the thing break the tie.
- Browser involved? TypeScript.
- Backend service or CLI? Go, or Rust if it must be fast.
- AI or data? Python.
That's it. Three lines cover almost everything.
So who actually picks the language?
Here's the part I keep chewing on. These four win partly because the models were trained on them. More training data means better generated code, which becomes tomorrow's training data. The strong get stronger.
So are these the languages of the future because they're the best? Or because the AI learned them first and now leans on them?
Maybe that difference stops mattering. If the model picks the language for you, "which language" turns into an implementation detail, like which instructions your compiler emits. You stop caring.
Ten years out, the interesting question isn't which of these four wins. It's whether a human is still the one choosing.
That's also why I still think you should understand all of this yourself. The model can write Go. It can't tell you whether Go was the right call for your problem. That judgment is the part worth learning, and it's the part that doesn't get automated away. I wrote more about that in why you should still learn to code if it resonates.