Waitgroups: What They Are, How to Use Them and What Changed with Go 1.25

> wg := sync.WaitGroup{}

just `var wg sync.WaitGroup`, it is cleaner this way

Personally I wished they had it backported to previous versions too, because it's rather convenient!

What is quite sad is that we cannot add it ourselves as it's so simple of what they have done:

    func (wg *WaitGroup) Go(f func()) {
        wg.Add(1)
        go func() {
            defer wg.Done()
           f()
        }()
    }

  package main
  
  import (
    "sync"
    "time"
  )
  
  type WaitGroup struct {
    sync.WaitGroup
  }
  
  func (wg *WaitGroup) Go(fn func()) {
    wg.Add(1)
    go func() {
      defer wg.Done()
      fn()
    }()
  }
  
  func main() {
    var wg WaitGroup
    wg.Go(func() { time.Sleep(1 * time.Second) })
    wg.Wait()
  }

This means you can't pass variables in as function arguments. Even the example in the official go docs doesn't handle the scope correctly:

  func main() {
   var wg sync.WaitGroup
   var urls = []string{
    "http://www.golang.org/",
    "http://www.google.com/",
    "http://www.example.com/",
   }
   for _, url := range urls {
    // Launch a goroutine to fetch the URL.
    wg.Go(func() {
     // Fetch the URL.
     http.Get(url)
    })
   }
   // Wait for all HTTP fetches to complete.
   wg.Wait()
  }

https://pkg.go.dev/sync#example-WaitGroup

You need to use this pattern instead:

   for _, url := range urls {
    url := url
    // ...

    for _, url := range urls {
        wg.Go(func(u string) func() {
            return func() {
                http.Get(u)
            }
        }(url))
    }

I like WaitGroup as a concept, but I often end up using a channel instead for clearer error handling. Something like:

  errCh := make(chan error)
  for _, url := range urls {
    go func(url string){
      errCh <- http.Get(url)
    }(url)
  }

  for range urls {
    err := <-errCh
    if err != nil {
      // handle error
    }
  }

Should I be using WaitGroup instead? If I do, don't I still need an error channel anyway—in which case it feels redundant? Or am I thinking about this wrong? I rarely encounter concurrency situations that the above pattern doesn't seem sufficient for.

  errCh := make(chan error, len(urls))

Forgive a bit of ignorance, it's been a bit since I've touched Go, but this looks awfully similar to a Java CountdownLatch [1]. Is this just a glorified Go port of that or am I missing something vital here?

[1] https://docs.oracle.com/javase/8/docs/api/java/util/concurre...

Love this. Majority of concurrency in a usual web service is implemented using waitgroups IME (see below) This will greatly simplify it.

  var wg sync.WaitGroup
  wg.Add(1)
  go func(){
    callService1(inputs, outParameter)
    wg.Done()
  }
  // Repeat for services 2 through N
  wg.Wait()
  // Combine all outputs

BTW, this can already be done with a wrapper type

  type WaitGroup struct { sync.WaitGroup }

  func (wg *WaitGroup) Go(fn func()) {
    wg.Add(1)
    go func() {
      fn()
      wg.Done()
    }()
  }

Since you're doing struct embedding you can call methods of sync.WaitGroup on the new WaitGroup type as well.