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

31–40 of 43 posts

Re: Zig's new CLI progress bar explained

#31

Post by rjh29 »

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

it's a joke. Obviously, when you're a compiler engineer, creating a progress bar is not a great demonstration of your skill.

It wasn't a joke apparently.

Re: Zig's new CLI progress bar explained

#32

Post by dang »

zarathustreal wrote: post #29
dang wrote: post #7

Earlier quoted context omitted.

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

One can recognize a response to provocation without an analysis. That's because they're so predictable, which is also why we have that guideline.

Re: Zig's new CLI progress bar explained

#33

Post by anacrolix »

voidhorse wrote: post #10
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

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…

This is my impression too. Rust is drastically different from mainstream languages, so it's worth the jump. Zig is quite close, and I'm not sure it provides enough. I would just use C.

Re: Zig's new CLI progress bar explained

#34

Post by [deleted] »

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

[deleted]

Re: Zig's new CLI progress bar explained

#36

Post by Filligree »

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

The article suggests it’s using a fixed-size buffer of 200 somethings. Seems worth checking, though I have no goose in this race.

Re: Zig's new CLI progress bar explained

#37

Post by vanderZwan »

Filligree wrote: post #36
vanderZwan wrote: post #27

Earlier quoted context omitted.

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.

The article suggests it’s using a fixed-size buffer of 200 somethings. Seems worth checking, though I have no goose in this race.

If I understand correctly then that's for the number of threads, although I also think that the sudden switch from terminal size back to the topic of threads is confusing so I agree that it's not entirely clear what the connection between the two is - or if there is none, that the structure of the article makes that confusing

Re: Zig's new CLI progress bar explained

#38

Post by binary132 »

hansvm wrote: post #21
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 wi…

I stan Zig but the OP literally starts with “there was a subtle bug in my fork() wrapper for years”.

Re: Zig's new CLI progress bar explained

#39

Post by binary132 »

One thing that the latest generation of languages has taught me (or that I have learned in the process?) is that “languages” aren’t “really a real thing” in and of themselves as much as they are merely composable APIs over compilers / interpreters (which are basically just dynamic compilers, or compilers are interpreters?), and compilers are an insane, fragmented dumpster fire with no or barely usable APIs. Only LLVM, GCC, TinyCC, and Terra admit this reality, neither LLVM nor GCC’s APIs are really user-oriented, and Terra isn’t really a realistic option for most people. I also personally don’t really feel that LLVM has accomplished (or can accomplish) its potential for a variety of reasons — most LLVM projects are forks or patches, although Zig has done well at this — and GCC has limitations as well although I’m very pleased with gccjit in Emacs. I’m very curious to see what the future holds especially if we can get an optionally-verifiable yet usable compiler API.

Re: Zig's new CLI progress bar explained

#40

Post by binary132 »

AndyKelley wrote: post #8
YuukiRey wrote: 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!

FWIW, I don’t think your writing is arrogant, but if it sets someone off, maybe they’re the one with an ego problem.
Post reply on HN