GBgbuk2013·Nov 11, 2018
From the video:
> Documentation is about 80% done
And yet there is not standard library documentation. :(
https://github.com/ziglang/zig/issues/965
In Zig: software should be perfect [video]ziglang
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 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 12:01:02 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.
* 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
21 sourcesI think Zig would be better suited.
See: https://github.com/ziglang/zig/wiki/Why-Zig-When-There-is-Al...
In Is it time to rewrite the operating system in Rust? [slides]Can you link to Nim's userland implementation of printf? Here's zig: https://github.com/ziglang/zig/blob/822d4fa216ea8f598e4a9d53...
In Why Zig When There Is Already CPP, D, and Rust? (2017)Why Zig When There Is Already CPP, D, and Rust? (2017)
141 points · Open discussionThere's an allocator in the standard library that is specifically designed to fail.
https://github.com/ziglang/zig/blob/master/std/debug/failing...
In LLVM 7.0.0 releasedHere's an excerpt from std.ArrayList[1]:
pub fn ArrayList(comptime T: type) type {
return struct {
const Self = @This();
raw_items: []T,
len: usize,
allocator: *Allocator,
// ...
pub fn append(self: *Self, item: T) !void {
const new_item_ptr = try self.addOne();
new_item_ptr.* = item;
}
pub fn addOne(self: *Self) !*T {
const new_length = self.len + 1;
try self.ensureCapacity(new_length);
return self.addOneAssumeCapacity();
}
// ...
};
}
test "std.ArrayList.basic" {
var bytes: [1024]u8 = undefined;
const allocator = &std.heap.FixedBufferAllocator.init(bytes[0..]).alloca
Read the rest
tor;
var list = ArrayList(i32).init(allocator);
try list.append(1);
try list.append(2);
try list.append(3);
assert(list.len == 3);
}
In summary, functions that can fail have an inferred error set, or an explicit one[2]. At the callsite of functions that can fail will either be `if`, `while`, `catch`, or `try`, in order to deal with the error case.
[1]: https://github.com/ziglang/zig/blob/e3d8cae35a5d194386eacd9a...
[2]: https://ziglang.org/documentation/master/#Error-Set-Type
it does, the same as how it does in clang with -O3. There's an open issue for adding guaranteed tail call semantics: https://github.com/ziglang/zig/issues/694
it's an important issue for the project because one of the things it is tackling is the problem of unbounded stack growth. zig wants to get to a state where upper bound stack size is known at compile-time.
In LLVM 7.0.0 releasedI understand the question, but as @AndyKelley taught me (https://github.com/ziglang/zig/pull/993#commitcomment-289183...), it is actually worse to zero a value unnecessarily if you can use Valgrind/sanitizers to check for uninitialized values. Initializing the value as zero will prevent the detection of a bad value.
In Reading the NSA’s codebase: LemonGraph reviewMy understanding is that Rust uses LLVM coroutines[1]. In order to have the behavior where the function does not start executing immediately, you would follow the example that you can find by searching for "injected suspend point, so that the coroutine starts suspended". So what this looks like is:
* Function call
* The coroutine creates its frame (I believe this maps to "future creation".)
* Function return (the injected immediate suspend)
* (sometime later) Put the work on the event loop
* Function call (suspend resume)
* Function executes until a suspend point
Eager execution has no injected immediate suspend, so it looks like this:
* Function call
* The coroutine creates its frame
* The function executes until a suspend point (function return)
That's it. The coroutine is responsible for making sure that it gets resumed appropriately i
Read the rest
f it suspends. Await doesn't do anything with an event loop; it just suspends and then puts the suspended coroutine handle in the target coroutine's frame with an AtomicRMW. If it turns out the target coroutine already completed, then it grabs the result, destroys the target coroutine, and cancels suspending (which is a jmp instruction). Otherwise the suspend completes and the target coroutine will resume the suspended one when it completes.
> If you have a program that only uses async & await and no concurrency primitives, the code in your program will execute in a defined, statically known, linear order.
This is true with eager execution as well. You can see some examples here [2].
One more side note, how eager execution was valuable to me in the self-hosted compiler:
pub async fn renderToLlvm(comp: *Compilation, fn_val: *Value.Fn, code: *ir.Code) !void {
fn_val.base.ref();
defer fn_val.base.deref(comp);
// ...
}
At the callsite we make an async call to renderToLlvm, passing in a ref-counted fn_val. If the body didn't execute immediately, the callsite might deref fn_val and destroy it before renderToLlvm gets a chance to add a reference, but because of eager execution, the ref is guaranteed.
[1]: http://llvm.org/docs/Coroutines.html
[2]: https://github.com/ziglang/zig/blob/363f4facea7fac2d6cfeab9d...
Why Zig When There Is Already CPP, D, and Rust?
5 points · Open discussionLearn Zig (https://github.com/ziglang/zig). Aims to be lightweight alternative to Rust, similar to how C is lightweight alternative to C++. Both Zig and Rust use LLVM backend and borrow some concepts from the LLVM IR.
In Ask HN: Best programming language or theory to learn before learning Rust?It should be noted that 0.2.0 is significantly different than master in regards to pointer syntax due to pointer reform [0]. There are a lot of other changes too, but that one's the most noticeable.
[0] https://github.com/ziglang/zig/issues/770
In Pointers Are More Abstract Than You Might Expect in C> I think there's room for other languages to occupy a similar space but they're need to focus on no-std-lib no-runtime operation (not always the sexiest target).
You're describing the Zig language!
It aims to be as fast as C, and unlike most languages that say this is a goal, it means it. There's no "almost as fast as C if you ignore the garbage-collector and the array-bounds-checking", it's actually as fast as C.
Its author values the minimalism of C, but wants to create a far better language for doing that sort of work. [0]
They're doing surprisingly well. They even managed to make a faster-than-C (faster even than hand-tuned assembly) SHA-2 [1]
[0] https://andrewkelley.me/post/intro-to-zig.html , https://github.com/ziglang/zig/wiki/Why-Zig-When-There-is-Al...
[1] https://ziglang.org/download/0.2.0/release-notes.html , it's also mentio
Read the rest
ned somewhere in this talk https://youtu.be/Z4oYSByyRak
There is at least this comment in the docs:
> Zig is taking cues from Jai's stance on allocators, since that language is being developed by a high-performance game designer for the usecase of high-performance games."
https://github.com/ziglang/zig/wiki/Why-Zig-When-There-is-Al...
In I Quit My Job to Live on Donations to ZigShowing the 15 most recent of 21 sources. Enable JavaScript to search and browse every indexed mention.