I keep a folder of code I’ve deleted on purpose. Not the lost-to-a-bad-merge kind. The kind you remove because the language finally grew a better way to do the thing, and you want a small reminder that the old way is gone for good.<\/p>\n
Last August a fair chunk went into that folder: most of the Concurrency has always been Go’s headline feature. Goroutines and channels shipped in version one, and they hold up fine. But the patterns most of us built on top of them aged badly. The Go 1.25 shipped last August and absorbed enough of that boilerplate to be worth a post. So here’s a tour of the Go concurrency patterns I actually reach for in 2026: what the standard library finally took over, what moved to Here’s the pattern every Go developer has typed a few hundred times. Spin up a goroutine per item, track them all with a Three things in there are pure ceremony. The Go 1.22 already dealt with the third problem by giving every loop iteration its own variable. Go 1.25 dealt with the other two by adding a Most real concurrent work needs to do three things at once: wait for everything to finish, keep the first error, and stop the rest once that error shows up. That’s exactly the job My rule of thumb: if the goroutines can fail, use One goroutine per item is fine for ten URLs. Try it on fifty thousand and you’ll open fifty thousand sockets, or grab fifty thousand database connections, and something downstream will tip over.<\/p>\n For years the fix was a buffered channel used as a counting semaphore:<\/p>\n It works. It also reads like a riddle. Every time I came back to code like that I had to stop and work out whether sending or receiving was the “acquire” side. (Sending. It’s always sending. I still check.)<\/p>\n Once ten goroutines are running, the next This is the change I’m happiest about, because flaky concurrency tests have eaten more of my life than the actual concurrency bugs ever did.<\/p>\n You know the test. Something is supposed to happen after a timeout, so the test sleeps a little longer than the timeout and then checks:<\/p>\n That Go 1.25 promoted The function runs inside what the Go team calls a “bubble”. Inside the bubble the clock is fake. It would be nice to end with “concurrency is solved now”. It isn’t. A few things are still completely on you, and no shiny method on Goroutine leaks are the big one. Context propagation is that same discipline wearing a different hat. Channel ownership hasn’t moved either. The goroutine that sends on a channel is the one that closes it, never a receiver, and never two senders racing to get there first. The newer APIs do help sideways here, because the channels you never hand-write can’t deadlock on you, and I lean on the range-based patterns from my notes on Go iterators<\/a> for most of the iteration I used to wire up by hand.<\/p>\n Open your largest Go service and run Go 1.25 added WaitGroup.Go and a stable testing\/synctest. Here are the Go concurrency patterns I actually use in 2026, and the boilerplate I deleted.<\/p>\n","protected":false},"author":2,"featured_media":271,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"rank_math_title":"","rank_math_description":"Go 1.25 added WaitGroup.Go and a stable testing\/synctest. Here are the Go concurrency patterns I actually use in 2026, and the boilerplate I deleted.","rank_math_focus_keyword":"golang concurrency patterns","rank_math_canonical_url":"","rank_math_robots":"","footnotes":""},"categories":[159,45],"tags":[212,267,46,319,47,131,318],"class_list":["post-272","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-go","category-programming","tag-concurrency","tag-errgroup","tag-go","tag-go-1-25","tag-golang","tag-goroutines","tag-waitgroup"],"_links":{"self":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/posts\/272","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/comments?post=272"}],"version-history":[{"count":0,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/posts\/272\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/media\/271"}],"wp:attachment":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/media?parent=272"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/categories?post=272"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/tags?post=272"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}wg.Add(1)<\/code> calls I’d ever written.<\/p>\nWaitGroup<\/code> dance. The semaphore you hand-build out of a buffered channel. The time.Sleep<\/code> in a test that quietly hopes the CI runner isn’t having a slow morning. None of it was wrong. It was just boilerplate we’d all silently agreed to put up with.<\/p>\nerrgroup<\/code>, and what’s still completely your problem because no API is going to save you from it.<\/p>\nThe WaitGroup dance I stopped doing<\/h2>\n
WaitGroup<\/code>, wait for the lot to finish:<\/p>\nvar wg sync.WaitGroup\nfor _, url := range urls {\n wg.Add(1)\n go func(u string) {\n defer wg.Done()\n fetch(u)\n }(u)\n}\nwg.Wait()\n<\/code><\/pre>\nwg.Add(1)<\/code> that has to match a wg.Done()<\/code> living somewhere else. The defer wg.Done()<\/code> you will forget exactly once, and then lose an afternoon to a hang you can’t explain. And the func(u string)<\/code> with its (u)<\/code> at the bottom, copying the loop variable so the closure doesn’t grab the wrong one.<\/p>\nWaitGroup.Go<\/code> method. Same loop, now:<\/p>\nvar wg sync.WaitGroup\nfor _, url := range urls {\n wg.Go(func() {\n fetch(url)\n })\n}\nwg.Wait()\n<\/code><\/pre>\nGo<\/code> bumps the counter, runs your function in a goroutine, and decrements when it returns. The Go 1.25 release notes<\/a> call it a convenience, which sells it a bit short. The real win is that a mismatched Add<\/code>\/Done<\/code> pair is now impossible to write. If it compiles, the counting is correct. That’s a whole class of bug gone, not just a few keystrokes.<\/p>\nerrgroup is still the one I reach for most<\/h2>\n
WaitGroup.Go<\/code> is great for fire-and-forget work. It has one blind spot: it can’t tell you anything went wrong. The functions it runs return nothing, so if fetch<\/code> fails inside one of those goroutines, you find out never.<\/p>\ngolang.org\/x\/sync\/errgroup<\/code> has done for years, and 1.25 didn’t try to replace it:<\/p>\ng, ctx := errgroup.WithContext(ctx)\nfor _, url := range urls {\n g.Go(func() error {\n return fetch(ctx, url)\n })\n}\nif err := g.Wait(); err != nil {\n return fmt.Errorf("fetch batch: %w", err)\n}\n<\/code><\/pre>\nWithContext<\/code> is the part people skip, and they shouldn’t. It hands you a derived context that gets cancelled the moment any Go<\/code> function returns a non-nil error. If you actually pass that ctx<\/code> down into fetch<\/code>, one failure stops the other twenty requests still in flight, instead of letting them burn time and rate-limit budget on work whose result you’re about to throw away. The errgroup package docs<\/a> lay out the exact cancellation rules, and they’re worth two minutes before you rely on them.<\/p>\nerrgroup<\/code>. If they genuinely can’t, WaitGroup.Go<\/code>. I land on the first one far more often than I expected to.<\/p>\nBounded concurrency without the channel trick<\/h2>\n
sem := make(chan struct{}, 10)\nfor _, url := range urls {\n sem <- struct{}{}\n go func() {\n defer func() { <-sem }()\n fetch(url)\n }()\n}\n<\/code><\/pre>\nerrgroup<\/code> grew a SetLimit<\/code> method that does the same job and actually says what it means:<\/p>\ng, ctx := errgroup.WithContext(ctx)\ng.SetLimit(10)\nfor _, url := range urls {\n g.Go(func() error {\n return fetch(ctx, url)\n })\n}\nif err := g.Wait(); err != nil {\n return err\n}\n<\/code><\/pre>\ng.Go<\/code> call blocks until one of them finishes. You get bounded concurrency, error propagation, and context cancellation out of a single object, and whoever reads it next doesn’t have to decode a channel idiom first. I set the limit to match whatever the real bottleneck is, usually the connection pool size, rather than a round number that happens to look tidy.<\/p>\nTesting concurrency without sleep-and-pray<\/h2>\n
func TestCacheExpiry(t *testing.T) {\n c := NewCache(50 * time.Millisecond)\n c.Set("k", "v")\n time.Sleep(60 * time.Millisecond) \/\/ hope the CI box isn't loaded\n if _, ok := c.Get("k"); ok {\n t.Fatal("expected key to be expired")\n }\n}\n<\/code><\/pre>\n60ms<\/code> is a bribe. Too short and the test fails on a busy CI runner. Too long and your whole suite drags. There’s no correct value, only values that fail a bit less often.<\/p>\ntesting\/synctest<\/code> from an experiment to a real package, and it ends the bribery:<\/p>\nfunc TestCacheExpiry(t *testing.T) {\n synctest.Test(t, func(t *testing.T) {\n c := NewCache(50 * time.Millisecond)\n c.Set("k", "v")\n time.Sleep(60 * time.Millisecond) \/\/ virtual time: instant and exact\n if _, ok := c.Get("k"); ok {\n t.Fatal("expected key to be expired")\n }\n })\n}\n<\/code><\/pre>\ntime.Sleep<\/code> doesn’t wait 60 real milliseconds. It advances a virtual clock the instant every goroutine in the bubble is blocked, so the test is deterministic and finishes in microseconds. There’s also synctest.Wait<\/code>, which blocks until every other goroutine in the bubble is idle, so you can check state at an exact point without racing it. The Go blog’s synctest write-up<\/a> and the testing\/synctest docs<\/a> cover the full rules, including which operations are allowed to cross the bubble boundary. One note if you used the experimental version: the old synctest.Run<\/code> is deprecated, and synctest.Test<\/code> is the API to write against now.<\/p>\nThe patterns Go 1.25 didn’t fix<\/h2>\n
WaitGroup<\/code> is coming to the rescue.<\/p>\nerrgroup<\/code> waits for the goroutines it started. It has no idea about the one you spawned with a bare go<\/code> and a channel it will block on until the heat death of the process. Every goroutine still needs a clear answer to one question: what guarantees this ends? Usually the answer is a context, which means a context has to actually reach it.<\/p>\nerrgroup.WithContext<\/code> only cancels siblings if you thread its ctx<\/code> all the way down to the call that actually blocks. A context that stops at the first function boundary is decoration. I’ve started treating a missing ctx<\/code> argument on an I\/O function the way I treat an ignored error return, a habit I wrote up properly in my post on Go error handling patterns<\/a>.<\/p>\nWhat to do this week<\/h2>\n
grep -rn \"wg.Add(1)\" .<\/code>. Every hit is a tiny migration. If those goroutines can’t fail, swap the block for wg.Go<\/code>. If they can, you probably wanted errgroup<\/code> the whole time. Then pick your slowest concurrency test, the one with a time.Sleep<\/code> you’ve quietly resented for months, and move it into a synctest.Test<\/code> bubble. None of this is a rewrite. It’s an afternoon of work, and it’s the same unglamorous cleanup I end up doing on most client codebases I take on<\/a>: you finish with less code that does the same job and leaves fewer dark corners for bugs to sit in.<\/p>\n","protected":false},"excerpt":{"rendered":"