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.
Zig: Build System Reworked
181–190 of 263 posts
Re: Zig: Build System Reworked
#182Earlier 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.
Re: Zig: Build System Reworked
#183Would someone tell a rust user why they should 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
#184Earlier 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…
Re: Zig: Build System Reworked
#185After 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
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
#186Earlier 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…
There's no value to iterating on a PR when the approach itself is not right.
Re: Zig: Build System Reworked
#187Would someone tell a rust user why they should and should not try zig?
Re: Zig: Build System Reworked
#188My 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.
Re: Zig: Build System Reworked
#189Earlier 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.
Re: Zig: Build System Reworked
#190There 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…
There's a reason why Factorio uses Lua as it's scripting level language