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

21–30 of 60 posts

Re: Zig Guide

#21

Post by sramsay »

pyrolistical wrote: post #15
sramsay wrote: post #5

Earlier quoted context omitted.

For me, it's the library problem. I read the guide and think, "Wow, this is really great!" Then I read the cookbook, and it mostly says that things (like database connectivity, regex, options parsing, even HTTP GET) are not quite ready for prime time, and I should just call out to C. Obviously, it takes time for a language to get there; I don't really mean this as a criticism. But I'm just not interested in wrapping…

Since c abi powers the world, with zig’s ability to easily wrap c libs, not only does zig have access to all libs; it also makes it easy to integrate zig with any existing project as most programming languages have integration with c. This is why everybody says just use some existing c lib

Hmm. I could substitute lots of languages for zig in that first sentence. But that doesn't invariably lead the communities that maintain those languages to utter the second.

I also doubt I have space to enumerate the languages that claim to "easily wrap c libs." None of them easily do that. That statement imagines that there's some basic consistency between APIs (and that those APIs are asking for and returning fairly simple types).

Re: Zig Guide

#22

Post by whitehexagon »

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 front, which was a bible during the rapid standard library expansion days, but the JVM stayed stable at least.

I left Golang behind because of the same academic churn in language design that I saw in Swift.

So at the moment I really love coding in Zig. It already does everything I need it too already, and anyway I cant upgrade past 0.8.1 because 'old mac', and wont run on Asahi M1 because 'new mac'. But I assume in trying to be a good C replacement, these are temporary limitations, especially now it can self compile.

What I really enjoy is that I can use it for very lightweight WASM / web front-end stuff, and at the other end of the client scale, I am using it for some SOC programming on the PinePhone. I know C has the same reach, but my days of looking up ** semantics in K&R are long past!

Hopefully we'll get a solid language spec soon, and the language changes will slow to a crawl once 1.0 approaches. As for the lacking documentation that is always a complaint, I'll hopefully try to contribute to that when I start my new Zig project in May.

Anyway respect and thanks to Andrew and the team for all the hard work they are doing. It is an amazing project and I hope it works out.

Re: Zig Guide

#23

Post by matu3ba »

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 am unaware of solutions. The former works via thread sanitizer, undo thread fuzzing and rr chaos mode, but I am unaware of solutions to test lock- and wait-free code besides trying really hard to create race conditions and comparing expected results to observe the race conditions, which does not cover temporal race conditions not observable at a later point.

Your statement like the general "safety" discussion is missing numbers on compilation time vs run time cost and coverage or any form of metrics to estimate risk vs benefit with cut-off values. Specifically input set/formulae coverage for functions and component planning would be interesting to discuss systems at scale (not basic code coverage), but I am unable to get decent information on that.

Re: Zig Guide

#24

Post by ngrilly »

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.

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

Re: Zig Guide

#25

Post by lukaslalinsky »

sramsay wrote: post #21
pyrolistical wrote: post #15

Earlier quoted context omitted.

Since c abi powers the world, with zig’s ability to easily wrap c libs, not only does zig have access to all libs; it also makes it easy to integrate zig with any existing project as most programming languages have integration with c. This is why everybody says just use some existing c lib

Hmm. I could substitute lots of languages for zig in that first sentence. But that doesn't invariably lead the communities that maintain those languages to utter the second. I also doubt I have space to enumerate the languages that claim to "easily wrap c libs." None of them easily do that. That statement imagines that there's some basic consistency between APIs (and that those APIs are asking for and returning fairl…

The thing is, all valid C types are also valid in Zig. You just `@cImport` the header file and use it. You don't need to wrap the API, you just use it.

Re: Zig Guide

#26

Post by AndyKelley »

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…

It's hardly an unpopular view when it's exactly the plan of the project, is it? Why do you think it's taking so long to reach 1.0?

Re: Zig Guide

#27

Post by unclad5968 »

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…

If you're interested in a c-like that isn't going to change, the crwator of Odin has said the language is basically done and further work is mostly on the standard library.

Re: Zig Guide

#28

Post by bobajeff »

behnamoh wrote: post #8

it’s funny how vibes have shifted from Rust to zig now. I wonder what programming language will be the hype in 2026!

From my perspective rust is still getting a lot (most) of the attention while zig has a loyal but smaller following. Odin (one I love) has an even smaller following still.

Personally, I don't really care about languages. I'll use whatever language I have to in order to try a library/engine I'm interested in. Currently I'm looking at trying Godot, Bevy and O3DE. As they all seem to be used to some extent right now. Note that none of those are written in Zig (or Odin). Maybe that will change after 1.0?

Re: Zig Guide

#29

Post by do_not_redeem »

ngrilly wrote: post #24
lukaslalinsky wrote: post #13

Earlier quoted context omitted.

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.

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.

Re: Zig Guide

#30

Post by nbobko »

It's good to have more documentation on Zig by the community, but I'm gonna throw in a bit of criticism.

One major thing I appreciate about the official Zig Language Reference is that it is no-pagination single html page that I can ctrl+f https://ziglang.org/documentation/master/ I wish more projects published their docs like that.

When I read, my mouse is busy selecting different parts of the text that I'm thinking about.

1. I don't want to move my mouse off the text to click the "next" button.

2. I don't want to move my mouse off the text to expand TOC items.

3. I don't want to waste my time on switching between pages back and forth.

I prefer the raw text on a long scrollable, non-interactive page with TOC on the side.

Otherwise, great to see more guides on the Zig topic.

Post reply on HN