3 ms·

> 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

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

tptacek 2y ago
Another way to think about this: if the only point of the program is to print the output, why not just serialize, or pipeline only one request past the current one? 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.
- klodolph 2y ago
  Why not serialize / just print one? Parallel is faster. 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.
  - tptacek 2y ago
    Is it faster? The design proposed deliberately withholds fast results in order to ensure they're printed in sequence. Anybody who has ever run "traceroute" knows what this UX is like. If I wasn't going full TUI, I would just print the results as they come in, on stderr (with an index number). A sync.WaitGroup is as fast as the proposed behavior, for what it's worth, and doesn't have the ordering complexity.
    - skywhopper 2y ago
      Dude, just accept the premise of the article. 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.
      - kaashif 2y ago
        Yeah, this is funny. It's like presenting someone with a thought experiment and them saying "yeah but that would never happen".

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

tptacek 2y ago

Another way to think about this: if the only point of the program is to print the output, why not just serialize, or pipeline only one request past the current one? 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.

klodolph 2y ago
Why not serialize / just print one? Parallel is faster. 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.
- tptacek 2y ago
  Is it faster? The design proposed deliberately withholds fast results in order to ensure they're printed in sequence. Anybody who has ever run "traceroute" knows what this UX is like. If I wasn't going full TUI, I would just print the results as they come in, on stderr (with an index number). A sync.WaitGroup is as fast as the proposed behavior, for what it's worth, and doesn't have the ordering complexity.
  - skywhopper 2y ago
    Dude, just accept the premise of the article. 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.
    - kaashif 2y ago
      Yeah, this is funny. It's like presenting someone with a thought experiment and them saying "yeah but that would never happen".