That return err from the goroutine looks wrong, I don't think the error is ever used. log.Fatalln(err) would keep the behavior of the V code.

It'd just cause a panic and stop that particular goroutine. To properly handle it, it needs to be passed back into a results channel or something. Generally we don't intentionally cause panics in go code as a matter of style.

You can insert a `defer log.Println(err)` if you want to handle that particular error but I didn't bother.

log.Fatalln() does an os.Exit(1), it doesn't just cause that particular goroutine to stop[1]. log.Panicln() will also cause the entire program to exit unless there's a recover[2].

log.Println(err) would be better than returning err, because returning err makes people wrongly think the error is being handled somewhere, when in reality nothing is looking at the return value. Using defer for that seems a bit strange though.

[1] https://play.golang.org/p/wwiq1bYjwVH

[2] https://play.golang.org/p/MpzafFlBSfx

Agreed, that is much more idiomatic.