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.

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.

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.


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.


context.WithValue

func WithValue func WithValue(parent Context, key, val any) Context WithValue returns a derived context that points to the parent Context. In the derived context, the value associated with key is val. Use context Values only for request-scoped data that transits processes and APIs, not for passing optional parameters to functions. The provided key must be comparable and should not be of type string or any other built-in type to avoid collisions between packages using context.


context.TODO

We’re almost done going through the context package. What would you like me to cover next? If you have a suggestion, hit reply, and let me know! – func TODO func TODO() Context TODO returns a non-nil, empty Context. Code should use context.TODO when it’s unclear which Context to use or it is not yet available (because the surrounding function has not yet been extended to accept a Context parameter).


context.Background

After this detour through context key types, let’s get back to the GoDoc for our context package. Next up: context.Background(): func Background func Background() Context Background returns a non-nil, empty Context. It is never canceled, has no values, and has no deadline. It is typically used by the main function, initialization, and tests, and as the top-level Context for incoming requests. Why would you ever want a context that essentially does nothing?