I thought exactly the same thing. I use errgroup in practically every Go project because it does something you'd most likely do by hand otherwise, and it does it cleaner.

I discovered it after I had already written my own utility to do exactly the same thing, and the code was almost line for line the same, which was pretty funny. But it was a great opportunity to delete some code from the repo without having to refactor anything!

> and the code was almost line for line the same, which was pretty funny.

One of the core strengths of Go is that it fits the zen of Python's " There should be one-- and preferably only one --obvious way to do it" and it does this very nicely.

The extended standard lib is pretty great, but definitely can't keep the Go compatibility promise, so it's good that it's separate.

>golang.org/x/ is stuff that should be in the standard library but isn't, for some reason

think of it as testing/staging before being merged into stable stdlib

I do believe it’s backwards compatibility and evolving APIs

Except that it's a little bit too convenient, and highly useful things like errgroup stay there instead of having been adopted into the stdlib.

Wow how did I not know of this?!

How does it cancel in-progress goroutines when the provided context is cancelled?

They have to all use the special context.

They just need to be context aware, or call context-aware things.

Ok so no magic goroutine interruption, just contexts all the way down.

Still, this is nicer than hand-rolling a WG every time.

I never used errgroup but I realize that it's essentially the same what I end up implementing anyways.

With standard waitgroups I always move my states as a struct with something like a nested *data struct and an err property which is then pushed through the channel. But this way, my error handling is after the read instead of right at the Wait() call.

Looks like this isn’t usable with functions that take parameters. For that, you need wg.Add.