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

121–130 of 263 posts

Re: Zig: Build System Reworked

#121

Post by dmit »

conorbergin wrote: post #116
dmit wrote: post #18

Earlier quoted context omitted.

Have you ever thought "Ugh, this bit of Python code is running much slower than I expected on my computer. Wonder if anyone has written a native library for this"? That's probably the closest use case for someone who matches your description -- a language that is much more ergonomic, much more 'modern' feeling (in all the good ways), while still extremely compatible with C. As for the language itself, it's going to b…

I don't think performance has got much to do with tinkering. IMO the real benefit of Zig is you get the flexibility of C with the ergonomics of a modern language. I like Python as a tool language, and I am very impressed by projects like Micropython, but you always eventually run into a wall. I.e. you are never going to write a compute shader in python, but I assume someone is going to try. I think the programmer sho…

> I don't think performance has got much to do with tinkering.

Yes, in general, but also there are cases when you realize you can, idk, parse a CSV file in 0.2 seconds instead of 200 seconds. That kind of improvement unlocks a new level of tinkering.

Re: Zig: Build System Reworked

#122

Post by NewsaHackO »

araoz wrote: post #106
NewsaHackO wrote: post #82

Earlier quoted context omitted.

> bun seems to be committed to slop rust already. so, with their ethic, maybe we should just disassociate them from zig and let them go realize their slop dreams? Closing your eyes and pretending a problem does not exist is the a good solution. The fact of the matter is one of the biggest projects that used Zig thought that the devX was so bad that they opted to rewrite their entire 1M LOC project into a different la…

I don't remember where it was said first, but I think the problem was not "AI drama" or that zig doesn't have "a good solution". It was more a mismatch between Bun's & Zig's goals. Bun wants to move fast & break things, even more now after getting acquired, but Zig punishes that. Zig requires you to handle everything carefully, there's no GC or big runtime to let you "break things", zig will let you just segfault. Co…

But this goes to my second point; it seems like Zig wasn’t open to any compromise about the solution that Bun submitted and one they built in house. Is it the Zig culture to reject a pull request like that wholesale? It’s really odd for them to have such a flippant attitude and not to even try offer ways that they could use the pull request or things that they need to tweak to make it more inline with what they want. Companies want to use languages that have a understanding committee, and are willing to work together to create solutions, not just say “No, this isn’t what we want, and we are building a similar system anyway so don’t even bother to try again”. It just looks unprofessional.

Re: Zig: Build System Reworked

#123

Post by onlyrealcuzzo »

IshKebab wrote: post #47

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…

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

Re: Zig: Build System Reworked

#124

Post by insanitybit »

amazingamazing wrote: post #57
pylotlight wrote: post #53

Earlier quoted context omitted.

Just plain incorrect.. please stop spouting this nonsense, this is not the reason whatsoever.

What is the reason?

The explicitly stated reason is that they ran into too many segfaults and it was slowing down development velocity.

That said, I hope that Zig posts won't be plagued by "but the bun thing" like this in the near future.

Re: Zig: Build System Reworked

#125

Post by pron »

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.

Neither has been battle-tested at the relevant scale.

Re: Zig: Build System Reworked

#127

Post by pron »

sourcegrift wrote: post #96

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

I don't think Rust users are relevant here. It primarily comes down to personal preferences, and since Zig and Rust are so different, some will be drawn to Rust and others to Zig. If you really like a language and it suits your needs, be it Rust or any other, there's no need to look to switch. I think that the audience Zig is aimed at is low-level programmers who haven't taken a liking to Rust, which is the majority of them. Rust isn't very popular among experienced low-level programmers (certainly for a language that old), and I guess Zig is hoping to be more to their liking.

For example, I find Rust to be far too similar to C++, and it shares most of the problems I have with C++ only with much lower adoption. I'm not saying I'm ready to make the switch, but at least Zig offers a different approach that's intriguing to me.

Re: Zig: Build System Reworked

#128

Post by cornstalks »

ACCount37 wrote: post #108
cornstalks wrote: post #85

Earlier quoted context omitted.

When I want to tinker it’s usually because I want to make something faster than anyone else has done. Does that help illustrate why some might prefer to tinker in Zig, and why your definition of tinker seems a little narrow?

Most of the time "make something faster than anyone else has done" is just not worth doing? Good enough is good enough. Unless it's some super hot path and it's the speed that's the main goal, nothing else. Which is rarely the case. If you only ever think of tinkering for the purpose of execution speed ninjutsu, isn't it your definition of tinkering that's far too narrow?

No, I’m saying that it’s how I like to tinker. Others have their own ways of tinkering that are just as valid!

I personally think the optimization challenge is fun. I like digging in to low level stuff, reviewing the assembly dumps and processor pipeline architectures. I fail or give up most of the time, but I enjoy learning in the process.

I’m just trying to show how Zig fits my tinkering well, since you said you can’t see how Zig would ever be a good fit for tinkering. I’m not saying it’s a good fit for all forms of tinkering.

Re: Zig: Build System Reworked

#129

Post by NewsaHackO »

geodel wrote: post #112
NewsaHackO wrote: post #82

Earlier quoted context omitted.

> bun seems to be committed to slop rust already. so, with their ethic, maybe we should just disassociate them from zig and let them go realize their slop dreams? Closing your eyes and pretending a problem does not exist is the a good solution. The fact of the matter is one of the biggest projects that used Zig thought that the devX was so bad that they opted to rewrite their entire 1M LOC project into a different la…

> The fact of the matter is one of the biggest projects that used Zig thought that the devX was so bad that they opted to rewrite their entire 1M LOC project into a different language. That is not the fact of matter. The fact is it got bought by Anthropic. And in larger scheme of things Bun is one example Claude capabilities of translation. And even if doesn't work, it just a part of Claude desktop stack so still hav…

Not really, if it doesn’t work then it will hurt their flagship desktop app’s stability, which would negatively affect their placing in an already cutthroat AI arms. Claude Code is the few business asset that Claude has the least moat compared to other providers( even open source). They can’t afford to be sloppy and use a buggy JS engine.

Re: Zig: Build System Reworked

#130

Post by ozgrakkurt »

epolanski wrote: post #5

This sounds like great news, Zig's compilation times are already terrific and this is going to only make them better.

Just creating a file with dummy test like

if (2 * 2 != 5) { @panic("fail"); }

And running `zig test file.zig -OReleaseSafe` takes a couple seconds on my computer. It also keeps taking the same amount of time every time I do it when I modify that file. Using 0.16 (or master) version so my toolchain isn't old and I'm on linux.

Zig is super nice to use as a language but the compiler/stdlib isn't developed conservatively enough imo.

You may not run into an issue like this when starting out with hello world but you will want to run optimized binaries for fuzz testing or benchmarking. And then it becomes super annoying considering you might be compiling a relatively small amount of code.

Just for comparison, imo Zig is a much better language than these other languages, but if you did something like this in Rust/C++/C etc. this kind of issues basically doesn't ever happen. Assuming clang/gcc/ninja etc. usage for C/C++.

I am able to use Ninja/Python/clang for configuring/building (-O2 or -O3)/testing ~10k loc C++ project in 200ms on the same computer for example.

Post reply on HN