Hacker News Reader

Comment by tptacek | Hacker News Reader

I don't think this is defensiveness so much as that attempting to model promises in languages like Go will result in bad, nonidiomatic code, and that is a thing that happens semiregularly with Go in particular, as it has so many refugees from other languages with sharply different idioms.

Here, we're discussing implementing future structs just to print DNS results in order. I don't think the UX proposed in the post is good, but stipulate that it is; this is not a hard problem to solve in idiomatic Go.

View on HN

"refugees from other languages with sharply different idioms"

Reminds me of the time I had to decipher some numerical analysis code written in Common Lisp but in the style of Occam...

> refugees from other languages with sharply different idioms

Mostly Java or JavaScript devs unable to make a dent in their main programming language space looking for a shortcut to jump to a better paying job by pretending to make a huge difference to the other programming language. I cringe every time a frontend dev who hasn't fully grasped React yet utters the words "I hear Rust is the future. I am going to port a JS package to it..." They have already started making inroads into Golang with half-implemented modules.

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

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

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

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

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

You're right, and for some reason I thought that solution had been ruled out.

No. Channels sent over channel is the correct idiom here. No need for a sort.

Do you find OPs solution nonidiomatic? I do not. The sequence-number solution would probably have been fine too. How would an idiomatic solution look to you?

Reply on news.ycombinator.com