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.
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.
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. Smart people like LLMs. It’s a big Venn diagram. It be great if we could not bash each other.
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.
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? Are you trying to gatekeep Zig because you think Zig is too difficult for LLMs?
You asked if there was "tangible benefit to end user or developer using ai assisted development". My answer is no, it can be done but 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 sometimes know better than the compiler, Zig is for you. If you're not, use Rust.
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.
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.
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 “defeat” (really: totally misunderstand) a compiler behavior, which instead resulted in severe bugs, I’d have a lot of nickels.
The overlap of situations where compiler-second-guessing truly being necessary and the programmers present are capable enough to implement it 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.
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.
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. 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.
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.
Comments
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.
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.
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.
It's the compilation that is slow, not the checking. You can observe this by comparing "cargo check" and "cargo build".
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 wish it was faster, but I will take the speedup that I can!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. Smart people like LLMs. It’s a big Venn diagram. It be great if we could not bash each other.
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.
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.
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?
You asked if there was "tangible benefit to end user or developer using ai assisted development". My answer is no, it can be done but 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 sometimes know better than the compiler, Zig is for you. If you're not, use Rust.
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.
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.
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 “defeat” (really: totally misunderstand) a compiler behavior, which instead resulted in severe bugs, I’d have a lot of nickels.
The overlap of situations where compiler-second-guessing truly being necessary and the programmers present are capable enough to implement it 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.
Of course I’d rather be writing the engine. =)
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.
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.
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.
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.
Use Rust if you want to write in a memory safe, high performance language.
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.
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.
This to me reads like an LLMism.