> 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?
io_uring has been one of the greatest sources of exploits for the Linux kernel in years. io_uring has resulted in so many practical privilege escalation attacks that many containers completely block it, and companies like Google keep it entirely disabled. RHEL also ships a kernel without it by default.
Programming asynchronous code is hard. Execution is split up, you have extra state machine to handle, extra resources to manage that need to survive across async boundaries. And by asynchronous, I mean either callbacks or manually checked completions from some event system. Modern languages hide that under async/await, which is much better from DX perspective, but still leads to split in the ecosystem, and it's hard to optimize across async boundaries.
This is an example why Go is such a successful language, in my view. It hides the async complexity and allows you to pretend you have a simple continuous thread of execution. It's just cheaper than system threads. Imagine if operating system threads and the blocking syscalls were this efficient.
I've spent the last year building a similar runtime for Zig. Purely because I want my applications to forget they are using things like io_uring in the background.
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 ?
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 it 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.
> 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.
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.
Can LLMs not write Zig code ? I'm not really understanding your explanation for why we can write other languages with LLM but not Zig here.
> 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? Is this your personal opinion that you don't want to see people using LLMs with Zig because you have a special attachment to it?
You asked if there was "tangible benefit to end user or developer using ai assisted development". My answer is no, it has no benefits for this use case. Use Rust here, because its compiler acts as an AI safety net.
Being a code artisan is not gatekeeping. It means if you're used to being close to the metal and often know better than the compiler, Zig is for you. If you're not, use Rust (or Go).
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
The idea that humans can't solve a specific problem more efficiently than a generalised algorithm that has to work for all code ever written in the language is a lie that JS script kiddies tell themselves to justify remaining ignorant without feeling bad about it.
Oh, humans can definitely do that, in some capacity, if they're attentive, slept enough, aren't hungry, or in emotional distress, for a limited amount of time.
A generalised algorithm can do this consistently, billions of times, which happens to be the amount of problems involved in building an application.
Which is why we don't write entire programs in raw assembly, but that doesn't mean it's actually difficult to do better than a compiler. You focus your efforts on where benchmarking and profiling tell you your bottlenecks are in your hot paths. If you actually engage in this in a regular basis, you will recognise that despite the myth-building and fear around writing low-level code, compilers do "stupid" inefficient stuff all the time, and it's not hard to do better than them with the specific context of your project in mind.
Sometimes, but measure the number of people like that against the massive number of people who blow their whole leg off by trying to second-guess the compiler. If I had a nickel for every “performance critical” (which it never is) weird bullshit thing I’ve seen people do to to “defeat” (really: totally misunderstand) a compiler behavior that led to severe bugs, I’d have a lot of nickels. The overlap between those things truly being necessary and programmers being capable enough to implement them in general is narrow enough that I’m fine with most languages’ escape hatches being similarly narrow.
I mean, using Rust or Zig rather than typescript, go, Java or C# is often a premature optimization, depending on use case. Plenty of games where majority of code is C# or unrealscript. Most people I talk to are surprised that Java has monomorphisation at runtime.
This reads as rather dismissive and not so humble. Compilers generating suboptimal and sometimes broken code very slowly is the norm, not the exception. Whether or not it's worth worrying about is indeed a development tradeoff but not one that should be so casually dismissed.
> Being a code artisan is not gatekeeping. It means if you're used to being close to the metal and often know better than the compiler, Zig is for you. If you're not, use Rust.
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.
> 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.
Nobody's writing Zig because they think they can beat the Rust compiler.
Comparisons to Rust usually stop at memory safety and overlook what no-hidden-control-flow buys you when it's applied consistently across the whole language.
The same mechanism that lets you control allocation (passing an allocator) extends to I/O. For instance, writing Zig, I know exactly when I'm handing control to the kernel and when I'm not. In the vast majority of languages, it's something you'd observe at runtime, whereas in Zig, it's simply the source code you compiled.
So the point of writing Zig over any other language isn't beating the compiler, it's understanding and controlling what your program does at any given moment.
So far claude has been fine to generated zig code. Dont have lots of issues. Tijy local models have more problems with zig, need additional instructions.
In general, what helps is to instruct ai to use test coverage to ensure the cover all edge cases with tests.
> A modern compiler will try to autovectorize your code, so you don't really know what the assembly will be.
Looking at what the compiler actually did is an ancient tradition. I’ve even done it with Java. Seeing five virtual calls with bounds checking all over get turned into a single load instruction has to be seen to be believed.
it's also my opinion. Which makes me wonder : isn't there an opportunity to create a variant of rust that would make absolutely zero compromise on UB and safety at the detriment of user experience ( which we don't care about now, with AI generating the code) ?
Like programming in a kind of super strict IL. Or the opposite : super poweful, super abstract language, yet extremely strict.
LLMs are actually pretty good at finding potential memory corruption issues in unsafe langauges upfront, to a point where I wonder if it even still makes sense using Rust with its slow compile-edit-test loop in a fully automated code generation scenario.
Part of the reason the compile-edit-test loop is slower than in other languages is because Rust is doing a whole borrow checking phase other languages don't. I don't see why it'd be faster or more accurate to get an LLM to do the same static analysis as the Rust compiler. Although I'd be interested in an analysis of how much each would cost in dollars.
And the difference is more useful in the more common scenario of editing code and checking it. Though those days, language servers like rust-analyzer do essentially replace cargo check.
Taking the alacritty project and modifying the source files to pretend something happened:
I’ve shipped games written entirely in assembly. I now work on a large service you have heard of. I graduated manga cum laude. I’m not smart enough to write systems in C or Zig that don’t have bugs.
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. It be great if we could not bash each other.
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.
Rust is quite slow but that is an interesting benefit but still not sure what the trade offs are, Rust has a huge mature ecosystem and there are lot of jobs for it.
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.
> 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.
LLMs can't write better code faster than any reasonably competent human. They suck at writing code, and if you're outsourcing programming to them the software you produce will suck as well.
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.
The breaking changes version to version. Zig tends to be quite liberal about moving forward, as should be expected at its version level. It simply outpaces the llms datasets.
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.
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.
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
|capture| hides an inconsistency that bugs me – everywhere else, assignment to a variable flows leftwards. |capture| is an unnatural rightwards assignment.
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.
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)
With LLMs you pay per token, so if you can express the same code in 1 / 10th the tokens that absolutely matters. Moreover they have a finite context window, so more concise syntax can make that more economical.
Sure but how many devs can sustain that level of efficiency around the clock and how much thought do you think their employers will give when the LLM tokens pay 1/100~1/1000th of the wage paid
I want code that is efficient, secure and cheap to produce. There is no way a human can compete with a network of agents doing that. Whatever edge you think exists is on a downward trend. Look at where we were in the days of GPT 4o vs now in terms of coding capability. Look at the marketplace for overseas contractors and the impact AI has had.
To ship what I do now would've cost a few million dollars per year in terms of the team needed to maintain it now its 1000x cheaper
I'm not making that argument are you responding to the right person?
My argument was that syntax still matters because LLMs communicate in syntax, and they pay for that per token. I'm not arguing that humans can compete with a network of agents.
Some people are actually interested in programming, coming and bleating about LLMs making all the finer points of it unimportant is as clueless as a manager coming here and telling us that syntax is unimportant because he has programmers for that crap.
If you don't care, don't go around in programming threads telling you how it doesn't matter anymore. It doesn't matter to you, because you prefer to be ignorant about the details of programming, and you have found tools that let you live in ignorance, good for you. But some of us do care, and are going to continue to do so.
My point isn't that what you are doing is pointless or that you shouldn't enjoy what you do but that it ultimately holds very little economic value especially as someone in charge of hiring developers, their experience is more valuable in the sphere of architectural design than expertise over syntax.
LLMs compile english to whatever code you want and it can write it better, faster and more efficiently than a human can over the long run. You might have an edge in shorter sprints but that gap is quickly reduced when LLMs simply learn and apply whatever optimization they find and it can continue to output without any diminishing returns and at fraction of what it takes to pay a human to do it.
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
Ofc it boils down to familiarity. But making a custom version of, say structs is just a weird design. The mainstream struct syntax is something everyone knows, and zig made all kinds of weird decisions around it. Same goes for @SpecialThing, looks like PHP to me. Multiline strings are also a weird addition. The list goes on.
> But making a custom version of, say structs is just a weird design.
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'.
> in Clang/GCC the `__` is not explicitly reserved for builtins
In fact in C identifiers starting with _ are reserved for the implementation (except for in local scope if the second character is not an underscore or capital letter).
I'm not really against such special symbols, only if they are too much, like in Perl.
~ and @ weren't replaced by anything with ::, though, ~Foo is Box<Foo> and @Foo is Rc<Foo> (or is it Arc<Foo>?). :: to access a member of a module already existed when ~ and @ was in Rust.
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.
Who's right though? The article seems to go directly against what parent said above?
> 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" :)
The article seems to talk about how `Thread.interrupt` works with synchronous IO, rather than the async IO machinery of `java.nio`. So I'd say the article is inaccurate or at least incomplete.
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.
I think that specific issue was a huge mistake, because it means the interruption, which was already messy, is now unusable.
First, you can get deadlocks as interrupt now calls arbitrary code to close channels. Second the interruptee thread cannot recover from an interrupt, if it chooses to to. Lastly it means that a server that shares a file descriptor with multiple threads breaks unrelated operations on interruption.
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.
Run with the options to dump optimized code to a file. Look at what it’s actually generating for all the byte buffer calls and you’ll see it’s piss-takingly fast. Looking at the Java it shows up as five virtual calls and a bunch of bounds checks. The JIT will turn that into a single x86 instruction in most cases.
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.
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?
You don’t have to do any significant work within the signal handler itself. In fact, the signal handler can literally be empty. What matters is that as long as SA_RESTART is not set, after the signal handler runs, the interrupted syscall fails with errno set to EINTR. Then the code that did the syscall can check whether a cancellation occurred (and retry the syscall if not).
Disclaimer: I haven’t looked at Zig’s implementation; I’m only going off how the Unix APIs work.
93 comments
[ 0.21 ms ] story [ 54.4 ms ] threadThere'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?
io_uring has been one of the greatest sources of exploits for the Linux kernel in years. io_uring has resulted in so many practical privilege escalation attacks that many containers completely block it, and companies like Google keep it entirely disabled. RHEL also ships a kernel without it by default.
This is an example why Go is such a successful language, in my view. It hides the async complexity and allows you to pretend you have a simple continuous thread of execution. It's just cheaper than system threads. Imagine if operating system threads and the blocking syscalls were this efficient.
I've spent the last year building a similar runtime for Zig. Purely because I want my applications to forget they are using things like io_uring in the background.
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 it 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 to me reads like an LLMism.
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.
> 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? Is this your personal opinion that you don't want to see people using LLMs with Zig because you have a special attachment to it?
Being a code artisan is not gatekeeping. It means if you're used to being close to the metal and often know better than the compiler, Zig is for you. If you're not, use Rust (or Go).
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.
Of course I’d rather be writing the engine. =)
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.
> 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.
Comparisons to Rust usually stop at memory safety and overlook what no-hidden-control-flow buys you when it's applied consistently across the whole language.
The same mechanism that lets you control allocation (passing an allocator) extends to I/O. For instance, writing Zig, I know exactly when I'm handing control to the kernel and when I'm not. In the vast majority of languages, it's something you'd observe at runtime, whereas in Zig, it's simply the source code you compiled.
So the point of writing Zig over any other language isn't beating the compiler, it's understanding and controlling what your program does at any given moment.
In general, what helps is to instruct ai to use test coverage to ensure the cover all edge cases with tests.
> 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.
Looking at what the compiler actually did is an ancient tradition. I’ve even done it with Java. Seeing five virtual calls with bounds checking all over get turned into a single load instruction has to be seen to be believed.
Like programming in a kind of super strict IL. Or the opposite : super poweful, super abstract language, yet extremely strict.
Taking the alacritty project and modifying the source files to pretend something happened:
I wish it was faster, but I will take the speedup that I can!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. It be great if we could not bash each other.
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.
LLMs can't write better code faster than any reasonably competent human. They suck at writing code, and if you're outsourcing programming to them the software you produce will suck as well.
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?
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.
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
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)
resultA : resultB ? (evaluation)
if we always put result first?
I think the most important piece of if statements and ternaries is the condition being evaluated and it's worth putting that first?
and ternary is a branch with no variable introduction, so it doesn’t apply again.
To ship what I do now would've cost a few million dollars per year in terms of the team needed to maintain it now its 1000x cheaper
My argument was that syntax still matters because LLMs communicate in syntax, and they pay for that per token. I'm not arguing that humans can compete with a network of agents.
If you don't care, don't go around in programming threads telling you how it doesn't matter anymore. It doesn't matter to you, because you prefer to be ignorant about the details of programming, and you have found tools that let you live in ignorance, good for you. But some of us do care, and are going to continue to do so.
LLMs compile english to whatever code you want and it can write it better, faster and more efficiently than a human can over the long run. You might have an edge in shorter sprints but that gap is quickly reduced when LLMs simply learn and apply whatever optimization they find and it can continue to output without any diminishing returns and at fraction of what it takes to pay a human to do it.
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'.
In fact in C identifiers starting with _ are reserved for the implementation (except for in local scope if the second character is not an underscore or capital letter).
~ and @ weren't replaced by anything with ::, though, ~Foo is Box<Foo> and @Foo is Rc<Foo> (or is it Arc<Foo>?). :: to access a member of a module already existed when ~ and @ was in Rust.
Great that Zig is supporting this more “first class”; not strictly required, but looks useful.
You can interrupt a blocking IO operation with either interrupt() or close().
https://docs.oracle.com/en/java/javase/25/docs/api/java.base...
> 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...
The article just references Thread.interrupt
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.
First, you can get deadlocks as interrupt now calls arbitrary code to close channels. Second the interruptee thread cannot recover from an interrupt, if it chooses to to. Lastly it means that a server that shares a file descriptor with multiple threads breaks unrelated operations on interruption.
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.
Disclaimer: I haven’t looked at Zig’s implementation; I’m only going off how the Unix APIs work.