COcodygman·Aug 30, 2016
In Zig: a system language which prioritizes optimality, safety, and readabilityziglang
zig
Zig2016–2026
ziglang / zig
zig
Moved to Codeberg
373Distinct people
681Mentions
3Explicit recommenders
43.3KGitHub stars
What to know before exploring
What it is
Moved to Codeberg
GitHub
Where it is used
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
- tigerbeetle/tigerbeetle · linked in 6 of the same discussions
- llvm/llvm-project · linked in 2 of the same discussions
- oven-sh/bun · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 7:56:55 PM 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.
* 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
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 9 | 1 | 8 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 21 | 2 | 19 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 34 | 2 | 32 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 60 | 3 | 57 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 111 | 4 | 107 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 93 | 8 | 85 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 113 | 12 | 101 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 85 | 5 | 80 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 124 | 9 | 115 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 26 | 1 | 25 |
What Hacker News says
9 sourcesMake issues. I made one for the %% operator:
https://github.com/andrewrk/zig/issues/176
In Zig: a system language which prioritizes optimality, safety, and readabilityhttps://github.com/andrewrk/zig/issues/89
As long as we rely on libclang and LLVM there will be a part of the compiler written in C++, and I foresee these dependencies sticking around.
In Zig: a system language which prioritizes optimality, safety, and readabilityZig: remove multiline comments
3 points · Open discussionZig (https://github.com/andrewrk/zig), "a system programming language intended to replace C", has a lot of those features.
In Crystal: Fast as C, Slick as RubyI'm working on a new language that has inline assembly and I pretty much just copied GCC's syntax[1]. Do you have any specific suggestions on how to do better?
[1]: https://github.com/andrewrk/zig/blob/master/std/linux_x86_64...
In Inline assembly in LinuxWhat exactly does the author mean by "C/C++ compatible"?
Because my language[1] just got the ability to directly include .h files and access to the functions and symbols therein. Small snippet[2]:
c_import {
@c_include("GLFW/glfw3.h");
@c_include("stdlib.h");
@c_include("stdio.h");
}
I realize this probably comes across as trying to one-up another person's work but I just got this working a few minutes ago and I'm really excited to demo it!
[1]: https://github.com/andrewrk/zig
[2]: https://github.com/andrewrk/tetris/blob/aaf09e30a3a7b9ed8f34...
OK I think I understand what the author means by "C/C++ compatible". Check out this snippet[3]
> Note that there is no #include line in the source file. The ZL prelude includes some of the more common functions from the C standard library and ZL source files are not
Read the rest
run through the C preprocessor by default.
The driver script zlc is meant to act as a drop drop in replacement for GCC. For example,
> zlc main.zl file1.cpp file2.zlp -o main
I think that zl compiles to C and also acts as a compiler driver.
[3]: http://zl-lang.org/doc/zlch2.html
The author linked to this site: https://www.securecoding.cert.org/confluence/display/c/SEI+C...
These are wonderful. Concise nuggets of knowledge that you can keep in your head, little warnings of what not to do.
Side note, it's really fun reading this article about modern C given that I'm working on an experimental programming language meant to replace C [1]. Just today I got the Guess Number Game example working, without a dependency on libc [2] (caveat: Linux x86_64 only so far). So, I'm having fun trying to think about how C could be better, reading implementations of various libc functions, and writing my own "standard library".
For example, in my language, there are no `int`, `unsigned char`, `short` types, there are only `i32`, `u8`, `i16`, etc (I shamelessly stole this idea from Rust). This mirrors the article's suggestion to only
Read the rest
use int32_t, uint8_t, int16_t, etc. But, since it's a new programming language, we don't have the other types sitting there as a red herring.
[1]: https://github.com/andrewrk/zig
[2]: https://gist.github.com/andrewrk/131e6f48a15c42fc5ca8