Live data from Hacker News

Zig's new CLI progress bar explained

andrewkelley.me

11–20 of 43 posts

Re: Zig's new CLI progress bar explained

#11
post #2

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

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

Re: Zig's new CLI progress bar explained

#12
post #2

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

0.12 is meant to be the version that you can probably stop tracking master.

It isn’t stable, but it is.

Re: Zig's new CLI progress bar explained

#13
post #7
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.

" 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

I agree that this was neither my finest nor most constructive comment.

Re: Zig's new CLI progress bar explained

#14
post #2

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

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 underestim…

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.

Re: Zig's new CLI progress bar explained

#15
post #4

Earlier quoted context omitted.

I highly doubt that was serious. I think you just missed the joke. Or did I miss something? I really hope I didn’t :(

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!

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.

Re: Zig's new CLI progress bar explained

#16
post #4

Earlier quoted context omitted.

I highly doubt that was serious. I think you just missed the joke. Or did I miss something? I really hope I didn’t :(

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!

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.

Re: Zig's new CLI progress bar explained

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

Re: Zig's new CLI progress bar explained

#18

Earlier quoted context omitted.

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!

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.

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

Re: Zig's new CLI progress bar explained

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

Re: Zig's new CLI progress bar explained

#20
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).
Post reply on HN