Readit News logoReadit News
tombert · 5 hours ago
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...

arccy · 4 hours ago
CountDownLatch looks like it can only count down? the go one you can add/remove at will
layer8 · 4 hours ago
Phaser [0] would be the more flexible equivalent in Java.

[0] https://docs.oracle.com/javase/7/docs/api/java/util/concurre...

tombert · 4 hours ago
You are right; it looks like a Phaser is a bit more analogous: https://docs.oracle.com/javase/8/docs/api/java/util/concurre...
xh-dude · 5 hours ago
Pretty much. It’s a counting semaphore underneath.
stefanos82 · 8 hours ago
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()
        }()
    }

evanelias · 8 hours ago
You can just use golang.org/x/sync/errgroup instead, which has always provided this style of use.

errgroup also has other niceties like error propagation, context cancellation, and concurrency limiting.

Cyph0n · 6 hours ago
Context cancellation is not always desirable. I personally have been bitten multiple times by the default behavior of errgroup.
porridgeraisin · 7 hours ago
errgroup cancels the whole task if even one subtask fails however. That is not desirable always.
CamouflagedKiwi · 5 hours ago
They basically don't backport anything for Go, but the quid pro quo for that is that the backwards compatibility is pretty strong so upgrades should be safe. I have seen one serious issue from it, but still it's the language I'm the most confident to do an upgrade and expect things to Just Work afterwards.
cedws · 8 hours ago
You can wrap WaitGroup if you really want to.
stefanos82 · 8 hours ago
Can you provide an example please?
danenania · 6 hours ago
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.

c0balt · 6 hours ago
You would probably benefit from errgroup, https://pkg.go.dev/golang.org/x/sync/errgroup

But channels already do the waiting part for you.

danenania · 5 hours ago
Thanks! looking into errgroup
javier2 · 6 hours ago
How you handle err here? If you return, the go routines will leak
danenania · 5 hours ago
Ah, good point—should be using a buffered channel to avoid that:

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

porridgeraisin · 7 hours ago
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.

nikolayasdf123 · 8 hours ago
> wg := sync.WaitGroup{}

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

fozdenn · 7 hours ago
doesn't this point to a bigger problem that there are two ways of doing the same thing?
unsnap_biceps · 5 hours ago
multiple ways of doing something isn't inherently bad.

For example, if you want to set a variable to the number of seconds in seven hours, you could just set the variable to 25200, or you could set it to 60 * 60 * 7. The expanded version might be clearer in the code context, but in the end they do exactly the same thing.

nikolayasdf123 · 7 hours ago
no. it is different thing. container-agnostic zero value vs struct init.
mr90210 · 7 hours ago
Oh you are one of those. The nit picker. This is not at a PR review mate.
nikolayasdf123 · 7 hours ago
"one of those", name calling, telling me what to say,

cool it down a little. touch some grass. and hopefully you will see beauty in Go zero-values :P

dwb · 7 hours ago
Why?
nikolayasdf123 · 7 hours ago
zero value. container-agnostic initialization. say your type is not struct anymore, you would not have to change the way you intialize it. what you care here is zero value, and let the type figure out that it is zero and use methods appropriately. and it is just more clean this way

here is google guideline: https://google.github.io/styleguide/go/best-practices#declar...

a-poor · 7 hours ago
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
    // ...

jeremyloy_wt · 7 hours ago
This isn’t necessary anymore as of Go 1.22

https://go.dev/blog/loopvar-preview

9rx · 6 hours ago
> This means you can't pass variables in as function arguments.

Well, you could...

    for _, url := range urls {
        wg.Go(func(u string) func() {
            return func() {
                http.Get(u)
            }
        }(url))
    }
> You need to use this pattern instead

Why? Seems rather redundant. It is not like WaitGroup.Go exists in earlier versions.