5 ms·
> this is not a hard problem to solve in idiomatic Go. Genuinely asking, what would the solution look like in idiomatic Go? Let's assume for a second that the
by noapologies 2y ago
> this is not a hard problem to solve in idiomatic Go.
Genuinely asking, what would the solution look like in idiomatic Go?
Let's assume for a second that the premise of the article is valid and exactly the behavior we want - "asynchronous execution but to report the results in order, as each becomes available".
- logicchains 2y agoSend the results into a channel, with a separate goroutine that polls the channel, stores a buffer of results, and sorts and prints the latest results at a regular interval.
- jcparkyn 2y ago> sorts and prints the latest results at a regular interval Slightly more complicated than that, because you can only sort and print elements once you have _all_ the elements that came before them. Once you add that layer you've got quite a lot more code (and potential for mistakes) than the promises version.
- kbolino 2y agoYou could also have N channels, one for each argument, and use reflect.Select to receive the results as soon as available, waiting to print any result until all of its predecessors have come in. You could also have a mutex-guarded block at the end of every worker goroutine to do the printing and a sync.WaitGroup to follow the workers in main.
- yencabulator 2y agoNo need for reflect.Select, just loop through the channels and wait on each. That'll do your "predecessors" part just by the sake that it's an in-order for loop.
- kbolino 2y agoYou're right, and for some reason I thought that solution had been ruled out.
- binary132 2y agoNo. Channels sent over channel is the correct idiom here. No need for a sort.
- deleted 2y ago[deleted]