Live data from Hacker News

Zig: Build System Reworked

ziglang.org

151–160 of 263 posts

Re: Zig: Build System Reworked

#151

There is an idea I've been kicking around for a long time, which I'll just call dual programming. The idea is to develop a stack that consists of just two programming languages, 1 higher level language, and one lower level language. You are supposed to do as much programming as you can in the high level language, and only drop into the low level language as needed. The problem is that unless you already know a low le…

[deleted]

Re: Zig: Build System Reworked

#152

There is an idea I've been kicking around for a long time, which I'll just call dual programming. The idea is to develop a stack that consists of just two programming languages, 1 higher level language, and one lower level language. You are supposed to do as much programming as you can in the high level language, and only drop into the low level language as needed. The problem is that unless you already know a low le…

this was the general motivation for my project zigler:

https://github.com/E-xyza/zigler

Re: Zig: Build System Reworked

#153

There is an idea I've been kicking around for a long time, which I'll just call dual programming. The idea is to develop a stack that consists of just two programming languages, 1 higher level language, and one lower level language. You are supposed to do as much programming as you can in the high level language, and only drop into the low level language as needed. The problem is that unless you already know a low le…

The OG of these is probably C and Assembly. C and (Emacs) Lisp is well known. Arguably, it's the entire reason we have Python. But if you want to pair Zig against something, I would look at Lua.

Re: Zig: Build System Reworked

#154
post #42

Earlier quoted context omitted.

the “(super) efficient” is not there yet. Io is still dynamic dispatch with multiple layers of indirection. afaik it’s slower than before. the upcoming releases are expected to provide a solution to this “dispatch is comptime-known, but still dynamic” problem, and drop the loses in efficiency.

Wow that’s gnarly it’s using dynamic dispatch. I mean I get it, but I thought zig was some sort of performance demon.

if youre doing io, one pointer indirection seems unlikely tp be rate limiting. same for allocation (the other dynamic dispatch in zig)

Re: Zig: Build System Reworked

#155

There is an idea I've been kicking around for a long time, which I'll just call dual programming. The idea is to develop a stack that consists of just two programming languages, 1 higher level language, and one lower level language. You are supposed to do as much programming as you can in the high level language, and only drop into the low level language as needed. The problem is that unless you already know a low le…

> You are supposed to do as much programming as you can in the high level language, and only drop into the low level language as needed.

I think that's a neat idea, but in the reverse: do as much as you can in the lower level language, and only go up to the high level language when the convenience is worth the cost.

Roc allows this: every program has a platform written in a low-level language, and then the Roc program uses the API that the platform exposes.

https://www.roc-lang.org/

Then how you want to balance high vs low is of course up to you :^)

Re: Zig: Build System Reworked

#156
post #90
post #75

Earlier quoted context omitted.

Hmm in the 2025 talk ( https://youtu.be/f30PceqQWko?si=qZESxMaSyt7fYMfz ), Andrew emphasizes that this approach is more efficient than before- even showing compiled assembly iirc. I guess that was a one-off?

My guess is that one of these (Andrew) is measuring syscalls and the other is measuring vtable indirections.

A vtable indirection is essentially free when you're going to perform a syscall. What matters is that the buffer is above the vtable (which is already the case for the current implementation) so that you don't pay for the indirection when hitting the buffer.

Re: Zig: Build System Reworked

#157

There is an idea I've been kicking around for a long time, which I'll just call dual programming. The idea is to develop a stack that consists of just two programming languages, 1 higher level language, and one lower level language. You are supposed to do as much programming as you can in the high level language, and only drop into the low level language as needed. The problem is that unless you already know a low le…

this was the general motivation for my project zigler: https://github.com/E-xyza/zigler

Very cool use of Elixir! I have been considering the Fig Stack (F# + Zig) myself, so I'm excited to see Zig being paired with a Functional Language

Re: Zig: Build System Reworked

#158

There is an idea I've been kicking around for a long time, which I'll just call dual programming. The idea is to develop a stack that consists of just two programming languages, 1 higher level language, and one lower level language. You are supposed to do as much programming as you can in the high level language, and only drop into the low level language as needed. The problem is that unless you already know a low le…

> You are supposed to do as much programming as you can in the high level language, and only drop into the low level language as needed. I think that's a neat idea, but in the reverse: do as much as you can in the lower level language, and only go up to the high level language when the convenience is worth the cost. Roc allows this: every program has a platform written in a low-level language, and then the Roc progra…

roc lang looks very interesting, I see they use a lot of Zig and Rust, very unusual combo I think.

Re: Zig: Build System Reworked

#160
post #114

Zig has so many compelling features, and I'd even be willing to give up Rust's near-perfect memory safety in some cases. But the one thing that really put me off is string handling. It's just so super tedious. I like being able to finely manage individual string memory allocations, but I really don't want to have to do it all the time . RAII is great; I wish they'd use some light (optional) RAII for strings and conta…

Why not use an arena allocator?

Tbh I don't know enough Zig to answer that. Can you give an example? E.g. some non-performance-sensitive function that returns a string? In Rust and C++ you can treat the string exactly the same as you would an integer and it's super easy.

In C you have pain. Does the caller allocate a buffer? How does it know how big to make it? Do you have to have separate calls to calculate the required length? Etc. Can Zig work like Rust/C++ and not like C? My impression is that it can't.

Post reply on HN