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.

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.

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?

This has not been my experience; Claude does a great job of writing unit tests for the Zig code, and combined with Zig's fuzzing features and a Python-based integration testing suite, I have avoided hitting runtime UB so far. In exchange, I get much faster compile times, which are important for the agentic development loop.

The question I ask myself is “would I write a game in Rust?” Zig seems like a better fit: you can be clever without being chided by the borrow checker. But as a “code artisan”, there’s an interesting challenge in making it work with Rust.

I might use Zig on a project if it was just me. I wouldn’t use it with the a team that I didn’t hand pick.

Smart people like Zig. Smart people like Rust. Smart people like LLMs. It’s a big Venn diagram. It be great if we could not bash each other.

In general, what helps is to instruct ai to use test coverage to ensure the cover all edge cases with tests.

> 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.

Not really seeing the connection here. What do you mean by code artisan? Are you trying to gatekeep Zig because you think Zig is too difficult for LLMs?

> Zig's value prop is different and closer to a modern C: it fits in your head and it maps fairly closely to assembly.

This can't be correct for the simple reason that it has both a modern optimizing compiler (LLVM) and UB.

A modern compiler will try to autovectorize your code, so you don't really know what the assembly will be.

UB gives compiler license to rewrite your code however it sees fit.

Like programming in a kind of super strict IL. Or the opposite : super poweful, super abstract language, yet extremely strict.

This to me reads like an LLMism.

Sure it wastes a bit of time always figure it out when it fails to compile.

This is why I’m excited to see qwen3.8 27b removed a bunch of knowledge for more reasoning. Baked in old zig api is worthless

---

Edit for replies complaining I used debug.print:

Okay, `try std.io.getStdOut().writer().print("Hello, world!\n", .{});`. Still one line, more explicit with chained methods, but that still just goes to show you how arbitrary this metric is -- Zig's standard library makes you be more explicit with one function, but it doesn't make you be as explicit with another one that works essentially the same way but writes to a different stream, ergo this has nothing to do with the language's inherent explicitness but rather comparing the implementation of a single random function.

Are you able to ship faster with Zig vs Rust? How did you arrive at the 4x figure?

I'm really puzzled why people are so angry over using ai assistance with Zig. LLMs are always going to be able to write better code faster and better than anyone who calls themselves code artisans in this day and age.

I think this comment posted a while back someone who worked on Zig is pretty telling:

> The key problem with Zig nowadays is how much of its community and adoption is driven by anti-Rust sentiment. As a result, while Rust puts beginner onboarding and documentation at the center of its culture, as opposed to the “C neckbeard”'s culture, Zig is going the other way around.

And ultimately this didn't stop people from using AI generating Zig code as much of the users in the thread are already using it to ship quality faster.

Happy to use the work the community outputs and culture is largely irrelevant when prompting LLMs outputs code that doesn't really require any intimate knowledge with the syntaxes

Do we even care about compilation time if we set it to work on a task and return some time later to see the result?

in general, I like zig syntax, but i find that it had very little regard to how the eye moves on the page. it’s jarring at times.

Zig has benefits, like comptime, no hidden control flow, memory mngmt, cross compilation etc. But its syntax is just a mouthfull of wats, whys and wtfs.

I can forsee a compile to Zig languge popping up sometime soon.