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

Zig: Build System Reworked

ziglang.org

Post reply on HN
Print view View original

251–260 of 263 posts

Re: Zig: Build System Reworked

#251

Post by insanitybit »

yarn_ wrote: post #249
insanitybit wrote: post #183

Earlier quoted context omitted.

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

thank you for this truly deranged comment

As opposed to yours?

Re: Zig: Build System Reworked

#252

Post by tomjen3 »

miki123211 wrote: post #40
ACCount37 wrote: post #20

Earlier quoted context omitted.

Rarely. Most tinkering tasks just don't have enough heavy duty computation in them to as much as strain a modern CPU. And most of the rest are covered by packages like numpy or pytorch. For the rare exceptions, I make a C lib and call into it to get my numbers crunched. I get that Zig is a viable replacement for C there. But I don't see it replacing Python.

And if you really need more performance (or, more often, fast startup times), Go gives you 90% of the speed with 30% of the effort. Rust if you really want to squeeze everything that can possibly be squeezed of that CPU.

Go does not give you control. Much of the speed comes from choosing the right algorithms - including memory management. In Go you have GC, you don't have that in Zig.

Linked lists are a lot less slow if you use Arena allocation around your hotspots and make sure to allocate space for as many as you thing you need, since they will be carved out of a contigious block of memory and will stay in CPU cache.

Golang also requires you to write more code, as it lags Zigs try operator.

Re: Zig: Build System Reworked

#255

Post by sunsetSamurai »

latexr wrote: post #189
sunsetSamurai wrote: post #158

Earlier quoted context omitted.

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

thanks, will watch it later

Re: Zig: Build System Reworked

#256

Post by chaz72 »

NewsaHackO wrote: post #173
jmull wrote: 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…

My interpretation of what they said is closer to “we already improved compilation speeds by 4x and we did it without compromising our plans to go much further - also this PR introduces specific timing bugs.”

Re: Zig: Build System Reworked

#257

Post by int_19h »

kibwen wrote: post #213
wmedrano wrote: post #120

Earlier quoted context omitted.

Zig gives you more control than Rust, which should theoretically lead to a higher performance ceiling. There's not much magic in Zig. Keep hitting goto-definition and you can eventually see the OS switch statements and syscalls.

Neither Rust nor Zig give you any more control than the other. If you want raw pointers or inline assembly, Rust supports that.

Technically true, but unsafe Rust is much harder to deal with because it makes assumptions (sometimes very non-obvious) regarding aliasing that Zig does not. You might think you can avoid problems by using T* rather than T&, but every accessible local is effectively a T& so it's still very easy to do something you're not supposed to.

Re: Zig: Build System Reworked

#258

Post by int_19h »

Philpax wrote: post #119
pmarreck wrote: post #86

Earlier quoted context omitted.

that’s not what the benchmarks say about Go, and based on multiple reports, Rust does not scale well into large codebases, which eventually become brittle and very difficult to change Zig is a return to “no magical effects,” except with reasonable safety

I would be very surprised to see a large Rust codebase being harder to maintain than a large Zig codebase. The former makes it much easier to maintain invariants at scale.

With Rust macros it's also possible to bolt on proper design by contract into the language.

Re: Zig: Build System Reworked

#259

Post by galaxyLogic »

throwawayk7h wrote: post #229
galaxyLogic wrote: post #224

Earlier quoted context omitted.

Why not just comment out variables you "want to keep around" but are not used anywhere?

it's just annoying to have to do that.

The converse is that if you have many unused variables some of them are used in some contexts but not others and then when you use FIND to find occurrences of a variable you will find many which are not relevant and some which are.

Overall the code gets smaller and easier to understand when it only has things that need to be there. If you comment out a an unused variable you can see from find-results that in effect that occurrence cannot matter.

Unused variables are "noise" that hide actually important things.

Re: Zig: Build System Reworked

#260

Post by kibwen »

int_19h wrote: post #257
kibwen wrote: post #213

Earlier quoted context omitted.

Neither Rust nor Zig give you any more control than the other. If you want raw pointers or inline assembly, Rust supports that.

Technically true, but unsafe Rust is much harder to deal with because it makes assumptions (sometimes very non-obvious) regarding aliasing that Zig does not. You might think you can avoid problems by using T* rather than T&, but every accessible local is effectively a T& so it's still very easy to do something you're not supposed to.

> every accessible local is effectively a T&

No, I'm not sure where you heard this but this is certainly not the case. If I have an i32 on the stack in Rust, there are no aliasing invariants that need to be upheld. You do, in fact, avoid problems in unsafe Rust by just using raw pointers instead of references. The idea that "unsafe Rust is harder to deal with than {Zig, C, C++}" is a long-outdated notion from old versions of Rust, before there was a dedicated way to produce a raw pointer without first producing an intermediate reference.

Post reply on HN