Zig – io_uring and Grand Central Dispatch std.Io implementations landed • Hacker News Board

Re: Zig – io_uring and Grand Central Dispatch std.Io implementations landed

#311

Post by wolvesechoes » Tue, Feb 17, 2026, 7:11 AM UTC

kibwen wrote: post #285

wolvesechoes wrote: post #248

Earlier quoted context omitted.

These languages have origin in a different era, without Reddit, Twitter or HN to spam about them, do we cannot really compare adoption rates.

No, this is silly. You can look at the availability and maturity of toolchains, the rate of release of projects written in that language, the rate of release of books and learning materials, the rate at which universities begin teaching the language, the volume of discourse devoted to that language in magazines and the online venues which did exist (e.g. Usenet), and crucially the declining metrics of all of the abov…

> availability and maturity of toolchains

Pretty bad situation for Rust.

> the rate of release of projects written in that language

I guess back in 90s they didn't do grep clones every weekend, so Rust wins here definitely.

> the rate of release of books and learning materials

And what this data tells us?

> the rate at which universities begin teaching the language

Pretty bad situation for Rust.

> the volume of discourse devoted to that language in magazines and the online venues which did exist (e.g. Usenet)

But you need to normalize this volume against total volume of content out there produced every second, and then situation becomes complicated.

> crucially the declining metrics of all of the above for the direct competitors of that language

Why ignore job offerings?

Re: Zig – io_uring and Grand Central Dispatch std.Io implementations landed

#312

Post by uecker » Tue, Feb 17, 2026, 3:26 PM UTC

pjmlp wrote: post #295

epolanski wrote: post #194

Earlier quoted context omitted.

Sure, but considering that Zig is a modern C alternative, one should not and cannot afford to forget that C has been successful also because it stayed small and consistent for so long. The entire C, C ABI and standard lib specs, combined, are probably less words than the Promise spec from ECMAScript 262. A small language that stays consistent and predictable lets developers evolve it in best practices, patterns, desi…

> The entire C, C ABI and standard lib specs, combined, are probably less words than the Promise spec from ECMAScript 262. Not if you look into C23, include all the compiler extensions devs keep thinking are part of ISO C, and the "C ABI" is one per each existing OS written in C.

C23 did not increase a lot. The core language spec is also very small. Extensions are also often relatively simple, but most importantly, one does not have to use them. ABI is usually not per OS but per architecture.

Re: Zig – io_uring and Grand Central Dispatch std.Io implementations landed

#313

Post by uecker » Tue, Feb 17, 2026, 3:30 PM UTC

zozbot234 wrote: post #107

flohofwoe wrote: post #104

Earlier quoted context omitted.

It's not just about writing imperative code that runs at compile time, the actual interesting comptime feature in Zig is that "types are comptime values", e.g. you can inspect types and build new types with regular (comptime) code. This is very different from the template/trait systems in C++ and Rust. What Zig's comptime system is missing is the ability to build functions bodies at comptime (e.g. some sort of compti…

"You can inspect types and build new types at compile time" is a key affordance of dependently typed languages.

I agree. I am not terribly convinced by C++ or Zig's comptime. You should be able to do this at run-time, and then just be able to make it a constant.

Re: Zig – io_uring and Grand Central Dispatch std.Io implementations landed

#314

Post by jeltz » Wed, Feb 18, 2026, 6:30 PM UTC

lukaslalinsky wrote: post #307

audunw wrote: post #286

Earlier quoted context omitted.

I think another way of thinking about this interface is: it’s kind of like an abstraction over Linux system calls and ntdll. It’s naturally gonna have a kind of subset of all the useful calls, with some wrapping. I don’t see anything wrong with this, it’s kind of how Windows forces developers to use DLL to access syscalls (the syscall numbers can change) which IMO is a good architectural decision.

Except it's not. I've implemented it, over its multiple iterations, so I'm familiar with it. It's an interface to satisfy the needs of the Zig compiler. It's heavily lacking for use in server applications.

Except it is not. The Zig compiler does not need this. I am not sure if this API will work out but it is not for the Zig compiler.

Re: Zig – io_uring and Grand Central Dispatch std.Io implementations landed

#315

Post by pmarreck » Wed, Feb 18, 2026, 9:50 PM UTC

maleldil wrote: post #273

pmarreck wrote: post #271

Earlier quoted context omitted.

Docs on this?

Here[1]. This mentions async, but it affects every single use of IO functions. [1] https://kristoff.it/blog/zig-new-async-io/

Ah. Yeah.

My main Zig project will need over 1,000 edits to get it up there :O I've already had Claude spec out the changes required. I'll just have it or Codex or whatever fork itself into one agent per file and bang on it (for the stuff I can't regex myself) ;)

But the IO thing is frankly a good idea. I/O dependency injection, when I've used it in the past, has made testing quite a bit simpler (such as routing any I/O stream into a string to assert on) and the code much easier to reason about. The extra argument is a bit annoying, but that's the price of purity and it's worth it.