HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
ziglang
zig
Zig2016–2026
ziglang / zig

zig

Moved to Codeberg

Languages & Compilers
Explore on GitHubRead Hacker News discussions
373Distinct people
681Mentions
3Explicit recommenders
43.3KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Moved to Codeberg

GitHub

Where it is used

  • Bun — Bun used the Zig programming language to implement its initial version of the runtime and tooling. This establishes Bun as a shipped product that was written in Zig. Source

What people are saying

My favorite of his https://x.com/joelreymont/status/1990981118783352952 > Claude discovered a bug in the Zig compiler and is in the process of fixing it! ...a few minutes…

rdtsc used a recommendation phrase. 3 indexed comments match. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 7:02:26 AM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year681 dated mentions

Observed mentions: 2016-01-08 12:54:33 UTC to 2026-09-19 17:18:26 UTC.

02550751001252016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 9 mentions; 1 submissions, 8 comments20162017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 21 mentions; 2 submissions, 19 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 34 mentions; 2 submissions, 32 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 60 mentions; 3 submissions, 57 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 111 mentions; 4 submissions, 107 comments20212022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 93 mentions; 8 submissions, 85 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 113 mentions; 12 submissions, 101 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 85 mentions; 5 submissions, 80 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 124 mentions; 9 submissions, 115 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 26 mentions; 1 submissions, 25 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC918
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC505
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC21219
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC34232
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC60357
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC1114107
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC93885
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC11312101
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC85580
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC1249115
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC26125

What Hacker News says

