Hacker News Reader

Comment by dadkins | Hacker News Reader

There's a library for that pattern: 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()

View on HN

I'm embarrassed how many times I've implemented the above without thinking to look for a standard lib solution. Thanks!

Nice. Yeah I'm very new to Go so I know almost nothing about the stdlib libraries. Thanks for the pointer.

Tooting 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

You 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.

That 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.)

Yes, but outside the Go standard libraries, adding a dependency on a standard library isn't a big deal and won't add a cycle.

Yes. 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.

Looks interesting (thanks). Will certainly check it out.

Even 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.

Why 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.

If 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.

I didn't claim I could. Take your trolling elsewhere.

Reply on news.ycombinator.com