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

Post by dnautics » Mon, Feb 16, 2026, 1:26 PM UTC

pjmlp wrote: post #297

dnautics wrote: post #217

Earlier quoted context omitted.

wow, what a list! all of these are statically analyzable using a slightly hacked zig compiler and a library! https://github.com/ityonemo/clr (Btw: you can't null pointer dereference in zig without using the navigation operator which will panic on null; you can't misalign a pointer unless you use @alignCast which will also create a panic)

I can also analyse C and C++ code for such issues, while keeping using a mature languages ecosystem.

Post by pmarreck » Mon, Feb 16, 2026, 1:48 PM UTC

praveer13 wrote: post #162

pmarreck wrote: post #133

Earlier quoted context omitted.

Apologies, but your information is either outdated from lack of experience with the latest frontier models, or you don't realize the fact that 99.9% of the work you do is not novel in all capacities. Have you only used Copilot, or something? Because that's what it sounds like. Since the performance of the latest models (Opus 4.6 max-effort, gpt-5.3-Codex) is nothing short of astonishing. Real-world example: Claude is…

I’ve been making a project in zig 0.16 with Claude as a learning experiment. It’s a fairly non trivial project (BitTorrent compliant p2p downloader for model weights on top of huggingface xet) - whenever it doesn’t know the syntax or makes errors, it literally reads the standard library code to understand and fix it. The project works too!

Post by dnautics » Mon, Feb 16, 2026, 5:09 PM UTC

pjmlp wrote: post #304

dnautics wrote: post #301

Earlier quoted context omitted.

If you can statically analyze c for memory safety, why did pazlo bother building fil-C?

Where did I wrote that static analysis was enough on its own?

Post by lukaslalinsky » Mon, Feb 16, 2026, 6:06 PM UTC

audunw wrote: post #286

lukaslalinsky wrote: post #68

I don't want to be the negative guy, but this is news about two unfinished implementations. There is a lot of work needed for this to be considered done. For example, no networking in the GCD version yet. And as these are being implemented, the interface stops being an interface, the vtable keeps growing, and it's just the current snapshot of what's needed by the std implementations.

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.

Post by xnoreq » Tue, Feb 17, 2026, 6:36 AM UTC

hxtk wrote: post #97

jauntywundrkind wrote: post #66

Contrary to the neggies, I am positive in Zigs effort to iterate & improve. Right now there is no language that is good at io-uring. There are ok offerings, but nothing really has modern async joy that works with uring. Whoever hammers out a good solution here is going to have a massive leg up. Rust is amazing in so many ways but it has been quite a brutal road to trying to support io-uring ok, and efforts are still…

It’s surprising to me how much people seem to want async in low level languages. Async is very nice in Go, but the reason I reach for a language like Zig is to explicitly control those things. I’m happily writing a Zig project right now using libxev as my io_uring abstraction.