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

Show HN: Zli – A Batteries-Included CLI Framework for Zig

github.com

Post reply on HN
Print view View original

21–30 of 41 posts

Re: Show HN: Zli – A Batteries-Included CLI Framework for Zig

#21

Post by Cloudef »

quotemstr wrote: post #12
AndyKelley wrote: post #9

Earlier quoted context omitted.

This is factually incorrect. While some operating systems use libc as the syscall ABI, this is not the case for Windows or Linux. On those systems, by default, Zig programs do not link libc; they make DLL calls or syscalls directly. The project in question, however, does seem to link libc in the build script for no reason, as well as create a static library for no reason (it doesn't export any functions). As Loris po…

> On those systems, by default, Zig programs do not link libc; they make DLL calls or syscalls directly. Well, that makes me think a lot less of Zig. Bypassing libc makes programs less cooperative members of the broader ecosystem. There's value in libc being able to act as a userspace intermediary between programs and the kernel. (That's why Windows doesn't provide a way to make direct system calls: you're going to g…

libc's been poisoning software long enough. Glad it's optional in Zig on platforms that provide stable system ABI.

Re: Show HN: Zli – A Batteries-Included CLI Framework for Zig

#22

Post by folkrav »

kingo55 wrote: post #19

Cool name - I bet it sounds great with an American/Canadian accent. Using the UK/Australia/NZ accent, it's pronounced "zed-ell-aye", so I didn't grok it instantly like most of the audience here would.

“Zee” is getting more popular especially with gen Z (unintended) who were raised with more widespread access to American media, social or otherwise. Like many Commonwealth countries, most of Canada uses “zed”, however.

Re: Show HN: Zli – A Batteries-Included CLI Framework for Zig

#23

Post by quotemstr »

Cloudef wrote: post #21
quotemstr wrote: post #12

Earlier quoted context omitted.

> On those systems, by default, Zig programs do not link libc; they make DLL calls or syscalls directly. Well, that makes me think a lot less of Zig. Bypassing libc makes programs less cooperative members of the broader ecosystem. There's value in libc being able to act as a userspace intermediary between programs and the kernel. (That's why Windows doesn't provide a way to make direct system calls: you're going to g…

libc's been poisoning software long enough. Glad it's optional in Zig on platforms that provide stable system ABI.

"[P]oisoning"? Do you have a technical objection, or do you just not like the letter "c"?

Re: Show HN: Zli – A Batteries-Included CLI Framework for Zig

#24

Post by quotemstr »

Graziano_M wrote: post #17
quotemstr wrote: post #12

Earlier quoted context omitted.

> On those systems, by default, Zig programs do not link libc; they make DLL calls or syscalls directly. Well, that makes me think a lot less of Zig. Bypassing libc makes programs less cooperative members of the broader ecosystem. There's value in libc being able to act as a userspace intermediary between programs and the kernel. (That's why Windows doesn't provide a way to make direct system calls: you're going to g…

On windows you make system calls through the DLLs because the system calls can change on you. On linux you're pretty much guaranteed that the API to the kernel will not change. It will get extended, but the semantics of old calls will not change).

So? That you can do something doesn't mean you should. Bypassing libc breaks workflows. Zig and Go aren't worse off on non-Linux platforms because those platforms enforce talking to the kernel through a library. Nobody, in either the Zig or the Go worlds, has justified bypassing libc in terms of concrete and specific user benefit.

Re: Show HN: Zli – A Batteries-Included CLI Framework for Zig

#26

Post by codethief »

bsder wrote: post #18
quotemstr wrote: post #2

No terminfo support? I'm probably tilting at windmills here, but I wish people wouldn't hardcode terminal escape codes. Considering zig's good interop with C, wiring up a call to tigetstr(). It's also important not to emit escape codes at all when TERM=dumb. (You'll get this behavior automatically if you implement color support by asking terminfo to the escape codes.) const c = @cImport({ @cInclude("ncurses.h"); @cIn…

> I'm probably tilting at windmills here, but I wish people wouldn't hardcode terminal escape codes. Please, no. There is no reason for this to be querying a hack from 1978 in 2025 when there are effectively two output terminal protocols--Windows and ANSI. And there is only a single terminal input protocol (kitty) that isn't brain damaged and allows you to do something super complex like "detect when Shift Key is pre…

> I have to install Ghostty in all my guest instances to pick up some stupid termcap/terminfo entry, or I get garbage all over my terminal.

That's a bummer to hear, I've been wanting to use Ghostty for a while but that'd be a showstopper for me. Is there a GitHub issue tracking this?

Re: Show HN: Zli – A Batteries-Included CLI Framework for Zig

#27

Post by quotemstr »

bsder wrote: post #18
quotemstr wrote: post #2

No terminfo support? I'm probably tilting at windmills here, but I wish people wouldn't hardcode terminal escape codes. Considering zig's good interop with C, wiring up a call to tigetstr(). It's also important not to emit escape codes at all when TERM=dumb. (You'll get this behavior automatically if you implement color support by asking terminfo to the escape codes.) const c = @cImport({ @cInclude("ncurses.h"); @cIn…

> I'm probably tilting at windmills here, but I wish people wouldn't hardcode terminal escape codes. Please, no. There is no reason for this to be querying a hack from 1978 in 2025 when there are effectively two output terminal protocols--Windows and ANSI. And there is only a single terminal input protocol (kitty) that isn't brain damaged and allows you to do something super complex like "detect when Shift Key is pre…

> Ghostty

I bet it has a setting to set TERM. I mean, TERM is hardly a panacea, but it's better than blindly spewing terminal control control codes without configuration or control or feature discovery.

> effectively two output terminal protocols--Windows and ANSI. And there is only a single terminal input protocol (kitty) that isn't brain damaged and allows you to do something super complex like "detect when Shift Key is pressed and released".

And what, every terminal application should have its own special knob for you to tell it what kind of terminal you have?

This whole discussion is a great example of why Chesterton's fence is a thing. The terminal world is already pretty fragmented. Suggestions to ignore the only even halfway decent widely-supported app-agnostic config knob without replacing it with something better are short-sighted. In any multi-party ecosystem, you need some way for different programs, written by different people at different times, to discover each other's capabilities.

Re: Show HN: Zli – A Batteries-Included CLI Framework for Zig

#28

Post by bsder »

codethief wrote: post #26
bsder wrote: post #18

Earlier quoted context omitted.

> I'm probably tilting at windmills here, but I wish people wouldn't hardcode terminal escape codes. Please, no. There is no reason for this to be querying a hack from 1978 in 2025 when there are effectively two output terminal protocols--Windows and ANSI. And there is only a single terminal input protocol (kitty) that isn't brain damaged and allows you to do something super complex like "detect when Shift Key is pre…

> I have to install Ghostty in all my guest instances to pick up some stupid termcap/terminfo entry, or I get garbage all over my terminal. That's a bummer to hear, I've been wanting to use Ghostty for a while but that'd be a showstopper for me. Is there a GitHub issue tracking this?

> That's a bummer to hear, I've been wanting to use Ghostty for a while but that'd be a showstopper for me. Is there a GitHub issue tracking this?

You should try it out for yourself first. It could be something weird in my setup since I'm running an immutable distro.

And, no, it doesn't have a Github issue because I didn't feel like tracking down all the moving pieces to replicate it when I can just resolve it with a package install.

Re: Show HN: Zli – A Batteries-Included CLI Framework for Zig

#30

Post by bsder »

quotemstr wrote: post #27
bsder wrote: post #18

Earlier quoted context omitted.

> I'm probably tilting at windmills here, but I wish people wouldn't hardcode terminal escape codes. Please, no. There is no reason for this to be querying a hack from 1978 in 2025 when there are effectively two output terminal protocols--Windows and ANSI. And there is only a single terminal input protocol (kitty) that isn't brain damaged and allows you to do something super complex like "detect when Shift Key is pre…

> Ghostty I bet it has a setting to set TERM. I mean, TERM is hardly a panacea, but it's better than blindly spewing terminal control control codes without configuration or control or feature discovery. > effectively two output terminal protocols--Windows and ANSI. And there is only a single terminal input protocol (kitty) that isn't brain damaged and allows you to do something super complex like "detect when Shift K…

> And what, every terminal application should have its own special knob for you to tell it what kind of terminal you have?

No, they should default to the only sane thing left, ignore TERM/termcap/terminfo, and leave the people who still want to run a VT-52 or Tek4014 in the dustbin.

There is a single combination for terminal usage which isn't broken in 2025--ANSI escape codes for output with the Kitty escape codes for input.

(And don't get me started about resolving the dependencies around ncurses, terminfo, etc. because some program is welded to a 15 year old version of curses ...)

Post reply on HN