Zig’s Io.Threaded is neat

Join the discussion

• Hacker News
• I know syntax does not REALLY matter, but Zig is just kind of subpar syntax wise. Its really verbose and picked weirdly from what already exists. Zig code is usually hard to read because it really noicy, and has weird things not existing in other languages without merit.
  by phplovesong
• Of course syntax matters in any programming language. That is like saying the alphabet and grammar does not really matter in English.
  by nromiun
• You might be interested in this recent talk which argues concrete syntax does actually matter: https://slim.computer/concrete-syntax/
  by ModernMech
• I don't think that it's really subpar. It's just unusual compared to others. In and of itself it's very consistent. For instance there's `|capture|` for capturing all sort of things(errors, optionals, ...) in nearly all control flow constructs. `blk:` for naming blocks, `if`s, `switch`, and so on. Have a look at this blog post: https://matklad.github.io/2025/08/09/zigs-lovely-syntax.html
  by pzittlau
• Well, compared to what? Zig is much nicer to read than Rust or C++, about the same as Typescript, but not as nice as modern C.

  But that's just my opinion.

  Such questions usually come down to "how familiar am I with this programming language", and anything that doesn't look like your pet language looks ugly. Except Rust and C++ of course, those are objectively ugly ;P

  by flohofwoe
• I'm shipping in Rust but any reason to do so in Zig ? What does it offer over Rust ? Something tangible benefit to end user or developer using ai assisted development ?
  by zuzululu
• I often use LLMs to build and modify open-source tools for personal use and Rust's compile times are disgusting, eg. Codex CLI taking over 15 minutes to recompile on my fairly high-end machine. Zig's incremental compilation optimizations are amazing, giving near-instant recompiles measured in ms instead of minutes. I would certainly classify four orders of magnitude faster compilation as a tangible benefit even if you're not writing the code by hand.
  by applfanboysbgon
• Zig lets you be very explicit about what you want. Zig's hello world takes 3 or 4 lines where other languages take 1. That is how much other languages make decisions for you. Some people care to make those decisions themselves.
  by hiccuphippo
• Zig's compiler somehow feels lightweight to me compared to Rust's. When i develop something in Rust, the compiler and LSP is overheating my CPU. So im using Zig nowodays for long life my laptop.

  When I had problems in my Zig codebase(latest version), the LLM cant resolve my problem. It kept giving me results based on older versions of the Zig code. This was due to breaking changes in every version. Thats why I no longer ask the LLM for help with Zig-related code. The folks on Zig Discord server and its forum, helps me very much.

  by ErenayDev
• Use Rust if you're not writing code yourself.

  The borrow checker will catch all kinds of bugs that AI-generated code will happily compile in Zig but will blow up as UB at runtime.

  Zig's value prop is different and closer to a modern C: it fits in your head and maps fairly closely to assembly. There is no hidden control flow or hidden allocations, so you can tweak performance at a very low level. You're the pilot, not the compiler.

  Rust trades the low-level clarity for compiler-enforced safety. If you're not a code artisan or don't care about being one, then please use Rust.

  by rahen
• Just use C, these are well understood things 20 years ago.
  by up2isomorphism
• The way Zig handles the transition between synchronous and asynchronous I/O without requiring a heavy runtime is a masterclass in systems design. I'm particularly interested in how this approach to blocking calls might simplify mobile development where thread-per-request isn't always feasible but async/await coloring remains a pain. Does this implementation handle thread pool exhaustion gracefully if a large number of 'threaded' tasks block simultaneously?
  by fenestella
• Cool writeup but... Signals are not some opaque or roundabout feature to do this. Signals are a thing for a reason and this is how it's implemented in any threaded I/O library I've read.
  by inglor
• how do they handle that malloc aint async signal safe?
  by Asmod4n
• Ye, but signals are cumbersome and a foot gun. Should a library ever install signal handlers? What about languages with runtimes? Ever read the spec on how go handles signals differently depending on how it is compiled?
  by eptcyka
• Oh man this finishes too early, I would want to read more!
  by two_handfuls
• It got cancelled halfway
  by skrebbel
• Agreed.

  There's this line:

  > Wouldn’t it be cool if we could just use standard OS threads, blocking APIs, avoid new shinies like io_uring, but still get to cancel any work reliably?

  Wish more was said about this: why would that be cool? I get that having robust cancellation in standard threads is cool, but why do we want to avoid io_uring?

  by memco
• All my days of low level stuff were in the windows world where async/cancel was supported since nt kernel days at least. Wrapping this coherently at some level of abstraction was always worth doing, although threads are just one way. Overlapped I/O let you do it all on one thread. Linux looks harder.

  Great that Zig is supporting this more “first class”; not strictly required, but looks useful.

  by lll-o-lll
• If you are comparing to overlapped I/O, you should use io_uring as reference and cancellation in io_uring is fairly simple.
  by lukaslalinsky
• Just here to say that Java as interruptible channels since the beginning of 2000.

  You can interrupt a blocking IO operation with either interrupt() or close().

  https://docs.oracle.com/en/java/javase/25/docs/api/java.base...

  by _old_dude_
• Name checks out.
  by dtj1123
• I know some people hate on it, but I genuinely think that NIO is pretty good just in general.

  It actually kind of annoys me; I feel like most Java code I've had to debug/maintain is slow and terrible because most Java engineers lack any ambition so they write the old terrible IO that they learned in university, and for years I guess I kind of erroneously assumed that Java was "bad" at doing IO.

  Then I read a book on NIO, started writing my own code with channels and selectors and realized that it actually works quite well, and I found it relatively intuitive and performance was pretty solid.

  This is actually a recurring pattern I've found in the Java world; Java has added a lot of great features over the years that make the language more ergonomic and performant and fun to write, but due to its prevalence in the "Enterprise" world and university, it selection biases towards people who refuse to learn anything new, meaning that a lot (the majority?) of Java code feels like it was written in 1997.

  I have been writing a lot of Java in my free time, unapologetically using Java 17, 21, and 25 features, and I am actually enjoying it.

  by tombert
• You might want to read the “prior art” section of their article…
  by gdcbe
• Pretty sure you've been able to interrupt a thread blocked on IO in a normal InputStream since 1.0.2 in 1996.

  There is a significant caveat to this, which is that if the underlying blocking IO operation isn't natively cancellable (and the JDK doesn't use the trick Zig uses here), then the interrupt is allowed to close the IO resource as a way of ending the operation early. In practice this is usually fine, as you're interrupting the thread precisely because you want it to give up on whatever it's doing, but it precludes some particularly subtle possible IO designs.

  Not sure if this changes under virtual threads, where the thread is much more loosely coupled to the syscall.

  by twic