My thoughts on the future of Go in the AI era
One slightly controversial opinion I have is that AI might actually make boring languages more valuable, not less.
To be fully honest, nowadays I don’t write as much Go code as I wanted.
One reason is that we don’t use Go at my current company. We mostly use TypeScript, about which I still have mixed feelings, but to be fair, it works pretty well for us nevertheless. So I won’t blame TypeScript much here.
I still maintain a few Go projects, so I write at least some amount of Go from time to time.
But oh boy, I miss writing more of it.
Especially I miss the developer experience. Nothing even comes close for me, and interestingly, I think that becomes even more important in the AI era. And in this article I’d like to rant a bit about that.
Sponsor
AI writes more code than ever. Reviewing it shouldn’t mean scrolling forty files in alphabetical order.
CodeRabbit Review reorganizes any pull request from a flat file list into a structured, layer-by-layer walkthrough - the logical reading order of the change, not the order your platform happens to sort it. Every range gets its own plain-language summary, with sequence diagrams, state machines, and ERDs generated inline wherever a visual earns its place.
Cohorts group related files and chunks so you review one idea at a time. Layers order them so foundational changes - data shapes, contracts - come before the code that depends on them. Code Peek lets you click any variable, function, class or type to see its definition and usages without leaving the tab, while Semantic Diff view cuts past formatting noise to show what actually changed.
Open it straight from the Review Change Stack button in the PR Walkthrough. Navigate cohorts and layers from the keyboard, comment against exact line ranges and submit native reviews, comments and approvals post back to GitHub or GitLab right where your team expects them.
In the early access, available for free to everyone.
From the team that pioneered AI code reviews. 2M reviews every week. 6M repos. 15K customers.The review interface built for the way modern PRs are actually written.
Review your next PR with CodeRabbit Review Today
Things are clearly changing now with coding agents, and the way we write code. I don’t mean all of us, by the way, I still have huge respect for people who manually craft software without relying heavily on AI. I think there will always be space for that level of engineering craftsmanship.
So, things are changing, for better or worse, I am still not completely sure, but you can already see some trends forming. Rust and TypeScript are becoming dominant choices in AI-generated code, while some other languages… let’s just say you hear less and less about them.
So the real question is: what programming languages will still matter in 5 years from now?
I think we will see fewer dynamic Backend languages in new projects. Ruby on Rails, PHP, maybe even Python for some Backend workloads. Not because those languages are bad, obviously. Many of them are fantastic for humans.
You see, without AI, languages competed a lot on human ergonomics. Now they also compete on machine ergonomics.
Take Ruby on Rails for example. It is incredibly human-friendly, but I would argue not necessarily machine-friendly, performance-wise and typing-wise. Humans can navigate conventions, implicit magic, and DSLs very naturally because they understand context. Models struggle more with that. Explicit systems are simply easier for them to reason about.
And then there are new so-called AI-native languages.
Honestly, reading that I am still not sure what are the strengths here
they even route the docs differently for humans or agents. Is it different?
And honestly, I still don’t fully understand the pitch. Both of them feel like AI generated slop languages made with a prompt like “Hey, make me a programming language, do not make mistakes”.
Models today are trained mostly on existing languages and existing ecosystems. So how exactly are they suddenly supposed to generate perfect code in a completely new language with no mature tooling, no massive production codebase, no battle testing, and very little real-world data?
What about security, compilation? Feels like a blackbox.
So right now, ecosystems still matter a lot.
And that is where Go becomes really interesting.
Because in my opinion, and many people will disagree, Go is actually an extremely good language for LLMs. Not just for humans, but for models too. And honestly, I am really rooting for it to win this competition.
So let’s review a few things that I think make Go uniquely good for the agentic era.
First, the standard library is absolutely massive and incredibly well-designed. You can build real production systems with surprisingly few dependencies. HTTP servers, JSON handling, crypto, testing, concurrency, file systems — most of it is already there.
And another important thing: the Go team takes security and stability very seriously. You rarely hear about catastrophic ecosystem-level security disasters coming from the Go standard library itself.
Then there is the compiler. Go compiles insanely fast.
That matters much more in the AI era than people realize. Humans can tolerate slower feedback loops. Agents really cannot. AI systems might compile and iterate hundreds of times while solving a task. Fast compilation directly improves that workflow.
Then you have:
single static binary distribution
built-in formatting
powerful cross-compilation
minimal dependency hell
simple and intentionally boring syntax
Go is pragmatic. It has one mostly obvious way to do things
And this is actually one of Go’s greatest strengths. Go intentionally removed many ways to write “creative” code. There are simply fewer ways to make a mess, which means AI-generated Go code often ends up looking surprisingly clean and maintainable.
One of my favorite features: Go’s compatibility promise.
Back in Go 1, the team introduced a compatibility guarantee that basically says old programs should continue working on newer Go versions.
This sounds boring until you compare it to some modern JavaScript ecosystems where dependencies from two years ago already stop working.
I can still open Go projects I wrote almost 10 years ago and run them on a modern Go version without issues.
That level of stability is honestly extremely rare.
And I think stability might become one of the most valuable engineering properties again, especially when AI starts generating massive amounts of code. The last thing anyone wants is millions of lines of generated code depending on fragile ecosystems that break every six months.
Let’s actually try it.
I found one of my old projects (10 years old): https://github.com/plutov/games
It just runs.
I also think formatting matters much more than people admit, especially while humans still review AI-generated code.
And gofmt alone adds enormous value here.
Every Go project looks roughly the same. The style guide is basically built into the language itself. You do not spend time debating formatting rules or installing fifteen prettier plugins and linter configs.
You just run: gofmt
And when AI generates code, this consistency becomes even more valuable because stylistic entropy never really accumulates.
Then comes go vet, linting, which are also consistent between projects.
Another massively underrated feature is cross-compilation.
This still feels magical to me:
GOOS=windows GOARCH=amd64 go build
GOOS=linux GOARCH=arm64 go buildAnd that’s it.
You instantly get binaries for completely different platforms without setting up complicated build pipelines or external tooling.
Again, fewer moving parts.
Fewer things that break.
That matters a lot when autonomous agents start building and deploying systems end-to-end.
And again, error handling.
Some people dislike Go’s error handling because it is verbose, but others love it because it is explicit.
err := os.ReadFile()
if err != nil {
// ...
}
And honestly, for AI-generated code, explicitness is amazing.
The control flow is obvious. The failure paths are visible. There is much less hidden magic and much less ambiguity. Models generally perform better when the code is straightforward and deterministic.
You are almost forced to think about failure cases.
And that is a good thing.
And then there is concurrency.
Go still has one of the nicest concurrency models ever designed.
go fetchData()Even today, spawning concurrent work in Go feels absurdly lightweight compared to many other ecosystems.
Simple primitives. Simple mental model.
One slightly controversial opinion I have is that AI might actually make boring languages more valuable, not less.
Because maintainability scales better than cleverness.
Generated code does not need to be genius-level engineering. It needs to be understandable, stable, refactorable, and easy to verify.
And Go is proudly boring in exactly the right ways.
I don’t know whether Go will become the dominant AI-era language.
Maybe it won’t.
But I do think it will age incredibly well.
Go still feels refreshingly simple.
And honestly, simplicity might end up being one of the most important features in the entire AI era.