[HN Gopher] Zig's new CLI progress bar explained
___________________________________________________________________
Zig's new CLI progress bar explained
Author : fmystic
Score : 91 points
Date : 2024-05-30 04:07 UTC (2 days ago)
(HTM) web link (andrewkelley.me)
(TXT) w3m dump (andrewkelley.me)
| lionkor wrote:
| I really enjoy reading Zig, I always struggle writing it because
| its so subtly different from the other languages I use, like C,
| Rust and Go, that I get confused often.
|
| I really hope Zig becomes stable soon so I can use it on non-
| throwaway projects
| voidhorse wrote:
| My experience is exactly the same. It deviates just enough in
| really minor ways that it becomes difficult to write. There's a
| lot of upfront effort to unlearn all the syntactic patterns
| that have already been established, the fact that the
| differences are really small makes it harder, not easier.
|
| I think the language design includes a lot of good
| justification for these choices, but I worry they might have
| underestimated the sheer power of habit and historical
| precedence.
| wredue wrote:
| Personally, I do not find that zig differs from other
| languages all that greatly.
|
| I am actually a little curious about the minor and subtle
| differences, cause I personally did not find that this was
| the case coming from C, Java, C#, a little rust, COBOL and
| NATURAL.
|
| Edit:
|
| I do admit that you need to understand what said other
| languages are doing in order to accomplish things. No hidden
| flow definitely increases a bit of the surface area of the
| code, but if you understood how other languages accomplish
| the stuff they hide form you, then zig does not feel like it
| has minor differences.
| mr90210 wrote:
| > I really hope Zig becomes stable soon so I can use it on non-
| throwaway projects
|
| This may or may not give you some comfort, but I recall hearing
| one of the core maintainers of Zig talking about its use at
| Amazon to leverage its cross platform capabilities.
| wredue wrote:
| 0.12 is meant to be the version that you can probably stop
| tracking master.
|
| It isn't stable, but it is.
| thefaux wrote:
| 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.
| YuukiRey wrote:
| I highly doubt that was serious. I think you just missed the
| joke.
|
| Or did I miss something? I really hope I didn't :(
| AndyKelley wrote:
| It's amusing to me that multiple people on HN think I'm
| joking. Have you ever tried to write thread-safe, lock-free,
| infallible, non-heap-allocating code before?
|
| I'm curious what kind of API the people who think this
| problem is easy would have come up with, and what its
| performance characteristics would be compared to mine.
|
| I had a blast working on this problem!
| YuukiRey wrote:
| I think the part that might raise eyebrows is the
| "programming language designed for making perfect
| software". Perfect is, after all, highly subjective, yet at
| the same time a maybe unnecessarily hyperbolic term.
|
| I don't mind the language though. I have no doubt that
| you're at the top of your game and the problems you've
| outlined in the post do indeed sound challenging.
| AndyKelley wrote:
| https://youtu.be/Z4oYSByyRak?t=161
|
| Software Should Be Perfect - A journey of questioning
| assumptions and building a new programming language
|
| This has been my goal since the beginning. I wasn't
| kidding
| thefaux wrote:
| I agree that this is not an easy problem. I have written a
| status bar for a fairly widely used open source build tool
| in java. I hijacked System.out and System.err globally and
| added all writes to a queue that I line buffered and
| interleaved progress bars at the bottom. There was no
| noticeable performance degradation relative to not having
| the progress bar since all the queue management was handled
| on a background thread. I would characterize the volume of
| output as medium. The tool is chatty compared to some, but
| we aren't talking about managing massive amounts of data
| coming in.
|
| At some point though, I stopped working on this tool
| because it and the compiler it was primarily used for were
| way too slow and started focusing on compiler design. I am
| currently working on a compiler that is self hosted and
| compiles itself in 1 second but I expect to get that down
| to under 100ms.
|
| You don't need progress bars when your build is that fast.
|
| I was undeniably rude in my initial post, but I also want
| to challenge you to be even better as a programmer. I had
| to write many compilers before I figured out how to self
| host as quickly as I now can. That is the advantage of
| working in isolation. I have thrown out more working
| compilers than all but a handful of people have written. My
| language is not public because I am still iterating but I
| wrote the bootstrap compiler in about 10 days of 4-5 hours
| per day and the self-hosted compiler took about 3 more
| weeks on top of that. It is ~4200 lines of code in itself.
| The next version will likely be fewer.
| vitaminCPP wrote:
| it's a joke. Obviously, when you're a compiler engineer,
| creating a progress bar is not a great demonstration of your
| skill.
| chipweinberger wrote:
| I think it's fun and enjoy reading it.
| dang wrote:
| " _Please don 't pick the most provocative thing in an article
| or post to complain about in the thread. Find something
| interesting to respond to instead._"
|
| https://news.ycombinator.com/newsguidelines.html
| thefaux wrote:
| I agree that this was neither my finest nor most constructive
| comment.
| ximeng wrote:
| The visualisation is really neat.
|
| Would be interesting to have a mechanism to track runtime of each
| step and compare across runs (maybe with a unique generated
| key?), so that you could benchmark speed up and slow down. This
| would enable per time rather than per step progress bars.
| ai_ wrote:
| 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't too much
| of an issue since the information is all still in the same place
| and it's not actually changing too much between each stage. I can
| identify each step, figure out what's changing between them, and
| look for that information specifically.
|
| The new progress system dumps _a lot_ more information at the
| user, most of it detailing what file is being analyzed and
| compiled, each one taking maybe 2-4 frames of screen time, on an
| excessive number of lines, just a complete barrage of pointless
| information. None of this is really important to me since the
| only time it would be important is if a file or step took more
| than 3 seconds to be processed. With items constantly appearing
| and disappearing, the things that are taking time on the more
| macro scale like build-lib and build-exe steps that are more
| important to me will constantly move around the terminal. It 's
| much much harder to read something if it's jumping up and down
| randomly every 2 frames vs if it's being swapped to share a
| single line. If the line literally leaves my field of view, it
| becomes frustrating to follow.
|
| I much prefer the Bazel approach to this problem. When running a
| series of actions concurrently, the 6 actions taking the most
| amount of time will be visible in the action list showing how
| long they're taking, but all other actions will be minimized to a
| "and X other actions..." line.
|
| This looks cool on the surface, but in practice is not that good
| at giving you progress information. Which is what progress
| indicators should do! At best this is a better indicator of how
| much work is being done, not how much progress is being made.
| Like a bunch of bleeps, bloops, and random LEDs toggling when a
| computer does work in a sci-fi TV show.
|
| I think this would be better if individual files being processed
| got removed unless they start taking too long. Keep the build-exe
| and build-lib steps around but make them a little sticky. When
| they complete, have it say "Done" and then remove things in
| groups or on a set interval. Don't change the number of lines too
| often and don't reorganize lines either. Generally, it should be
| easy to parse what's going on and frequent changes to the number
| of lines and how much information is on each makes that hard.
| epage wrote:
| This is really good feedback! I'm looking at redesigning
| Cargo's output (after I wrap up other projects).
| Groxx wrote:
| I wish all multi-task systems had a UI like this. It makes it SO
| much easier to spot where your biggest latencies are coming from,
| which is an excellent passive motivator to improve them.
|
| Silent / opaque progress just teaches people that they can't do
| anything about it except wait, so all it does is get worse and
| worse.
___________________________________________________________________
(page generated 2024-06-01 23:00 UTC)