> The only point of the program is to print the output.
A consistent structure helps humans parse the output. I have host(1)'s output order in my mental memory.
A consistent structure helps humans parse the output. I have host(1)'s output order in my mental memory.
Or you could just use a sync.WaitGroup and not print anything until all the results are in, which is what the proposed design does anyways in the case where an early request is the slowest to resolve.
Why not wait? Because it’s nice to see results as they come in.
Yes, there are pathological possibilities here, if an early request is slow. But this complaint sounds like a complaint about the author’s goals, which are stated clearly enough. “The author has the wrong desires or goals”, your comment seems to say.
A sync.WaitGroup is as fast as the proposed behavior, for what it's worth, and doesn't have the ordering complexity.
He gives the requirements: Execute in parallel, print in order as quickly as possible. That’s the premise. The point of the article is in how to achieve that, not whether you should.
“Print as soon as possible and ignore ordering” is not a challenge nor an interesting topic to write an article about.