Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zig's new CLI progress bar explained

andrewkelley.me

Post reply on HN
Print view View original

21–30 of 43 posts

Re: Zig's new CLI progress bar explained

#21

Post by hansvm »

lionkor wrote: 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

Here's my opinion from the Zig evangelism strike force:

Aside from the removal of async (which was very disruptive for a few of my projects), the rest of the changes over the last few years have been minor. It takes a few hours once a year to update a few tens of thousands of lines of code to the new syntax, build system, and stdlib. The current 0.12.0 is supposed to be a semi-stable release for people to be happy with pre-1.0, reducing that effort further, and language stability is an express design goal, so once 1.0 hits (ETA 3-5yrs?) it'll almost certainly be good enough for you.

I do think the initial learning curve was higher than I would have expected for such a simple language. The docs are much better now, and there are more examples and learning resources (off-topic, definitely use the zig-help channel in their discord server). I just finished making a compelling enough prototype that $WORK wants to use Zig for some performance-critical software. I suspect it'll be easier for my team to learn than it was for me. We'll see (whether it succeeds or fails, that sounds like a fun first blog post).

Despite that higher-than-expected learning curve (which IMO was mostly because nuances like the in-memory representation of a 5-bit integer weren't documented, so you had to experiment to find out the exact behavior if you were doing anything "interesting"), once you've picked it up it really is a simple language. IMO it's worth pushing through. I've done hardly anything with Go yet, but Zig fits happily in the mind of this particular C/Rust/Forth/Scala/Python/... programmer. Pushing through the first ~100 Ziglings exercises might be a pretty fast way to work through most of the syntactic differences if you're already comfortable with C and Rust.

Or maybe your prior is that new languages need to prove themselves and stabilize a little longer before you sink time into them. That's fine too. I'm just commenting since you seem to be a bit on the fence and because I think it's better than your current impression of it is.

Re: Zig's new CLI progress bar explained

#22

Post by epage »

I've seen guides for detecting terminal support for colors, hyperlinks, emoji, etc but not "fancy" terminal control like this. Anyone know of any? In one CLI I work on, some others are concerned about the long tail of users and wanting to make sure no one has a bad experience by default.

Re: Zig's new CLI progress bar explained

#23

Post by rockorager »

epage wrote: post #22

I've seen guides for detecting terminal support for colors, hyperlinks, emoji, etc but not "fancy" terminal control like this. Anyone know of any? In one CLI I work on, some others are concerned about the long tail of users and wanting to make sure no one has a bad experience by default.

This isn't using any "fancy" terminal features, aside from the synchronized update sequences (which terminals that don't support typically will ignore, though windows has a special case where it must be ignored). That said, you can query the terminal for support for this sequence if you wanted to.

Other than that, it's using standard ANSI sequences: `\r` to return the cursor to the beginning of the line, `\x1bM` (Reverse Index) to move the cursor up a single line (repeated n times), and then `\x1b[J` to clear the screen below the cursor position. All of these are sequences defined at least since the VT220, probably the VT100.

Re: Zig's new CLI progress bar explained

#24

Post by epage »

rockorager wrote: post #23
epage wrote: post #22

I've seen guides for detecting terminal support for colors, hyperlinks, emoji, etc but not "fancy" terminal control like this. Anyone know of any? In one CLI I work on, some others are concerned about the long tail of users and wanting to make sure no one has a bad experience by default.

This isn't using any "fancy" terminal features, aside from the synchronized update sequences (which terminals that don't support typically will ignore, though windows has a special case where it must be ignored). That said, you can query the terminal for support for this sequence if you wanted to. Other than that, it's using standard ANSI sequences: `\r` to return the cursor to the beginning of the line, `\x1bM` (Rev…

> `\x1bM` (Reverse Index) to move the cursor up a single line (repeated n times), and then `\x1b[J` to clear the screen below the cursor position. All of these are sequences defined at least since the VT220, probably the VT100.

For whatever reason, the people I'm collaborating with have the impression these aren't universal enough. And of course termcaps is out of vogue.

Re: Zig's new CLI progress bar explained

#25

Post by saurik »

epage wrote: post #24
rockorager wrote: post #23

Earlier quoted context omitted.

This isn't using any "fancy" terminal features, aside from the synchronized update sequences (which terminals that don't support typically will ignore, though windows has a special case where it must be ignored). That said, you can query the terminal for support for this sequence if you wanted to. Other than that, it's using standard ANSI sequences: `\r` to return the cursor to the beginning of the line, `\x1bM` (Rev…

> `\x1bM` (Reverse Index) to move the cursor up a single line (repeated n times), and then `\x1b[J` to clear the screen below the cursor position. All of these are sequences defined at least since the VT220, probably the VT100. For whatever reason, the people I'm collaborating with have the impression these aren't universal enough. And of course termcaps is out of vogue.

Simultaneously caring about terminals that don't support basic movement but also refusing to use termcap seems like an unfortunate combination :(.

Re: Zig's new CLI progress bar explained

#26

Post by Filligree »

> The key insight I had here is that, since the end result must be displayed on a terminal screen, there is a reasonably small upper bound on how much memory is required, beyond which point the extra memory couldn't be utilized because it wouldn't fit on the terminal screen anyway.

How large are your terminals?

I'm not sure if this represents lines, or perhaps something else. But on occasion I need to copy things out of my terminal, scrolling while copying doesn't work well, and so I shrink the text size to, let's say, one or two pixels per letter. I suspect Zig won't survive this.

Re: Zig's new CLI progress bar explained

#27

Post by vanderZwan »

Filligree wrote: post #26

> The key insight I had here is that, since the end result must be displayed on a terminal screen, there is a reasonably small upper bound on how much memory is required, beyond which point the extra memory couldn't be utilized because it wouldn't fit on the terminal screen anyway. How large are your terminals? I'm not sure if this represents lines, or perhaps something else. But on occasion I need to copy things out…

One pixel per letter on a 4k screen would be 3840 × 2160 chars at most, so around 8 megabytes if we assume one byte per "character tile" on the screen. I highly doubt Zig would die from this.

Re: Zig's new CLI progress bar explained

#29

Post by zarathustreal »

dang wrote: post #7
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.

" 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

It makes me chuckle to think you’ve done an analysis of this article for provocativeness.

Thinking about a real human spending their time trolling threads to tell someone their critique isn’t interesting..well that’s a bit less humorous.

Re: Zig's new CLI progress bar explained

#30

Post by one-punch »

Reminds me of nix-output-monitor [1], for example see [2].

It makes it easy to understand how individual steps are progressing, and how individual steps relate to the overall plan. It enables me to locate expensive build steps, and possibly to avoid them if steps are failing.

[1]: https://github.com/maralorn/nix-output-monitor

[2]: https://asciinema.org/a/7hJXH2iFLEkKxG1lL25lspqNn

Post reply on HN