You can interrupt a blocking IO operation with either interrupt() or close().
https://docs.oracle.com/en/java/javase/25/docs/api/java.base...
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.
> In Java, there’s a similarly looking thread interruption mechanism. Critically, it doesn’t support interrupting syscalls: IOException and InterruptedException are both checked and unrelated, meaning that IOing functions are not interruptible
One says IOing functions are not interruptible, other says "You can interrupt a blocking IO operation" :)
https://docs.oracle.com/en/java/javase/25/docs/api/java.base...
Great that Zig is supporting this more “first class”; not strictly required, but looks useful.
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.
if (evaluation) result = evaluation
if (evaluation) |result|
Although assignments as expressions in C are convenient, I don't think they make a ton of sense and find Zig's capture easier to read (easier to immediately see what's being evaluated)
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.
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
This I don't understand? Zig structs are pretty much the same as in any other language, except that the declaration can be more flexible by building the struct type via comptime code (e.g. how Zig does generics) - and Zig groups structs and namespaces under the same keyword (which hardly matters in practice though).
> @SpecialThing
...not any weirder than `__builtin` keywords in Clang or GCC and at least in Zig it's obvious that anything starting with a `@` is a builtin, while in Clang/GCC the `__` is not explicitly reserved for builtins. ObjC also uses a leading `@` to separate ObjC keywords from regular C keywords. Agreed that the @-noise can get a bit excessive in Zig though (mainly because implicit casting is heavily restricted, at least compared to C).
> Multiline strings are also a weird addition
AFAIK the 'weird' multiline syntax is for keeping the parser simple and fast. Multi-line-strings themselves are a good feature to have though.
In general, if Zig code starts to look too 'noisy', that's usually a sign that the code should be simplified.
I definitely don't agree with all design decisions in Zig, but the syntax is mostly fine (my main critique points are that Zig often tries to lean too much into 'design purity' than 'programmer convenience' and that parts of the stdlib are too 'object oriented'.
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.
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.
In general, what helps is to instruct ai to use test coverage to ensure the cover all edge cases with tests.
Like programming in a kind of super strict IL. Or the opposite : super poweful, super abstract language, yet extremely strict.
> 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.
> 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?
Being a code artisan is not gatekeeping. It means if you're used to being close to the metal and sometimes know better than the compiler, Zig is for you. If you're not, use Rust.
With all due respect, that tickles my spidey senses. People claiming to know better than a compiler about low-level details of their code are most often either engaging in premature hyper-optimisation, or suffer a specific kind of greybeard hubris IMHO
A generalised algorithm can do this consistently, billions of times, which happens to be the amount of problems involved in building an application.
You are saying that if you are not a code artisan (who by definition can't use LLM) likeyou then they should not use Zig. Honestly, I don't care. I'm not a code artisan, if Zig can help me ship faster and better with LLMs, my job is done and that's what I get paid for.
> 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.
So there is a benefit here mentioned by the non-arisans which is what I wanted to know but you wouldn't know if you don't use ai assisted delivery.
This to me reads like an LLMism.
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.
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
---
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.
small typo fix:
instead of `std.io`, it should be `init.io`. `init` is first parameter in `main` function.
In Zig, you create a buffered writer for the stdout file handle, write hello world to the buffer, and then flush it. It exposes what's actually happening underneath.