News for hackers. Stuff that matters.
Re:Conc: Better Structured Concurrency for Go by Groxx on Wednesday January 11, 2023 @06:58PM (#34346919)
https://github.com/sourcegraph/conc/blob/main/iter/iter.go#L...

    // Map applies f to each element of input, returning the mapped result.
    func Map[T, R any](input []T, f func(*T) R) []R {
     res := make([]R, len(input))
     ForEachIdx(input, func(i int, t *T) {
      res[i] = f(t)
     })
     return res
    }
Seems a little silly to farm that off to a custom func when you could just write the for-loop, but it's probably fine / may be no different in practice.

Let's go see what ForEach does, to make sure: https://github.com/sourcegraph/conc/blob/main/iter/iter.go#L...

    // ForEachIdx is the same as ForEach except it also provides the
    // index of the element to the callback.
    func ForEachIdx[T any](input []T, f func(int, *T)) {
     numTasks := runtime.GOMAXPROCS(0)
     numInput := len(input)
     if numTasks > numInput {
      // No more tasks than the number of input items.
      numTasks = numInput
     }
    
     var idx atomic.Int64
     // Create the task outside the loop to avoid extra closure allocations.
     task := func() {
      i := int(idx.Add(1) - 1)
      for ; i < numInput; i = int(idx.Add(1) - 1) {
       f(i, &input[i])
      }
     }
    
     var wg conc.WaitGroup
     for i := 0; i < numTasks; i++ {
      wg.Go(task)
     }
     wg.Wait()
    }
Yeah I'm gonna go with a giant nope. Getting that through review is rather concerning to say the least, for something you'd be basing your most-complex and most-needing-correctness code around.
Re:Conc: Better Structured Concurrency for Go by tjdevries on Wednesday January 11, 2023 @08:12PM (#34347706)
I'm not sure what you don't like? Sorry, must just be missing your point.
Re:Conc: Better Structured Concurrency for Go by kubanczyk on Thursday January 12, 2023 @05:45PM (#34361323)
I'm guessing it's about creating a GOMAXPROCS pool of goroutines which are then (wastefully) competing with each other for an atomic loop counter.

It got me curious what's faster when looping over a slice of million elements: to use a million separate goroutines or to use that pool.