[HN Gopher] Zig Guide
___________________________________________________________________
Zig Guide
Author : tosh
Score : 123 points
Date : 2025-02-05 18:45 UTC (4 hours ago)
(HTM) web link (zig.guide)
(TXT) w3m dump (zig.guide)
| tjkrusinski wrote:
| Zig is great, played with it a bit to compile to WASM and found
| it to be pretty easy to work with.
|
| That said, they're not winning on the docs, community and
| marketing front vs Rust. It's not really apples to apples, but
| it's a comparison people naturally draw.
| sroussey wrote:
| > The latest release of Zig is 0.13.0 and is currently
| unstable.
|
| The unstable part might be why. That said, I'm a little
| familiar with it as it's what Bun uses.
| sramsay wrote:
| 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 C libraries while I wait for a zig version. I'd rather
| just write C. Or work in a language that _is_ there with these
| kinds of things.
| pyrolistical wrote:
| 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
| sramsay wrote:
| 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).
| lukaslalinsky wrote:
| 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.
| pyrolistical wrote:
| I would argue zig had the best c integration. This is why
| it's different.
| sramsay wrote:
| Better than C++? Better than Lua?
| throwawaymaths wrote:
| arguably Zig's c integration is better than c's c
| integration.
| sramsay wrote:
| 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!)
| hardwaregeek wrote:
| In fairness to Zig, they're quite a bit younger. I have no
| doubt they'll catch up
| 2c2c2c wrote:
| problem is that the language started hitting its stride and
| getting attention while the core team is on a 2 year side quest
| of rewriting the compiler + incremental compilation
| androiddrew wrote:
| Zig sounds super appealing but yes the documentation and
| community resources are very lacking. Which is why I chose to
| learn Go this year over Zig.
| LenaAn wrote:
| 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?
| behnamoh wrote:
| it's funny how vibes have shifted from Rust to zig now. I wonder
| what programming language will be the hype in 2026!
| sundarurfriend wrote:
| To me, it seemed more like Rust and Zig started gaining
| popularity around the same time, a few years ago. Then people
| realized that Zig was in a much earlier state of development
| than they'd assumed, and had barely any resources to get into
| it, so the mindshare went mostly towards Rust alone. This is
| Zig is hitting a second wave.
| pyrolistical wrote:
| It probably just because C++ is more popular than C. Rust is
| a C++ replacement and zig is a C replacement.
|
| I see zig catching up in popularity because people are
| appreciating the simplicity it is trying to achieve.
| pjmlp wrote:
| As someone that was around when C started to be adopted in
| home computers, followed by C++ adoption several years
| later, and remembers C vs C++ flamewars on USENET, the
| popularity comparison made me smile.
| bobajeff wrote:
| 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?
| sundarurfriend wrote:
| 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.
| bikeshaving wrote:
| 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]: https://github.com/ziglang/zig/issues/2646
|
| [#2]: https://github.com/oven-sh/bun/issues?q=is%3Aissue+segfault
| lukaslalinsky wrote:
| 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.
| ngrilly wrote:
| Unlike C, Zig offers spatial memory safety, but it does not
| offer temporal memory safety.
| do_not_redeem wrote:
| 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.
| Rendello wrote:
| 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.
| modernerd wrote:
| It's not memory safe.
|
| People say, "oh, it's safer than C because tests can warn of
| missed deinits" but the fact is it isn't memory safe by design
| and it's not a priority for the language.
|
| There are still reasons to use it and there are domains where
| memory safety isn't a priority, but memory safety depends on
| the same mix of linters, code review, simple memory models, a
| deep understanding of how memory works, minimal dependencies
| and luck just like in C. Although none of those things will
| save you on their own or combined. If memory safety is a
| priority I'd consider other languages.
| pjmlp wrote:
| Think Modula-2, Object Pascal safety.
|
| Much better than C will ever be, but still with gotchas like
| use after free, or hardware mapped variables.
| matu3ba wrote:
| 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.githu
| b.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.
| lolinder wrote:
| > Neither Rust is memory safe due to stackoverflow on
| recursion or in the call chain being possible.
|
| Does a stack overflow trigger a crash, or does it cause
| undefined behavior and/or remote code execution? You'd have a
| point if it's the latter, but I also assumed that I would
| have heard about it before if that were true.
|
| And if it's not the latter, then it's not a failure of memory
| safety as most people mean it.
| steveklabnik wrote:
| There's stack probes that cause an abort.
| bikeshaving wrote:
| 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?
| throwawaymaths wrote:
| in principle static checking of memory safety in zig could be a
| thing, but there are some minor obstacles:
|
| https://github.com/ityonemo/clr
| whitehexagon wrote:
| 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.
| AndyKelley wrote:
| 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?
| unclad5968 wrote:
| 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.
| rewgs wrote:
| > I left Golang behind because of the same academic churn in
| language design that I saw in Swift.
|
| What? Go is one of the most stable languages I can think of.
| What churn are you referring to?
| nbobko wrote:
| 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.
| alberth wrote:
| FYI - it's not the official guide nor documentation.
|
| It should be better noted on this website, but this is not the
| official Zig guide - which can be found here:
| https://ziglang.org/learn/
|
| (And while yes, Zig does make reference to zig.guide because it's
| very helpful and people appreciate the effort put into it - but
| it's still under the other online learning resource section, not
| official documentation section)
___________________________________________________________________
(page generated 2025-02-05 23:01 UTC)