93 sources
elcritch·Dec 30, 2022
No, I'd count Zig as having more of an "open ended" type system / philosophy. Though, it looks like Zig doesn't do function overloading either [1]. That's a disappointment. So you end up with `array_count`, `map_count`, etc instead of just `count`. In my way of thinking that's more work reduces readability. It's one of the paint points of C vs C++ to need `array_list_count` and `hash_map_add` instead of just saying `vec.insert(...)`. The biggest ones for me in Rust is that it disallows extending traits for types you don't own, and the lack of function overloading. Neither of those are required for the borrow checker or safety, but it's a philosophical design decision. 1: https://github.com/ziglang/zig/issues/1251
In 50 years of C, the good, the bad and the ugly [video]
modernerd·Dec 26, 2022
The Zig Programming Language Discord has a zig-help channel that's pretty responsive if you're ok with Discord. The archive is searchable. https://github.com/ziglang/zig/wiki/Community#discord-englis.... GitHub's code search beta is a good way to find out how other people are doing things with Zig, if you have access to it. For example: https://cs.github.com/?scopeName=All+repos&scope=&q=http+pat... Some less-known walkthroughs for those new to Zig but comfortable in other languages: - A half-hour to learn Zig: https://gist.github.com/ityonemo/769532c2017ed9143f3571e5ac1... - Zig Crash Course: https://ikrima.dev/dev-notes/zig/zig-crash-course/ You can also see how other people have solved problems you might have: https://github.com/catdevnull/awesome-zig
In I wrote a Ruby extension in Zig
losvedir·Nov 17, 2022
Aw, I get that this is just showing off use cases for the new inline else feature, but from the title I was hoping it had more to do with this issue[0]. Having only used Zig enough for an Advent of Code, interfaces via a mechanism akin to rust's traits is probably my highest wishlist feature. If I understand the post here correctly, the version of interfaces shown affects the runtime data representation. And tagged unions have to be at least the size of the largest variant, sometimes plus the tag (right? Or is that just true in rust?). Ideally, to me, an "interface" can be used as purely a compile time constraint. With rust traits, to use the example in the post, when you define a function that takes an "Animal", it will basically generate a version of the function that takes a Cat, and one that takes a Dog, and double checks that Cat and
Read the rest
Dog both have `talk` implementations. So the tradeoff is you get static dispatch with no wasted space in the data representation, at a cost of more code generation. Zig's comptime is powerful enough, that you can maybe even implement this version of traits in "userland" code, and that linked issue has some neat examples, though I think it would be better in the compiler itself so it can more easily be used throughout the ecosystem and so it interacts better with tooling (e.g. doc generation). [0] https://github.com/ziglang/zig/issues/1268
In Easy Interfaces with Zig 0.10
j-pb·Oct 25, 2022
The bug that's currently blocking me from any work using master is https://github.com/ziglang/zig/issues/12325 That's not really a bug related to unfinished features that might get replaced anyways, but simply one involving recursive structs with pointers between, i.e. linked lists. Not detecting issues like these feels less like a "these parts are unfinished hence here be dragons" thing and more like a fundamental culture problem. I'm fine with cutting myself every now and then with a sharp tool and cutting edge technology, but that can also be done while having a ever growing and mature core that promises at least some stability. The only alternative seems to be to pull a Hickey and work on it for two years without releasing anything.
In Zig Is Self-Hosted Now, What's Next?
AndyKelley·Oct 25, 2022
If bugs are your concern, then this upcoming release is good news for you. Total number of open bug reports is 1,124. However if we remove bugs labeled "stage1" - that is - bugs that are no longer applicable because this release changes the default compiler to the self-hosted one - then the number drops to 514. It would be a fair characterization to say that this release cuts the number of known bugs in half. We have those stage1 bug reports still open because I mandated that every one must have test coverage before being closed, even though they are already fixed in master branch. That said, I would humbly ask for you to trust my leadership on finding the balance on how much effort to spend on bug fixing versus how much to spend on progress. I think you underestimate how much is going to change before Zig tags 1.0. There are still a few
Read the rest
experimental and exploratory changes planned, and when software specifications change, bugs are inevitably introduced. Spending the time to iron out 100% of the bugs found from fuzz testing, on a feature that ends up replaced with a different one that also needs to get debugged, is a waste of time, and a disservice to the wider user base of the project. We're better off finding the "sweet spot" for a swift journey, arriving at our destination early, and then busting out the hardcore QA. I see https://github.com/ziglang/zig/issues/13211 mentioned elsewhere in this thread. I want to point out that getting the C ABI correct when using LLVM is a notoriously perilous process, as any other compiler dev reading HN today can attest, and this regression which lasted for a total of 6 days in master branch without ever gracing a tagged release, is a symptom of the fact that we actually addressed this C ABI problem at its core, added more test coverage, added an abstraction in the LLVM code generation, and fixed the C ABI for several targets. And finally, I agree that fuzz testing should be integrated into Zig's unit testing system. That would be a nice enhancement.
In Zig Is Self-Hosted Now, What's Next?
kristoff_it·Oct 25, 2022
We do have a good number of known miscompilations, I can substantiate for the parent poster with a simple link: https://github.com/ziglang/zig/labels/miscompilation It's also true that the self-hosted compiler has caused new bugs to pop up, which in turn made us write new behavior tests. To me that's to be expected with every project aimed at rewriting an existing system. It's also true that proper testing infrastructure is critical, and we do have it, although the requirement of more than 8gb of ram has not played in our favor in the past. We plan to revamp our CI systems once we are done with this release. That said, it's a v0 language. If you choose to use it, you know you're coming with us on a ride. The choice of how much to prioritize correctness vs progress is influenced by many things that are going on in the project and there is
Read the rest
no one clear strategy that trumps all others. Quoting j-pb from another comment: > A language that (does or doesn't) compile your code in 0.1 seconds to a broken binary is worse than piping your code into dev/null. Eh, yes, but also no. Obviously a compiler needs to work correctly to be useful, but our priority right now is to move the project forward using our best judgment, not ensure that it has maximal utility to early adopters. I do agree with the sentiment that the compiler needs to be reliable, it's just that Zig is v0 for a reason. In concrete terms I think that once we're done with an initial adjustment phase, you will find that the compiler will have a steady increase in stability over time. That's how it was with the bootstrap compiler before we started the self-hosted work. Also, quoting dist1 from up the comment tree: > I'm not so familiar with Zig, are you saying that the compiler fails to compile correct (i.e. according to spec) code? Keeping in mind everything that I just wrote, note that Zig doesn't have a spec yet. Sometimes, some issues in the compiler are the result of discovering that a design choice needs to be amended. Recent example of that: https://github.com/ziglang/zig/issues/12251
In Zig Is Self-Hosted Now, What's Next?
cyber_kinetist·Oct 17, 2022
Hmm... after some research it seems that I've misunderstood Zig's situation a bit. Zig has introduced null-terminated string types a couple of years ago, but still encourages you to do most string operations with slices instead. Let me explain: Zig's string literals (which you create with parenthesis like "Hello world!") are null-terminated byte arrays, expressed as the type *const [N:0]u8 (where the :0 tells you that it's null-terminated), whereas the more typical array might be written as *const [N]u8. The reason for this feature is not because the language wants you to use null-terminated strings, but because these static strings need to be stored in the global data section of the ELF executable, and these require you to use null-termination. But if you want to do any mutable operation with this string, you need to convert this into a
Read the rest
proper slice (ptr + size). And it seems like Zig developers don't really use null-terminated types that much at the API level, but use it for things like C interop or cases where you really need it for special optimizations. Noting that from the PR that introduced this feature, Andrew Kelley writes [0]: > I think you will find that the Zig community in general (and especially myself) agrees with you on this [null-terminated strings being fragile], and APIs in general should prefer slices to null terminated pointers. Even if you are using Zig to create a C library, and even in actual C libraries, I would recommend pointer and length arguments rather than null terminated pointers, like this: https://github.com/andrewrk/libsoundio/blob/1.1.0/soundio/so... > That being said, I want to repeat what I said earlier about null terminated pointers: A null terminated array is not inherently an evil C concept that is intruding in the Zig language. It's a general data storage technique that is valid for some memory constrained use cases. I also stumbled on a Real Actual Use Case inside LLVM. The bottom line for me is that null terminated pointers exist in the real world, and especially in systems programming. You can see this in interfaces with the operating system in the standard library... So he acknowledges null-terminated strings can certainly be useful in certain situations outside of legacy reasons, which is good to know. And Zig creating a special type for this shows that a good systems language needs to be designed to accommodate the needs of the outside world. [0] https://github.com/ziglang/zig/issues/265#issuecomment-46337...
In Learn enough C to survive
gavinray·Oct 13, 2022
I like this idea a lot. Are there any other databases which do a similar thing? This seems like one of those things that has massive benefit if you're willing to invest in the effort + architect it like that from the start. (Unrelated note: I discovered last night that Zig has io_uring support and some nice wrappers implemented in "std". Which is nice for usecases like databases or networked services) https://github.com/ziglang/zig/blob/42a3b60c331cf01d1ab80eb7...
In A database without dynamic memory allocation

Showing the 15 most recent of 93 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.