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

161–170 of 263 posts

Re: Zig: Build System Reworked

#161

Post by elcritch »

tatjam wrote: post #71
archargelod wrote: post #60

Earlier quoted context omitted.

That's actually a great argument for Nim[0]. Easy interop with C, native-speed performance, and a syntax very close to Python in both readability and how quickly you can get something working. Batteries included, automatic memory management without a conventional GC and metaprogramming - is a really cool combination. [0] - https://nim-lang.org/

Aggh if only its LSP was better! I have always run into issues when using Helix with it (it kept crashing), and I'm absolutely spoiled by good LSPs in other languages :( Wish I had the time and skill to actually contribute to the LSP, if you have ever used Nim it's a seriously underrated language.

Araq the Nim creator is working on a rewrite of the Nim compiler called Nimony that'll become Nim 3.

It's making fast progress and will provide the basis for a proper LSP! Nimony already supports incremental compilation and parallel which are key pieces for good fast LSP.

Re: Zig: Build System Reworked

#162

Post by F3nd0 »

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

Compromising on project goals just because someone with somewhat different goals made a pull request doesn’t exactly scream responsible and professional to me. The way I understand it, many people appreciate Zig because it’s very consistent and restrained about the kinds of problems it’s trying to solve and how, so being very careful with accepting complex, externally developed solutions seems perfectly in character for the language.

I’m not sure how well the Zig developers have handled their communication, so perhaps there really was room for improvement there.

Re: Zig: Build System Reworked

#163

Post by childintime »

Decabytes wrote: post #149

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…

C# is close to achieving that goal.

Re: Zig: Build System Reworked

#164

Post by macintux »

kibwen wrote: post #143
3836293648 wrote: post #118

Earlier quoted context omitted.

You are entirely right here, you're also incredibly rude. Please don't bother replying when the only thing you're actually doing is being condescending and spreading negativity

[flagged]

> Be kind. Don't be snarky. Converse curiously; don't cross-examine. Edit out swipes.

Rudeness may be acceptable elsewhere. Not here.

Re: Zig: Build System Reworked

#165

Post by scuff3d »

xngbuilds wrote: post #50

After watching Andrew Kelley's interview video makes me want to pick up Zig: https://www.youtube.com/watch?v=iqddnwKF8HQ

I have a lot of respect for Andrew, and I really enjoy Zig, but God that interview was awful. Andrews answers were fine, but the whole thing felt very sycophantic.

Re: Zig: Build System Reworked

#166

Post by forrestthewoods »

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.

Re: Zig: Build System Reworked

#167

Post by jmull »

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

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 roadmap would need to be resolved.

I would assume the bun people know all this. That makes it more of a publicity stunt than a serious attempt to contribute to zig, and we should probably all treat it that way.

Re: Zig: Build System Reworked

#168

Post by justinhj »

IshKebab wrote: post #160
nusaru wrote: post #114

Earlier quoted context omitted.

Why not use an arena allocator?

Tbh I don't know enough Zig to answer that. Can you give an example? E.g. some non-performance-sensitive function that returns a string? In Rust and C++ you can treat the string exactly the same as you would an integer and it's super easy. In C you have pain. Does the caller allocate a buffer? How does it know how big to make it? Do you have to have separate calls to calculate the required length? Etc. Can Zig work l…

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.

Re: Zig: Build System Reworked

#169

Post by defen »

xyzsparetimexyz wrote: post #61
portly wrote: 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

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 would be for a command-line flag to disable unused variable errors. So much effort has been put into making iteration fast (all this build system stuff, the custom backend, incremental compilation) and then there's just this giant blocker preventing fast iteration on the editing side.

Re: Zig: Build System Reworked

#170

Post by foresto »

xyzsparetimexyz wrote: post #61
portly wrote: 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

Ugh. This is something I hate about Go. I would be happy to have unused variables generate warnings, but as errors, they turn the toolchain into an adversary.

It's common for me to temporarily comment out a variable's use when developing new code, as I experiment with ideas. It's even more common when working in unfamiliar code, such as tracking down a bug or incrementally adding a new feature. It's an important part of my exploration process.

When I hit Compile at that point, I expect the compiler to build the work-in-progress exactly as it is in that moment. Executing the output allows me to spot check the snapshot's behavior against my expectations and mental model. The compile step also assures me that no syntax errors have crept in while I was focused on the logic flow or general shape of the code.

When a compiler refuses to do its job, and instead barfs up spurious errors complaining about unused variables, it brings my workflow to a screeching halt. In order to make progress, I am forced to abruptly leave my current context to visit all the different places where those variables are introduced, edit them, try again, discover that those forced edits have left more variables unused, and repeat the process until the combative compiler shuts up and does what I told it to do in the first place. By the time I'm allowed to return to what I was doing, my train of thought has been derailed, the bits of logic that I had been juggling have fallen to the ground, and my focus destroyed. And then, once I have recovered my original thoughts and seen the output of my snapshot build, I have to go back and revert all those forced edits before I can resume my work.

What an aggravating, disruptive, and completely unnecessary waste of my time and attention.

I hope Andrew has the good sense to let errors of this kind be silenced or demoted to warnings, perhaps with a compiler flag or debug build mode.

Post reply on HN