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

51–60 of 60 posts

Re: Zig Guide

#51

Post by throwawaymaths »

do_not_redeem wrote: post #29
ngrilly wrote: post #24

Earlier quoted context omitted.

Unlike C, Zig offers spatial memory safety, but it does not offer temporal memory safety.

Zig only has spatial memory safety in limited situations. For example: If you use many-pointers anywhere in your codebase, those places have no spatial memory safety. If you compile in ReleaseFast, you have no spatial memory safety at all.

in practice though you should be compiling ReleaseSafe and activating ReleaseFast only in functions where you need it (and that is the default)

Re: Zig Guide

#52

Post by lukaslalinsky »

throwawaymaths wrote: post #51
do_not_redeem wrote: post #29

Earlier quoted context omitted.

Zig only has spatial memory safety in limited situations. For example: If you use many-pointers anywhere in your codebase, those places have no spatial memory safety. If you compile in ReleaseFast, you have no spatial memory safety at all.

in practice though you should be compiling ReleaseSafe and activating ReleaseFast only in functions where you need it (and that is the default)

Even the Zig compiler is built with ReleaseFast for the published binaries.

Re: Zig Guide

#53

Post by dragonelite »

lukaslalinsky wrote: post #13
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 not memory safe, there is no way around it. It's really only as safe as C, with some helpers for making it easier to write safe code. You should really not use Zig unless you are prepared to deal with memory safety on your own. That makes it a good low-level language for system programming, but a VERY bad general purpose language. I'm writing this as a fan of Zig.

Because its not so strict and safe as Rust is what brings me joy for hobby and recreational programming. Its easy to track how and when memory is allocated because you need to pass an allocator to do it.

Re: Zig Guide

#54

Post by throwawaymaths »

lukaslalinsky wrote: post #52
throwawaymaths wrote: post #51

Earlier quoted context omitted.

in practice though you should be compiling ReleaseSafe and activating ReleaseFast only in functions where you need it (and that is the default)

Even the Zig compiler is built with ReleaseFast for the published binaries.

not sure what you think the safety parameters for compilation should be.

Re: Zig Guide

#55

Post by throw-the-towel »

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.

Wait, how come you even have HolyC experience?

Re: Zig Guide

#56

Post by Rendello »

throw-the-towel wrote: post #55
Rendello wrote: post #16

Earlier quoted context omitted.

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.

Wait, how come you even have HolyC experience?

For a few years I was a highly-paid TempleOS sysadmin for a fortune 500 company.

Just kidding ;) It was hobby development, of course. Building demos and games in HolyC was how I finally started learning lower-level software.

Re: Zig Guide

#57

Post by abu-matterize »

sundarurfriend wrote: post #10

I've been going through ziglings https://codeberg.org/ziglings/exercises/ and am a bit more than halfway through it. So far, it feels like though there's been a bunch of things to learn, they all fit together easily in a small mental space. It does generally feel like they've redesigned C for the modern times without going overboard, and succeeded to an admirable degree in the goal of being a simple language.

What's your feeling with it?

Re: Zig Guide

#58

Post by cztomsik »

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.

Rust is generally safer than Zig, but unsafe Rust is/was (mid)designed in such way that it's almost guaranteed to blow in your face eventually.

I don't know if mutable noalias has been already enabled for good, but even if there are no changes between compiler versions, those mutable noalias rules are super-tricky to get right.

In Zig, a pointer is just regular thing, you take care, but most pointers are arena-allocated anyway, and that's a bit like runtime-branded lifetime (which is great and Rust cannot do that, at least not in idiomatic Rust).

Re: Zig Guide

#59

Post by ulbu »

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…

off-topic, but relevant: (1) Asahi M1 will run zig soon - page size has already been pushed to runtime where it belongs. (2) if it doesn't yet, for personal use, you can hack it in with this one-liner "sd '(.visionos) (=> 16)' '$1, .linux $2' /std/mem.zig" (i'm using sd instead of sed, adapt if needed).

Re: Zig Guide

#60

Post by baranul »

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…

A lot of people have put Zig on pause or have outright rejected it. Nothing wrong with that (personal choice). Tsoding (well known YouTube programmer) makes fun of it and won't use it unless paid to.

Context is needed, in regards to safety. Zig, attempts to be safer than C, but then so do many other C alternatives and replacements. C3, Odin, Jai, Nim, D, etc... In fact, V (Vlang) could be seen as making a better argument for safety, because it provides even more default safety features and uses an optional GC. None of its libraries depend on the GC and it can be completely turned off (via cmdline flag).

Post reply on HN