Why I Started Learning Go in 2026
On rediscovering the joy of learning without pressure
At the beginning of this year, I started learning Go.
This might seem like an odd choice. We’re living through a moment where AI coding assistants write most of the code anyway. Why would I spend my limited free time learning a new programming language from scratch?
I hadn’t properly learned a new language since I picked up Python in 2014. That’s over a decade of using the same primary tool. Of course, I’ve worked with other languages when projects demanded it. Java here, JavaScript there. But there’s a difference between solving an immediate problem and actually learning something. The former is about getting unstuck. The latter is about building understanding.
I missed the latter.
A brief history of my programming education
My first programming experience was Visual Basic in elementary school. At university, we started at the lowest level possible: machine instructions. Then Pascal, followed by C, C++, and R. Eventually I discovered Python, which I later heard described at an event in Austin as “the second-best language for anything.” That description stuck with me because it’s true. Python is rarely the optimal choice, but it’s almost always good enough.
For years, good enough was fine. I didn’t need to go deeper. The problems I was solving didn’t require it, and there was always another client, another project, another fire to put out.
But something had been nagging at me. I wanted to wrap my head around concepts again. Not just use them, but understand them properly. Concurrency. Polymorphism. Pointers. The fundamentals that get rusty when you’re always operating at higher levels of abstraction.
Why Go?
I considered Rust, but the learning curve felt too steep for what I wanted. I wasn’t trying to master something new. I was trying to rediscover something old: the experience of learning itself.
Go hit a sweet spot. It sits somewhere between C and Python. Low-level enough to force you to think about memory and concurrency, but not so demanding that every evening session becomes a slog. The language is opinionated and minimal, which meant less time learning syntax quirks and more time engaging with actual concepts.
I particularly enjoyed working with goroutines, channels, mutexes, and locking mechanisms. These aren’t new ideas, but implementing them in a new context made me think about them freshly.
Learning without pressure
Here’s what surprised me most: the experience was completely different from how I usually learn things.
When you’re solving a problem for a customer, you’re trying to fix it and move on to the next thing. There’s a deadline. There’s a budget. There’s someone waiting for the deliverable. You learn exactly what you need to know and not a byte more.
When you learn for curiosity, it becomes play. You try things. You test hypotheses. You fail and it doesn’t matter. You get genuine joy when something clicks. It becomes like art. You do it for the sake of doing it.
The biggest motivation was knowing I didn’t have to do any of this. No client was asking for it. No project depended on it. I was learning Go because I wanted to, and that freedom changed everything about the process.
The resources that worked
I started with the Tour of Go, which is excellent for anyone with solid programming fundamentals. I didn’t need explanations of what a loop is. I needed to understand how Go handles things differently. The Tour assumes competence and moves quickly, which suited me.
From there, I moved to a YouTube tutorial by Alex Mux that covered more ground, then to Go by Example for reference. And throughout, I used Claude itself as a learning companion.
The way I used Claude was interesting. Rather than asking it to write code for me, I asked it to quiz me. Generate a piece of code, and I had to figure out what it returns. This forced active engagement rather than passive consumption. Claude also helped me identify what to focus on, pointing out which concepts were most important to understand deeply versus which were just syntax to memorise.
A couple of weekends of focused work, plus some sporadic after-work sessions, and I had enough foundation to start writing my own code.
What this has to do with AI
I’ll be honest: learning Go hasn’t directly changed my client work yet. It’s been barely a few weeks.
But I think there’s something deeper happening.
The discourse right now is loud with claims that AI will replace coding. That fundamentals don’t matter when you can just prompt your way to a solution. I don’t buy it.
Understanding fundamentals makes you better at working with AI, not worse. It’s all about context and layers of abstraction. The more context and opinion you bring to a coding tool, the better results you get. Instead of saying “build this tool,” you can define the exact steps. You can specify the constructs. You can give the AI something that only needs to be translated into code rather than invented from scratch.
If you don’t understand what’s possible, you can’t ask for it precisely. If you can’t read the code AI generates, you can’t verify it’s correct. The fundamental skill isn’t typing. It never was. The fundamental skill is thinking about problems in computational terms, and that skill needs maintenance.
Learning as maintenance
I don’t know how much I’ll use Go going forward. It depends on time, on projects, on what problems show up. But I’ll keep playing with it when I can. The goal isn’t mastery. The goal is keeping the underlying machinery in working order.
There’s a version of this career where you slowly let your fundamental skills atrophy. Where you become dependent on tools that abstract away everything you once understood. Where you can ship code but can’t explain what it does.
I don’t want that version.
Fundamentals were always the key to this work, and that won’t change just because the tools got better. If anything, the gap between people who understand what’s happening beneath the abstractions and people who don’t is going to widen. The tools amplify what you bring to them. If you bring deep understanding, you get leverage. If you bring shallow prompts, you get shallow outputs.
Learning Go in 2026 isn’t about Go. It’s about staying sharp. It’s about remembering that this work can be joyful when you’re not racing against a deadline. It’s about maintaining the kind of mind that can engage with hard problems rather than just route around them.
And honestly, it’s about having fun again. That might be the most important part.