Go Routines

2 min read


Another solution to the WaitGroup mistake

Join me again, this coming Friday, August 22, at 3:00pm EDT (19:00 UTC), more live coding. Subscribe on YouTube and hit the Notify me button so you don’t miss it! Last week we looked at a common mistake with sync.WaitGroup, and how Go 1.25’s new go vet check can help catch it. To recap, the mistake is calling wg.Add(1) from within a goroutine, which can cause wg.Wait() to return prematurely:

Go Routines

2 min read


A common WaitGroup mistake

Can you spot the mistake in this code? for i := range 100 { go func() { wg.Add(1) defer wg.Done() fmt.Println(i) }() } wg.Wait() At first glance, this code probably looks fine. We’re calling wg.Add(1) at the beginning of each task. We’re deferring the call to wg.Done(), so it’s called when the function exits. Each Add call has a matching Done call. We’re properly waiting for all tasks to complete with wg.

Other

2 min read


Go 1.25 is here!

Join me tomorrow, Friday, August 15, at 3:00pm EDT (19:00 UTC), for a live stream where I’ll be building a new feature in my open-source project. Subscribe on YouTube and hit the Notify me button so you don’t miss it! So I’m taking a short break from talking about goroutines (mostly) to mention the relese of Go 1.25! Go 1.25 is a rather insignificant release, in the grand sceme of things.

Go Routines

2 min read


Dynamic wait groups

Join me this Friday, August 15, at 3:00pm EDT (19:00 UTC), for a live stream where I’ll be building a new feature in my open-source project. Subscribe on YouTube and hit the Notify me button so you don’t miss it! One thing we can do with sync.WaitGroup, that may not be immediately obvious, is to call Add from within a goroutine that’s managed by the wait group itself: wg := &sync.

Subscribe to Boldly Go: Daily

Every day I'll send you advice to improve your understanding of Go. Don't miss out! I will respect your inbox, and honor my privacy policy.

Unsure? Browse the archive.

Go Routines

2 min read


WaitGroup shortcuts

Join me next Friday, at 3:00pm EDT (19:00 UTC), for a live stream where I’ll be building a new feature in my open-source project. Subscribe on YouTube and hit the Notify me button so you don’t miss it! Yesterday I introduced the sync.WaitGroup type. Today I want to look at some possible ways to improve the same code. First, the code as we left off yesterday: wg := &sync.WaitGroup{} for i := range 10 { wg.

Go Routines

2 min read


sync.WaitGroup

It’s been a year since my last live stream, as I was moving across the globe. I’m finally settled (enough) to start up again. Join me, as I’ll begin building a new feature in my open-source project. The next session will be August 15, at 19:00 UTC. Subscribe on YouTube and hit the Notify me button so you don’t miss it! Yesterday we wrote some Go code to wait for goroutines using a channel:

Go Routines

2 min read


Waiting for goroutines

Yesterday we looked at some sample code with goroutines: for i := range 10 { go func() { fmt.Println(i) }() } But if you ran it, you probably saw no output. This is because the main goroutine exits before the 10 new goroutines have a chance to run. How do we solve this? We need some sort of synchronization mechanism in place, to ensure we wait for all goroutines to finish before exiting the program.

Go Routines

3 min read


Goroutines

Today I’m starting a new series of posts on the topic of goroutines. In the past, I’ve mostly walked through existing documentation (the Go spec, docs for standard library packages, etc), and provided my commentary and explanation. Starting today, instead, I’ll be going on a topical journey through goroutines. I will, of course, touch on the spec, and some standard library packages, but I’ll be taking my own path through the topic.


Dependency pinning

Today I want to share a trick I stumbled upon. It won’t matter to most of you. If it does matter to you, it will probably save you a bunch of headaches! First, some background. Have you ever had to use an outdated dependency for $REASONS? If not, you can skip today’s email, unless you’re just curious. One of my clients is still using MongoDB 3.2. MongoDB was EOLed more than a year before anyone had ever heard the term “COVID”.


Why is context.TODO not just a comment?

I’ve been on vacation for the last week, so haven’t written much. Let’s finally finish up the context package series with some reader feedback and questions! Joost Helberg wrote in with an interesting observation about context.TODO. In his own words: With regards to context.TODO, back in my early Go days, I thought the TODO was about the intent of this context. Like context.Background is for a background task and context.WithCancel for a job that can be canceled.


context.WithoutCancel

This is it! The last of the context package functions that we will cover in this series. Well, almost. I actually have a couple reader feedback and question emails to respond to, which I’ll do next, before startinga a new series. Speak of a new series: I’m still looking for suggestions! I have a couple ideas, but I’d rather do something you’re itching to learn about, than whatever random idea I come up with.