When generics landed in Go (golang) 1.18, they came with a rule that has annoyed people ever since: functions could declare type parameters, but methods could not. Go 1.27 removes that rule. A method can now declare its own type parameters, which makes patterns like chainable transformations possible for the first time. This was one of the most requested features in the language, and one of the most debated. In this article, we'll look at the problem, the fix, and the restrictions that come with it.
The encoding/json package is one of the oldest packages in Go (golang), and it shows. It matches field names case-insensitively, silently accepts duplicate keys, and marshals nil slices as null. We've all worked around these for years. Thankfully, Go 1.27 ships the fix: encoding/json/v2 graduates from experiment to standard library. It's stricter by default, significantly faster at unmarshaling, and your existing encoding/json code keeps working. In this article, we'll walk through what actually changes, by example.
Go (golang) 1.26 shipped in February of 2026. The headlines went to the Green Tea garbage collector and the new SIMD package. Those are great, but they aren't the changes you'll notice in your day to day code. The changes you'll notice are smaller: new now accepts an expression, errors.AsType gives us a generic errors.As, and slog.NewMultiHandler lets one logger write to many destinations. In this article, we cover each one by example.
Goroutine leaks are one of the sneakiest bugs in Go (golang). A goroutine blocks on a channel that nobody will ever read from, it sits there forever, and your memory slowly climbs until someone gets paged. The old way to find them was to stare at a full goroutine dump and guess which ones were stuck. Go 1.27 gives us something better. The runtime can now prove that certain goroutines can never wake up, and it reports them in a new goroutineleak profile. In this article, we'll write a leaky program, catch the leak with the new profiler, and fix it.
Our MCP server has been running in beta since November 2025. The feedback has been solid. Developers are using it daily to audit code, find examples, and get best practice recommendations. Now we're adding what teams have been asking for: shared accounts, new tools, and pricing that makes sense for organizations.
I spent over a decade building muscle memory in vim and tmux. Then AI-powered IDEs like Cursor showed productivity gains I couldn't ignore, so I made the switch despite the pain. A year later, I'm back in the terminal. Not because I gave up on AI, but because AI evolved. CLI-based agents like Claude Code changed everything. Now I work from anywhere via Tailscale and Termux, running multiple AI agents simultaneously without my machine crashing. The future of development wasn't in the IDE. It was in making the terminal powerful enough to compete.
I wrote about Claude Commands a few weeks ago. Clone this, symlink that, update manually. It worked, but managing individual command repos felt like the early days of GOPATH. Then Claude Code introduced plugins, and everything clicked. Now I have opinionated dev workflows, auto-invoked best practices, and Go training materials baked right in—no symlinking required.
I was already using AI for everything—fixing issues, generating tests, reviewing code. But every day I'd re-explain my process, skip context because typing was tedious, and wonder why the output wasn't quite right. Then I realized: the problem wasn't AI. It was me being lazy with my prompts. Commands fixed that.
Here's the counterintuitive truth emerging from two years of AI coding assistants: the better you already are at programming, the more AI helps you. The worse you are, the more it can hurt. This is creating a widening skills gap in software development, and it's exactly the opposite of what everyone predicted when ChatGPT launched. Training isn't becoming obsolete. It's becoming the difference between thriving with AI and drowning in AI-generated technical debt.
What if your AI coding assistant had instant access to 30+ years of Go training expertise? Not the jumbled mess of Stack Overflow and GitHub repos it usually learns from, but actual, curated, battle-tested best practices from thousands of hours teaching Go in production environments. We're building that. It's in beta now, and if you've ever trained with Gopher Guides, you get free access.
Over the past three months, we've been obsessively focused on eliminating friction in the learning experience. The result? A training platform where you can download entire courses with one click, jump from course material directly into your editor, and navigate content that feels like it was built for how developers actually learn. These aren't flashy features. They're thoughtful improvements that get out of your way so you can focus on mastering Go.
As a senior developer with 20+ years in the trenches, I built a fully functional, production-ready SEO validation system in under 4 hours using AI assistance. Ten years ago, this would have taken me weeks. But here's the key insight: without being a senior level developer, AI would have never gotten this to work. This is the story of how AI amplifies expertise rather than replacing it, complete with real metrics, mistakes made, and lessons learned.
AI hasn't killed software training. In fact, after seeing training demand slow down initially when ChatGPT and Copilot took off, we're now busier than ever. Why? Because teams are discovering what I've been saying all along - AI is only as good as the code it learned from, and most Go code out there isn't idiomatic.
This article explores important performance considerations when working with pointers in Go. We'll cover key topics like returning pointers to local variables, choosing between pointer and value receivers for methods, and how to properly measure and optimize pointer-related performance using Go's built-in tools. Whether you're new to Go or an experienced developer, these tips will help you write more efficient and maintainable code.
Creating technical articles can be painful when they include code samples and output from running programs. Hype makes this easy to not only create those articles, but ensure that all included content for the code, etc stays up to date. In this article, we will show how to set up Hype locally, create hooks for live reloading and compiling of your documents, as well as show how to dynamically include code and output directly to your documents.
In Go (golang) release 1.21, the slog package will be added to the standard library. It includes many useful features such as structured logging as well as level logging. In this article, we will talk about the history of logging in Go, the challenges faced, and how the new slog package will help address those challenges.
In release 1.21, the slices package will be officially added to the standard library. It includes many useful functions for sorting, managing, and searching slices. In this article, we will cover the more commonly used functions included in the Slices package.
After training for over four years, and recently enrolling in my own Masters degree program, I've married both of my passions and I'm excited to announce our new Masters Style Go Courses!
Table driven testing is not a unique concept to the Go programming language. However, there are some great features that make table driven testing in Go faster and more reusable. This article will cover how to get the most out of table driven testing with Go (golang).
The most anticipated feature of Go 1.16 is the addition to the Go tooling, and standard library, that allow for embedding static content into binaries. While it is tempting to start playing with this new toy right away, it is important to understand how it works first. In this article we are going to take a look at the new io/fs package introduced in Go 1.16 to support embedding.
Iota is a useful concept for creating incrementing constants in Go. However, there are several areas where iota may not be appropriate to use. This article will cover several different ways in which you can use iota, and tips on where to be cautious with its use.
If you haven't worked in a typed language before, it may not be obvious at first the power that it brings. This article will show you how to leverage the type system to make your code easier to use and more reusable.
Go is a typed language, but most Go developers don't truly embrace it. This short article talks about tips and tricks to write more robust code using custom types in Go.
The art of writing software is the act of communication. You might feel that this is a private conversation about your code with a persnickety compiler, but the audience for software is much larger. It’s the people who use your libraries and your APIs, the folks who work with you maintaining the codebase, and it's you, in the future, searching for clues about why you wrote what you wrote the way you wrote it. This talk is all about naming. It’s about the names we give to things in our programs and how those decisions can affect the maintainability of the software we write.
The process of writing a unit test usually follows a certain set of steps. First, we set up dependencies of the unit under test. Next, we execute the unit of logic under test. We then compare the results of that execution to our expectations. Finally, we tear down any dependencies and restore the environment to the state we found it so as not to affect other unit tests. In Go 1.14, the testing package now includes a method, testing.(*T).Cleanup, which aims to make creating and cleaning up dependencies of tests easier.
I recently had a friend come to me and mention that their website I created for them years ago needed some updating. After looking at it, it was clear it was time for an update. This article will walk through the design decisions and technical challenges that I needed to address in bringing their site up to some modern standards.
