Live data from Hacker News

Zig: Build System Reworked

ziglang.org

181–190 of 263 posts

Re: Zig: Build System Reworked

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

I believe their plan is using "restricted function pointers", where you can specify that a pointer will only ever be to a function defined in the codebase. I'm pretty sure they also have plans for devirtualization, but I haven't followed super closely.

Re: Zig: Build System Reworked

#182

Earlier quoted context omitted.

Andrew's take is "it's ready when it's ready but we hope it's good enough before it's fully ready that you want to use it anyway". It's different and I like it. You get one shot at it and may just as well get it right in as many areas as possible.

Yep. He mentioned recently in his JetBrains interview he wants Zig to be a language for the next 50 years. Rushing 1.0 for the sake of signaling to the wider industry today would be actively harmful to that goal.

Too bad it will not be adopted for anything serious in the next 50 years. There is no reasonable value proposition from a business standpoint for picking zig over rust. It is already the reality in much of the tech industry that Rust is filling the space previously occupied by C++. The fact that there now exists a safe low level language is legitimately a paradigm shift. It doesn't matter how many shiny cool things zig adds, being unsafe means it a technology stuck in the past.

Re: Zig: Build System Reworked

#183

Would someone tell a rust user why they should and should not try zig?

> and should not try zig?

Because it isn't memory safe. I honestly think it's beyond the point of "irresponsible" and well into "negligence" that we're still developing unsafe technologies - people are being harmed by this choice. It's one thing when you have to target specific platforms and maybe Rust wasn't an option or whatever, but the reasons to choose unsafe languages at this point are vanishingly small.

Zig is very cool, I love many aspects of it. I'll never touch it, I'll always advocate against it tbh. I'd probably advocate that software written in languages like Zig be flagged for FEDRAMP and other environments since devs seem to not care unless they're legally barred from making these sorts of choices.

Re: Zig: Build System Reworked

#184

Earlier quoted context omitted.

> RAII is great; I wish they'd use some light (optional) RAII for strings and containers etc. Is it not possible to build a wrapper that does this? It seems like it should be.

It is. I definitely agree that strings in Zig can be tedious, but the upside is that if you need it, you can build a string library that does everything you want it to do, in the way you want. For comparison, while Rust offers a very rich string library, it's also very strict about what you can/cannot do with strings, so if your use case falls outside of that you're out of luck. With Zig, you can pretty easily roll y…

You can also roll your own strings in Rust just fine. Take the bstr crate, for example.

Re: Zig: Build System Reworked

#185
post #8

After having used Zig for a couple of months now I am convinced it is a fantastic tool language. You just pick it up to hack some idea together freely. Every time I hit a wall, I find the creators have thought of it already and offers comfort. But nothing gets in your face how to use the programming language "correctly". For me it is now the go-to "tinker in my garage" language.

> But nothing gets in your face how to use the programming language "correctly". It doesnt let you have unused variables and theres no multiline comment support. These are fairly significant productivity issues for me

> It doesnt let you have unused variables

Andrew Kelly on that:

https://www.youtube.com/watch?v=iqddnwKF8HQ&t=2927s

Looks like you might be able to get rid of the error easily with annotations.

Re: Zig: Build System Reworked

#186
post #167

Earlier quoted context omitted.

A large, complex, unasked for PR is pretty likely pointless to throw at any serious project. (Well, it's pointless if your goal is to merge something.) Working together is a two-way process. To land a big change, the bun people probably needed to have been working/coordinating with the zig people throughout. E.g., zig outright cannot accept PRs that break the language in unplanned ways and any conflicts with the road…

Of course, and it is expected that large pull requests/RFCs are iterated on. I will not believe Bun seriously asked for a pull request to be merged with absolutely no expectation of back and forth discussion. But this isn’t what happened. The whole reason everyone thought it was rejected by Zig because Bun used LLM to generate it was because they responded in a way that someone would if they didn’t want a certain pul…

I don't really get the objection here. Who should make decisions about zig's roadmap, priorities, and approaches, the zig people or the bun people?

There's no value to iterating on a PR when the approach itself is not right.

Re: Zig: Build System Reworked

#187

Would someone tell a rust user why they should and should not try zig?

I can tell you a bit about my own experience, as I've I used Rust for two years, but have now transitioned to Zig. I started working on a modular synthesis engine, and I realized that Javascript wouldn't give me the granular control I needed. So I decided to use Rust. This was my first foray into low level programming, so learning Rust first was great because I internalized their ownership rules. However, I started to realize that Rust was doing quite a bit of stuff behind my back, like freeing objects when dropped, or making allocations when I inserted an item. This is a big no-no for realtime programming, and Rust didn't help me understand what was happening. It was then that I read matklad's blog post on rust hard mode, https://matklad.github.io/2022/10/06/hard-mode-rust.html. I looked at some of his other blog posts too, and saw Zig. So Zig had been in the back of my mind for a while, when I decided to port a Tcl interpreter to Zig. I've been about 7 months in now making my own interpreter, and it's been a delightful language. Yes, I've had my share of memory leaks and double frees, but the debugging trace lets me capture a stack track at each reference count increment and decrement, so I'm able to hunt them down pretty well. I'm also hyper aware of memory layout and allocation failure, because allocation is fallible in Zig. The error union handling makes it pretty easy to propagate OOM though, so it's not hard to make code that's resilient to OOM. If I had tried to make this in Rust, I would have been fighting the standard library, ecosystem, and borrow checker constantly, because high level programming languages have non-trivial ownership semantics, and a lot of optimizations like epoch based variable caching just don't play nicely with references as trees.

Re: Zig: Build System Reworked

#188

My kingdom for Zig to have an official mechanism to emit the Linux library stubs. Zig’s ability to crosscompile and target arbitrary versions of glibc is PURE MAGIC. I leverage this magic in an unrelated C++ build system. But I have to hack around to get those library stubs from Zig. Would love it to be an official output.

Check out https://github.com/cerisier/glibc-stubs-generator

Re: Zig: Build System Reworked

#189

Earlier quoted context omitted.

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

I think they are switching from Rust to Zig. I don’t recall exactly, but they talked about it in a video where the creator of Roc interviewed the creator of Zig.

https://www.youtube.com/watch?v=w74rC-6caxE

Re: Zig: Build System Reworked

#190

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…

A common combo for this is (was?) C and Lua. Lua is intended to be a embedded language, so good for Interop, but also also high level and easy to use.

There's a reason why Factorio uses Lua as it's scripting level language

Post reply on HN