4 ms·
There's a library for that pattern: http://golang.org/pkg/sync/#WaitGroup http://golang.org/pkg/sync/#WaitGroup Instead of counting and using a done channel,
by dadkins 14y ago
There's a library for that pattern:
http://golang.org/pkg/sync/#WaitGroup http://golang.org/pkg/sync/#WaitGroup
Instead of counting and using a done channel,
import "sync"
...
var wg sync.WaitGroup
for ... {
wg.Add(1)
go dowork()
}
wg.Wait()
- jameskilton 14y agoNice. Yeah I'm very new to Go so I know almost nothing about the stdlib libraries. Thanks for the pointer.
- darkhelmetlive 14y agoTooting my own horn here, but I'm working on a book covering the Go Standard Library. Still in progress, and not at the sync package yet, but it's coming along. Check it out if you feel inclined. http://thestandardlibrary.com/go.html http://thestandardlibrary.com/go.html
- lsb 14y agoYou know what'd be cool? To take arbitrary code in a language, pattern match on the implementation in that language of each std lib function, and actively recommend substitutes for duplicated code.
- jlgreco 14y agoThat would be very cool. I wonder how hard it would be though. At least in Go I know that the standard lib contains lots of duplicate code (primarily so that things that should be small don't require larger things as dependencies. I think the time package's String() functions use reimplemented fmt package functionality for example, since fmt is a much larger dependency than time should have.)
- skybrian 14y agoYes, but outside the Go standard libraries, adding a dependency on a standard library isn't a big deal and won't add a cycle.
- jlgreco 14y agoYes. What I mean though is that if you are reimplementing, say, fmt.Printf, such a suggestion system might correctly suggest you use fmt.Printf instead, but also suggest you can use func (m Month) String() string from time, or something equally silly. Since the standard libs in Go duplicate code, you would have to be careful that your suggestion system isn't picking up false positives. I think the idea has a lot of promise though.
- stock_toaster 14y agoLooks interesting (thanks). Will certainly check it out.
- zmj 14y agoI'm embarrassed how many times I've implemented the above without thinking to look for a standard lib solution. Thanks!
- 0xABADC0DA 14y agoEven so why would you write that boilerplate code out each time? Something like this would work even better: result = src.asyncMap { |e| dowork(e) }; Except Google Go returns several values instead of tuples, so you can't just collect all the results as-is. And with no generics it would be annoying to actually use e and the result, since they would need casts. Too bad.
- burntsushi 14y agoWhy am I not surprised to see you trolling HN too? What's all too sweet is that you've brought your anti-Go zealotry here too! Joy. > Except Google Go returns several values instead of tuples, so you can't just collect all the results as-is. This is false. Functions in Go do not have to return multiple values. Therefore, you can "collect all the results as-is". > And with no generics it would be annoying to actually use e and the result, since they would need casts. Too bad. Actually, it wouldn't be annoying, because you wouldn't use a general purpose map like you've shown. You'd use code shown in the parent.
- 0xABADC0DA 14y agoIf you think you can do asyncMap in Google Go, without casts and without manually collecting multiple return values, by all means show us the code. I would find that really interesting.
- burntsushi 14y agoI didn't claim I could. Take your trolling elsewhere.