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()

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.

I know it's about Go, but bash is awesome for stuff like this:

   while read line; do
   host $line | head -n1 | awk '{print $1 " -> " $4}' &
   done < domains.txt

I realize it's a one-off, but you could potentially mix lines of output with a script like that.

If you gnu parallel (xargs++) installed - turn that second line into a script (and replace $line with $1).

  cat domains.txt | parallel -n 1 -P 50 script.sh

Notice that with parallel, you don't need the -n 1, since that's the default.

Ah, didn't realize that - throwback to my xargs days! Thanks for the tip.

Thanks for the note on parallel, it looks to be an excellently useful tool. I can find a lot of ways to save time with it.

FYI: On OSX, there is a Homebrew formula (brew install parallel).

If you are looking for which domain point to 1.2.3.4:

   cat domains.txt | parallel -P 100 --tag host | grep 1.2.3.4

Somewhat slower runtime than the go-solution, but may be faster to write.

You don't need to spawn N awks,

  <domains.txt while read line; do
    host $line | head -n1 &
  done | awk '{print $1 " -> " $4}'

So many ignored errors. :(

This is one of the things I love about go. If he wants the return value but doesn't want to address the errors, he has to actively do it. It makes you think twice when you are putting a _ for an error return. And now to another programmer coming in to maintain it, they stick out like a sore thumb.

I know zero Go (it's a little far down on the to-learn list), and maybe he edited it, but I went back and read the GP's code and didn't see anything that looked like ignoring errors.

Is it the two ", _" things?

So for this line of code:

file_in, _ := ioutil.ReadFile("domains.txt")

It says call ReadFile. In go a function can return multiple values. ReadFile returns an byte array and an error value. Normally you'd check to see if err is nil, if it is then no error happened. If it isn't you can check it out for information about the error and handle it.

A unique feature about go is that declaring a variable and never using it is an error and not a warning. Actually there aren't even compiler warnings. Either it is right or wrong. This means if he had called:

file_in, err := ioutil.ReadFile("domains.txt")

but never checked err it would not build. So to get the byte array but not the error you use the _ symbol to tell it to throw away that return value. This is what I was on about in that you have to actively ignore error handling if you want a return value.

> A unique feature about go is that declaring a variable and never using it is an error and not a warning. Actually there aren't even compiler warnings. Either it is right or wrong.

Ahhh. Nice. That sounds like a feature I could get behind, too. Thank you.

It seems tantalising for the compiler to also protest when return values of type error are not assigned to anything. An obvious inconvenience being that use of fmt.Println and similar would suddenly become noisy.

It's a one-off script, I didn't really care about errors. If this was something run regularly inside of a bigger application yes I'd have full error handling.

But tiny throwaway scripts get built up into huge applications all the time, sometimes by other people who don't have the mental TODO to go back and handle errors.