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

Zig Guide

zig.guide

Post reply on HN
Print view View original

41–50 of 60 posts

Re: Zig Guide

#41

Post by Rendello »

Rendello wrote: post #16
bikeshaving wrote: post #12

I love Zig and I love that it’s getting attention, but can someone convince me of its memory safety? One thing that surprised me is that returning pointers to stack-allocated memory doesn’t cause a compiler error — it just segfaults at runtime. This has been an open issue since 2019 [#1]. That, along with the number of memory-related issues in one of Zig’s most popular project, Bun.js [#2], gives me pause. [#1]: http…

There was a discussion yesterday in which the blog author stated (and elaborated on) "I strongly disagree that Zig is safer than — even — unsafe Rust. Anyone telling you otherwise is either purposefully lying, or ignorant". That has been my experience as well. The sorts of errors I ran into were the same as in my C and HolyC experience, and not the sorts of errors I get with Rust.

I meant to link it earlier: https://news.ycombinator.com/item?id=42942618

Re: Zig Guide

#42

Post by matu3ba »

bikeshaving wrote: post #37
matu3ba wrote: post #23

Earlier quoted context omitted.

Neither Rust is memory safe due to stackoverflow on recursion or in the call chain being possible. Sanitation is very much possible, so it is no design problem, see https://matu3ba.github.io/articles/optimal_debugging/#practi... . More interesting would be threading and process/shared memory synchronization problems and limitations. At least on Linux in theory the latter should be fuzzable with scheduler API, but I a…

My definition of safety is simply how many memory/UB bugs escape to production. This is quantifiable. Looking at open-source Zig projects, even highly competent programmers seem to be struggling. I’d love to dig deeper into what’s causing all these panics: how much comes from Zig’s great interop story, how much from common language footguns, and how much from its non-global-allocator-passing philosophy?

If you have the data set of known bugs, going through them should give you the cause. I do expect a strong correlation of basic coverage for simple UB things and input set/formulae coverage for the harder to hit ones, specifically as the code scales.

For formal proofs the effort scales quadratically, does Rust code also become quadratically slower with some constant factor? I'd assume runtime-checks could provide statistical safety and each component may need statistics tweaking unless being small enough/verified/edge cases enumerable with reasonable certainty etc. Are you aware of any known statistics or work besides the 0,x bugs per 1000 lines of code taking into account classes of bugs? Or what is your take on this?

Re: Zig Guide

#43

Post by rc00 »

sramsay wrote: post #40
throwawaymaths wrote: post #38

Earlier quoted context omitted.

arguably Zig's c integration is better than c's c integration.

How so? (If you're hearing a combative tone, it's unintended; I'm asking seriously, because I would love for this to be true!)

In C, C imports are in the global namespace. The language is also compiled sequentially, so often, time is spent ensuring headers are included in the proper order, hopefully avoiding a cyclic dependency. In Zig, C imports are done in a struct with a local namespace or imported package definition and the ordering is not relevant to compilation.

I think parent means that Zig is a better language with regards to being the target for C to be imported into than C and that is the benefit of being a more modern language with flexibility following more modern conventions. This is combined with the mostly seamless ability to utilize most C functions and types without too much strife.

Re: Zig Guide

#44

Post by rc00 »

LenaAn wrote: post #6

I first heard about zig this May and since then I hear more and more often about it. I wonder if it’s baader-meinhof or is Zig actually gaining popularity?

Both things can be true. This most recent hype cycle seems to be riding the wave from the related hype of Ghostty's public release and Bun's latest release. And recently, another project with decent name recognition by some announced intentions to rewrite in Zig. Other than the latter event which is merely an announcement as of now, this language is showing up in projects that people are paying attention to. That only brings more attention and to a degree, a certain amount of credibility, especially when the lead developer for Ghostty has a well-earned and positive reputation among the engineering community.

Re: Zig Guide

#45

Post by matu3ba »

matu3ba wrote: post #23
bikeshaving wrote: post #12

I love Zig and I love that it’s getting attention, but can someone convince me of its memory safety? One thing that surprised me is that returning pointers to stack-allocated memory doesn’t cause a compiler error — it just segfaults at runtime. This has been an open issue since 2019 [#1]. That, along with the number of memory-related issues in one of Zig’s most popular project, Bun.js [#2], gives me pause. [#1]: http…

Neither Rust is memory safe due to stackoverflow on recursion or in the call chain being possible. Sanitation is very much possible, so it is no design problem, see https://matu3ba.github.io/articles/optimal_debugging/#practi... . More interesting would be threading and process/shared memory synchronization problems and limitations. At least on Linux in theory the latter should be fuzzable with scheduler API, but I a…

Looks like my definition of memory safety is wrong and it means only "Runtime makes sure incorrect memory reads/writes are not possible", not by what means, so crashing is under that definition ok.

Re: Zig Guide

#46

Post by throwawaymaths »

rc00 wrote: post #43
sramsay wrote: post #40

Earlier quoted context omitted.

How so? (If you're hearing a combative tone, it's unintended; I'm asking seriously, because I would love for this to be true!)

In C, C imports are in the global namespace. The language is also compiled sequentially, so often, time is spent ensuring headers are included in the proper order, hopefully avoiding a cyclic dependency. In Zig, C imports are done in a struct with a local namespace or imported package definition and the ordering is not relevant to compilation. I think parent means that Zig is a better language with regards to being t…

ease of cross compilation as well.

Re: Zig Guide

#47

Post by esjeon »

bikeshaving wrote: post #12

I love Zig and I love that it’s getting attention, but can someone convince me of its memory safety? One thing that surprised me is that returning pointers to stack-allocated memory doesn’t cause a compiler error — it just segfaults at runtime. This has been an open issue since 2019 [#1]. That, along with the number of memory-related issues in one of Zig’s most popular project, Bun.js [#2], gives me pause. [#1]: http…

Zig is unsafe, but, instead, it encourages more strategic approaches for memory management. Period.

In case of Bun, it's kind of mixed bag, as it relies on JSCore from WebKit. A lot of its issues are from the the engine.

Re: Zig Guide

#48

Post by bikeshaving »

matu3ba wrote: post #42
bikeshaving wrote: post #37

Earlier quoted context omitted.

My definition of safety is simply how many memory/UB bugs escape to production. This is quantifiable. Looking at open-source Zig projects, even highly competent programmers seem to be struggling. I’d love to dig deeper into what’s causing all these panics: how much comes from Zig’s great interop story, how much from common language footguns, and how much from its non-global-allocator-passing philosophy?

If you have the data set of known bugs, going through them should give you the cause. I do expect a strong correlation of basic coverage for simple UB things and input set/formulae coverage for the harder to hit ones, specifically as the code scales. For formal proofs the effort scales quadratically, does Rust code also become quadratically slower with some constant factor? I'd assume runtime-checks could provide sta…

I haven’t gone so far as to create a dataset, but you can use GitHub search to quickly peruse the top open source Zig repositories: https://github.com/search?q=+language%3AZig+stars%3A%3E1000&....

All of them, with the notable exception of tigerbeetle, a financial transactions database, have issue trackers which are littered with users reporting segfaults. I don’t really know if it’s more common than in popular Rust repositories, but this is my highly anecdotal, qualitative investigation.

What worries me is that when you dig into specific issues for root causes, there seem to be a lot of different root causes and not a lot of obvious fixes. And segfaults are just the tip of the iceberg, the most obvious memory errors. I don’t think people are reporting heap corruption in the same way, if ever.

Re: Zig Guide

#49

Post by gowk »

whitehexagon wrote: post #22

I know it is not a popular view, but I really hope Zig becomes as stable in language design as C. I am tried of language design as an endless project of 'change because we can'. I switched from objective-c to swift thinking job done, and felt like I was learning a new language with each new version. I ended up switching back to objective-c. I think Java had a good start by defining a solid language spec (JLS) up fron…

Go stands out for its remarkable stability in language design. The Go team has maintained a strict backward compatibility promise since its first release in 2012. While Swift underwent significant breaking changes between versions 1.0-5.0, Go's evolution has been cautious and gradual. Even major features like generics (Go 1.18) were introduced after years of careful consideration. This stability and backward compatibility have made Go a trusted choice for enterprise development.

Re: Zig Guide

#50

Post by throwawaymaths »

sramsay wrote: post #40
throwawaymaths wrote: post #38

Earlier quoted context omitted.

arguably Zig's c integration is better than c's c integration.

How so? (If you're hearing a combative tone, it's unintended; I'm asking seriously, because I would love for this to be true!)

no combative tone detected.

for example if two c libs declare a function with the same name youre not gonna have a good time using them both from c. I believe that's not a problem in zig.

Post reply on HN