Zig's new CLI progress bar explained • Hacker News Board

Re: Zig's new CLI progress bar explained

#41

Post by sandywaffles » Mon, Jun 03, 2024, 1:53 PM UTC

epage wrote: post #20

ai_ wrote: post #17

I'm not sure if it's actually any easier to read. When lots of things are changing it honestly becomes harder to read and figure out what's important and what's superfluous. With the old progress system, everything was on one line. This honestly isn't horrible to me since I can easily glance text from left to right to figure out what the gist of the text is. When it's changing between the same two steps it still isn'…

This is really good feedback! I'm looking at redesigning Cargo's output (after I wrap up other projects).

Less is more; worse is better. I don't remember where I originally saw it, but some rules of thumb that seem to serve well are:

- information shown to the user should be able to be consumed; if it's too fast to read and not displayed in perpetuity (e.g. logged once complete) it's essentially just unnecessary movement akin to a really noisy "spinner"

- no new "movement" (e.g. spinnner/progress esque) within ~200ms will result in the user thinking something is hung

- every permanent line away from input command prompt is sacred; e.g. too much movement vertically (e.g. spamming logs) should be reserved for "verbose" output where the user explicitly asks for it. The effort by the user to scroll the buffer afterwards should be worth it.

The new zig progress IMO breaks a these rules and I'm not a huge fan of it except out of novelty in design.

Cargo's current output essentially only breaks the vertical scrolling rule; if I were BDFL I'd probably just use a single line indicatif spinner ephemerally instead of displaying all "downloading" and "compiling" lines unless someone asked for a "verbose" output and wanted to actually see those lines logged. It could be argued that using a tree of indicatif spinners for long running parallel tasks might be interesting? But determining what is "long running" would be extremely difficult to know ahead of time, and accidentally making an 8-frame spinner would just appear like useless noise. Add to that the max parallelization with Rust, especially in debug builds can be quite high which would end up looking much like the this zig output where 99% of the lines only last for a few frames.

Re: Zig's new CLI progress bar explained

#42

Post by geon » Tue, Jun 04, 2024, 1:07 PM UTC

thefaux wrote: post #3

Unsolicited writing advice: drop the self-aggrandizing grandiosity. It is distracting and undermines the work itself. Zig is a language for writing perfect programs? The fact that a progress bar is needed at all is a symptom of the lack of perfection of Zig. A perfect compiler would compile instantly (or at least faster than human perception is capable of registering) with no need for a progress bar.

> A perfect compiler would compile instantly (or at least faster than human perception is capable of registering)

That seems lika a very arbitrary requirement. I'd say a perfect implementation of anything must do what it is supposed to be doing, and that may have a lower bound on processing time. You can't write to memory faster than what the bus allows, for example.

Re: Zig's new CLI progress bar explained

#43

Post by wging » Wed, Jun 05, 2024, 3:16 AM UTC

sandywaffles wrote: post #41

epage wrote: post #20

Earlier quoted context omitted.

This is really good feedback! I'm looking at redesigning Cargo's output (after I wrap up other projects).

Less is more; worse is better. I don't remember where I originally saw it, but some rules of thumb that seem to serve well are: - information shown to the user should be able to be consumed; if it's too fast to read and not displayed in perpetuity (e.g. logged once complete) it's essentially just unnecessary movement akin to a really noisy "spinner" - no new "movement" (e.g. spinnner/progress esque) within ~200ms wil…

The vertical scrolling has the advantage that when you are watching a build go, and you see a certain step's taking a long time, it doesn't ever disappear from the terminal completely. You don't need to look through dependencies some other way and figure out which matches the thing you saw, or do a clean build to see the bottleneck again, etc.