“is bad tho?” is comic hyperbole. Sorry, I don’t mean to dismiss their work. I just am not impressed that their patterns are particularly elegant. It seems like just as much boilerplate as errgroup and not especially more power. (It’s better than pure stdlib of course, but that’s a low bar.)
You can also do all of them with pure channels/sync.WaitGroup. The point is to do them concisely. errgroup is pretty good, but still too much boilerplate. Also it only returns the first error in a set, so it does something different, and it doesn’t really help you write the code in the third example where you’re collecting results and spawning new tasks.
would be neat to see comparisons with errgroup in your readme, since my immediate impression was also “the main benefit is that it returns errors”. might help emphasize the other benefits
Maybe I am missing something, but couldn’t just not use panic? I get the feeling the author does more with concurrency than I have experience with, but I after years and years of programming in Go I have never felt the need to make the thing panic in certain circumstances. I always saw panic and the recovery mechanism as a very halfhearted attempt to “exceptions, but not exceptions” that never should have made it past the 1.0 release.
In my experience, the main source of panics is things like nil pointer and out of bounds errors rather than deliberate panics. On top of that, an uncaught panic in a goroutine will terminate the process, so for robustness you do still need to worry about panics.
Conc is bad tho?
I made a much simpler API: https://github.com/carlmjohnson/workgroup
I tried to write some comparisons to conc, but all of the conc code is too convoluted and does the wrong thing, so I couldn’t.
That’s not a very charitable take on
conc.without anything to back this up, this reads like FUD.
The workgroup library you published might be better than conc, but no need to disparage the work of someone else to promote yours.
“is bad tho?” is comic hyperbole. Sorry, I don’t mean to dismiss their work. I just am not impressed that their patterns are particularly elegant. It seems like just as much boilerplate as errgroup and not especially more power. (It’s better than pure stdlib of course, but that’s a low bar.)
Looking at your examples, I’d reach for
x/sync/errgroupfor all of those.You can also do all of them with pure channels/sync.WaitGroup. The point is to do them concisely. errgroup is pretty good, but still too much boilerplate. Also it only returns the first error in a set, so it does something different, and it doesn’t really help you write the code in the third example where you’re collecting results and spawning new tasks.
would be neat to see comparisons with errgroup in your readme, since my immediate impression was also “the main benefit is that it returns errors”. might help emphasize the other benefits
Maybe I am missing something, but couldn’t just not use
panic? I get the feeling the author does more with concurrency than I have experience with, but I after years and years of programming in Go I have never felt the need to make the thing panic in certain circumstances. I always sawpanicand the recovery mechanism as a very halfhearted attempt to “exceptions, but not exceptions” that never should have made it past the 1.0 release.In my experience, the main source of panics is things like nil pointer and out of bounds errors rather than deliberate panics. On top of that, an uncaught panic in a goroutine will terminate the process, so for robustness you do still need to worry about panics.