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

101–110 of 263 posts

Re: Zig: Build System Reworked

#101

Post by araoz »

xydone wrote: post #58
nromiun wrote: post #49

Is there any proposed timeline for a stable release? Big features like the recent async IO shows the language is very unstable right now.

There is no ETA on 1.0, but breakage has followed the pattern of it not really being hard to upgrade to a newer version, as it is very well documented on the version release notes.

writergate was not smooth, a lot of things that moved over to writer (Writer.Allocating for instance) had no documentation and I had to go read the zig source code to figure it out. the docs were just "instead of That use This"

Re: Zig: Build System Reworked

#102

Post by ksec »

nickmonad wrote: post #84
bluecalm wrote: post #55

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

Yes. And this kind of mentality is a near extinct in modern software development.

Re: Zig: Build System Reworked

#103

Post by magnio »

bbkane wrote: post #78
pjmlp wrote: post #32

Earlier quoted context omitted.

Yes, compilation speeds of the 90's are slowly making a return, thankfully.

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.

Re: Zig: Build System Reworked

#104

Post by metaltyphoon »

bbkane wrote: post #78
pjmlp wrote: post #32

Earlier quoted context omitted.

Yes, compilation speeds of the 90's are slowly making a return, thankfully.

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

Go changed something, not sure if 20 or 21, where it will download the Go compiler of all your third-party which don’t match yours. It slows things down.

Re: Zig: Build System Reworked

#105

Post by saintfire »

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

The unused variable error drives me insane

If they wanted the release build to be an error I wouldn't care. Having the current solution be "have the editor automatically change code to include or remove the underscore" is so wrong to me. Just invented a problem that needs tooling to modify source code to fix.

Re: Zig: Build System Reworked

#106

Post by araoz »

NewsaHackO wrote: post #82
ulbu wrote: post #46

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? zig is on its way to improving compilation times in its own pace and does so for the benefit of the project and everyone involved, so what is left to care for about bun by anthropic’s past?

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

Companies like TigerBeetle can and will benefit from zig's model.

Re: Zig: Build System Reworked

#107

Post by kibwen »

pmarreck wrote: post #86
miki123211 wrote: post #40

Earlier quoted context omitted.

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.

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

[flagged]

Re: Zig: Build System Reworked

#108

Post by ACCount37 »

cornstalks wrote: post #85
ACCount37 wrote: post #63

Earlier quoted context omitted.

Not really? I've been places, from embedded bare metal to ML AI, and that "embedded bare metal" end is the one place I don't use Python directly in. Embedded bare metal is just ruled by C forever. Bit of a shame, because C is kind of bad at its job, but nothing else has the "compatible with everything" badge of honor. The tooling around embedded devices though? Python.

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?

Re: Zig: Build System Reworked

#109

Post by wmedrano »

sourcegrift wrote: post #96

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

Try it if you want full control over every memory and IO operation and "drop". If you hit "goto-definition", you eventually get to see the OS switch statements and syscalls. There's not much magic.

Do not try it if you are scared of memory management and memory leaks.

Re: Zig: Build System Reworked

#110

Post by metaltyphoon »

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…

For me it’s string handling, no private, unused variable is compilation error, and having to implement interfaces myself.
Post reply on HN