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

221–230 of 263 posts

Re: Zig: Build System Reworked

#221

Post by justinhj »

IshKebab wrote: post #208
justinhj wrote: post #168

Earlier quoted context omitted.

An arena allocator lets you treat a series of allocations as a single block. In cases where you find yourself needing to micromanage a bunch of small memory allocations you can simply ignore freeing them individually and free the whole arena when you are done.

Yeah sorry I know what an arena allocator is. I meant how can you write code that deals with strings (joining, formatting, passing around etc.) but isn't sensitive to performance (so `std::string`-like performance is fine) in Zig without having to deal with tedious low level allocator details. If I have to pass an allocator around everywhere that's a pain in the bum. Apparently Zig doesn't have a global allocator so…

Passing an allocator around is a design choice of Zig, so yeah, it is not supposed to be avoided

Re: Zig: Build System Reworked

#222

Post by sieabahlpark »

ulbu wrote: post #42
brabel wrote: post #24

I just upgraded some code to Zig 0.16.0 and I am actually really happy with the results. It impacted A LOT of things, but the changes were actually very good and seems to have set the language for a bright future, especially with the new IO mechanism which allows supper efficient code that looks good whether it's implemented single-threaded, multi-threaded or just via an event loop! If you haven't tried Zig since 0.1…

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.

[dead]

Re: Zig: Build System Reworked

#223

Post by insanitybit »

beanjuiceII wrote: post #218
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…

> I'd probably advocate that software written in languages like Zig be flagged for FEDRAMP this is an insane take

Why? It seems sort of obvious. FEDRAMP is about specific assurances (like FIPS), memory safety is an obvious one.

Re: Zig: Build System Reworked

#224

Post by galaxyLogic »

defen wrote: post #169
xyzsparetimexyz wrote: post #61

Earlier quoted context omitted.

> 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

I love Zig and I am generally very happy with Andrew's benevolent dictatorship and the benefits of having one single smart tasteful person in charge of decisions, but the unused variable one really hurts. My guess is that he's seen what a mess C code can be with regard to warnings and so is just totally unwilling to compromise by adding the concept of warnings to Zig. But if I had one wish about the language, it woul…

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

Re: Zig: Build System Reworked

#225

Post by Mawr »

magnio wrote: post #103
bbkane wrote: post #78

Earlier quoted context omitted.

I thank Go for this. Go's compilation times seemed to inspire other language devs

I doubt Go has any sizable effect on the community of programming language developers. Probably Pascal has more impact on this.

Then you haven't been paying attention to the space. At all.

Every single new post-Go language, like Rust & Zig, ships with an opinionated autoformatter and a single go-to command to manage builds, packaging, etc.

And how many new languages do you see include inheritance and exceptions?

Older languages have started adapting what they can too:

- Python with `uv` and `black`

- Java with goroutine-like fibers and modern configuration-free gcs and the go-gc-like low pause times zgc

- Many languages now ship a production-ready http server, just like Go

Re: Zig: Build System Reworked

#226

Post by lukaslalinsky »

smj-edison wrote: post #220
dnautics wrote: post #214

Earlier quoted context omitted.

"you can specify that a pointer" i dont think you need to specify that. the compiler can figure it out and do an optimization pass at the end.

Oh, is it not a specific keyword? I thought they were thinking of it being a keyword so you could be sure that it was restricted, in case a variable or function was exported that took in a foreign pointer.

There are going to be builtins to control this. The compiler will not do it on its own.

Re: Zig: Build System Reworked

#227

Post by Mawr »

NewsaHackO wrote: post #122
araoz wrote: post #106

Earlier quoted context omitted.

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

Frankly, this just reads like FUD. See the official explanation on why the PR in question wasn't merged: https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio...

"Therefore, to implement this feature without an avalanche of bugs and inconsistencies, we need to make language changes."

"Put more simply, we are going to make these enhancements, but hacking them in for a flashy headline isn’t a good outcome for our users. Instead we’re approaching the problem with the care it deserves, so that when we ultimately ship it, we don’t cause regressions."

"So instead of wasting time writing a more robust implementation of this LLVM module splitting logic for a relatively minor improvement, we have instead put that effort towards features like self-hosted backends and incremental compilation, which can improve compilation speed by orders of magnitude.

[...]

There’s the 4x speedup claimed by the Bun team, already available on Zig 0.16.0!"

Re: Zig: Build System Reworked

#228

Post by Mawr »

epolanski wrote: post #15
dmit wrote: post #10

Earlier quoted context omitted.

I foresee a pjmlp comment in your near future. :)

Yeah, let's add a sprinkle of toxicity to my Saturday morning!

What, you wouldn't want a condescending lecture on which exact, unpopular even at the time, languages from the 80's, which had 10% of features of Zig and ran 20x slower, also had fast compilation times? For the 1000th time? Shame on you.

Re: Zig: Build System Reworked

#229

Post by throwawayk7h »

galaxyLogic wrote: post #224
defen wrote: post #169

Earlier quoted context omitted.

I love Zig and I am generally very happy with Andrew's benevolent dictatorship and the benefits of having one single smart tasteful person in charge of decisions, but the unused variable one really hurts. My guess is that he's seen what a mess C code can be with regard to warnings and so is just totally unwilling to compromise by adding the concept of warnings to Zig. But if I had one wish about the language, it woul…

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.

Re: Zig: Build System Reworked

#230

Post by kushagra1211 »

One thing I appreciate about Zig's development is that a surprising amount of effort goes into tooling and developer feedback loops rather than adding language features.

A new language can survive missing a feature for a while. It's much harder to survive if every compile, link, and dependency update feels slow. The focus on making the development cycle measured in milliseconds instead of seconds seems like a good long-term bet.

Post reply on HN