Zig vs Rust, agentic coding, and intellectual control

Ajouté : 2026-05-12

[00:00:00]Hey guys, it's your boy Zach.

[00:00:03]Um someone asked me in my last dev vlog about my use of LLMs.

[00:00:10]And I realized my view on that is directly related to um a lot of philosophical debates that have raged in the software world um including the very trendy comparison between Zig and Rust these days. So I'm going to there's actually a common thread here. I'm going to try to explain that.

[00:00:33]I'm outside by the way. It's a nice day, so I went to uh one of my favorite spots here.

[00:00:40]Right by the Ohio River.

[00:00:43]Um I'm going to move though cuz it's kind of like washed out with this shitty laptop camera.

[00:00:54]Um there we go.

[00:00:56]So yeah.

[00:00:58]This is a complicated topic.

[00:01:01]Normally I would insist on having a glass of whiskey.

[00:01:05]But it's too early in the day for that.

[00:01:07]So I have to settle for a cigarette.

[00:01:15]Um what I find compelling about this particularly Zig versus Rust is that it's clearly there's clearly this underlying philosophical disagreement. It's not just a shallow language war.

[00:01:31]It's actually a philosophical war that has been waged long before either of those languages existed.

[00:01:39]Um I mean one example is the Linux kernel mailing list had this exact same war going on. Only then it was C versus C++. Right?

[00:01:54]And I'll I'll try to link to an example of that, you know, one of my favorite rants from Linus.

[00:02:00]But he he you know, the C guys, they would always argue that um the most important thing in the long run for robust software was simplicity.

[00:02:13]Uh code simplicity and readability.

[00:02:16]Whereas the C++ guys they emphasized safety features from the compiler uh zero-cost abstractions as they refer to them.

[00:02:28]And um so that debate raged.

[00:02:33]In some sense, it was always hamstrung uh because even people who were believers in simplicity often gave up on using C after a while because uh it had too many foot guns.

[00:02:47]So what's what's really nice about Zig versus Rust is that we can see this play out more on a level playing field.

[00:02:56]Because these languages are both good modern languages. They have features that we come to expect like tagged unions, exhaustive switch statements, an actual error system.

[00:03:09]Things that uh we didn't have in C.

[00:03:13]But on a philosophical level, they are very much um just continuing the same battle that was waged back then between C and C++. What is more important?

[00:03:26]And and and I know you're going to say, "Well, both are important. I want readability and I want a safe compiler." Well, yes.

[00:03:34]We all want to have our cake and eat it, too.

[00:03:37]But sometimes these things are going to conflict.

[00:03:41]And which one are you going to prioritize when they are conflicting?

[00:03:45]That's what determines which side of this battle you're on.

[00:03:51]And uh uh it should be obvious what side I'm on.

[00:03:57]I spent my career writing Closure, now I'm writing Zig. I clearly am on the side of readability over safety or abstractions.

[00:04:07]I care about readability for the human reading the code more than anything else. I think that's ultimately in the long run what allows you to write robust software.

[00:04:19]I believe the problem with the languages that add all of these safety features is that the code becomes more complex.

[00:04:27]And when you have more complex code, you have a greater chance for logic bugs.

[00:04:32]So, you've made it uh less likely to get let's say memory bugs.

[00:04:38]But in exchange, you made the code more complex. And now you're probably going to have more logic bugs. Is that really a trade-off that you want to make?

[00:04:50]I'm going to If I If I remember to, I'll link to a article by George Fairbanks where he talks about two different ways you can get control of a code base, intellectual control and statistical control.

[00:05:06]It's the exact same distinction I've been making here, just phrased in a different way. Intellectual control is the control you get when you understand the code, when you can actually read it, understand it, run it in your head.

[00:05:22]Statistical control is the kind of control you get through automated means, like unit tests or your type system.

[00:05:30]Both of these are important, of course.

[00:05:33]But again, sometimes you can't have both. So, sometimes they conflict and you have to choose one or the other.

[00:05:41]And which one you choose, which one you lean more towards, is going to determine which side of this debate you fall on.

[00:05:47]Do you fall more so on the side of intellectual control, keeping the code simple and readable, or on the side of statistical control, getting more compile time guarantees, even if that means that the code itself becomes harder to read?

[00:06:08]So, in the uh C C++ debate, one of the flash points here was was destructors.

[00:06:15]Right? C++ has destructors and C does not.

[00:06:19]And uh you know, destructors are interesting because in you could argue in some sense they are a safety feature. They they prevent you from forgetting to run important cleanup code.

[00:06:34]But, if you take a typical C function, all of you know, calling a bunch of functions and then doing all of the cleanup directly, because there are no destructors in C.

[00:06:48]A C++ C++ guy will look at that and be like, "I know how to improve this."

[00:06:53]And he breaks the code out into into special types, and each type has its own destructor.

[00:06:58]And then the function uh it just instantiates those types, and this the destructors, of course, run automatically.

[00:07:07]And he's he's probably proud of himself like, "Oh, yeah, much better."

[00:07:12]But, is that better? I mean, the C function was it just a nice linear function that you could read, you could fit on one screen, and see everything.

[00:07:22]The C++ version, it it's uh it turned it into an Eldritch horror of abstraction.

[00:07:29]Maybe you're getting uh some nominal amount of extra safety, but is it is it really worth the trade-off to have code that reads like that, where where I mean, at the call site, you can't see the destructor at all. It's invisible.

[00:07:46]Um is this actually improving the code in the long run over the C version?

[00:07:52]It's the same debate.

[00:07:54]Just in a different way. Because the exact same thing can be seen when you compare Zig and Rust code. The Zig code will often have all of that directly in the function because there are no destructors in Zig.

[00:08:08]Whereas in Rust, everything is a trait.

[00:08:10]So, and that trait could be defined in a totally different file somewhere.

[00:08:15]Um and there's way more indirection in the code, which I would argue makes it much harder to read in the long run.

[00:08:29]So, um intellectual control and statistical control. That's really what the debate is. Which one do you lean more towards when they conflict?

[00:08:41]But, how does this relate to AI and agentic coding?

[00:08:45]Well, the argument goes that particularly if you're leaning heavily into it to the point where you're barely reviewing the output, who cares about readability?

[00:08:57]I've got my my nice little robot here who uh never gets tired and has infinite memory and can go through these horrible abstractions and understand it in seconds.

[00:09:11]Who cares about readability now? You may as well just use a language that goes entirely in the direction of statistical control like Rust instead of Zig. And this, of course, is what Bun is doing. They're rewriting their code from Zig to Rust entirely using Claude, apparently just in the past week.

[00:09:34]And uh the argument makes sense on the face of it. Like if you really are just diving headfirst into the deep end and you're not even reviewing the output of these LLMs, you may as well just use Rust or Haskell or something that gives you more guarantees.

[00:09:52]Readability doesn't matter if you're not reading it, right?

[00:09:56]>> [laughter] [snorts] >> Um maybe.

[00:10:00]But there is one flaw in this whole reasoning, and that is it is assuming that these LLMs will be able to keep up with all of the complexity that they themselves are producing.

[00:10:13]We all know if you if you use these uh um LLMs um like Claude or Codex, um they will typically produce over-engineered solutions that are much more complex than what an experienced programmer would write.

[00:10:32]I see this all the time. I uh you know, for for ZIT uh you know, I basically hand-coded all of it, but very recently I tried using Codex with GPT-5.5.

[00:10:48]And uh I just asked it to do a small refactor with the HTTP back end. Previously, it was hard-coded to output CGI format, so it can run as a CGI program.

[00:11:02]Um but I realized I I wanted to choose either CGI output or just direct HTTP output. Um and so I just asked it to do a quick refactor.

[00:11:15]And it decided to create a dynamic interface. That's not even a language feature in Zig, you have to build it um manually with a V-table and everything, and it did it. And I took one look at it was like uh no.

[00:11:30]>> [laughter] >> Like why would you make that a dynamic interface? There's only two possibilities, CGI or direct HTTP.

[00:11:37]Just make it a freaking enum.

[00:11:40]Or tagged union if it needs data along with it.

[00:11:44]Uh I don't need dynamism. I don't need to be able to create a new instance at run time.

[00:11:51]Totally over-engineered, totally more complicated than it needed to be.

[00:11:58]But here's the the thing people don't realize.

[00:12:01]When if you allow a complicated solution like that to get into your code base, every other uh change that you make to your code will also be more complex.

[00:12:14]Complexity compounds.

[00:12:16]So, if I allowed that to get into my code base, then any future change I made to that part of the code base would now be more complex as well because it has to contend with this grotesque dynamic interface that it created.

[00:12:31]And this is the problem is that complexity with with uh agentic coding, it doesn't increase linearly, it increases exponentially. Every time it creates an overly complex solution to a problem, all future changes that it makes will also be more complex.

[00:12:50]And the problem is you're assuming that it will always be able to handle the complexity that it creates.

[00:12:59]And I don't see the evidence for that at all.

[00:13:04]Um every technology plateaus at some point.

[00:13:08]It's I mean, you can't just assume it's it's just going to continuously increase its context window and continuously improve the models themselves and the fine-tuning.

[00:13:19]No, I mean, at at some point the amount of complexity that it creates will will so great that making any changes to the code base will be um extremely uh costly in time and produce new bugs constantly.

[00:13:39]That's the problem. That in essence is the problem with uh you know, going headfirst into vibe coding and allowing uh allowing it to make these sorts of changes without serious review.

[00:13:59]Um so I don't I don't actually think it's going to work out in the long run.

[00:14:06]I think readability still matters.

[00:14:09]Readability by a human being still matters and that is why I still use uh Zig and why I like small minimalist languages even today even though we've got these amazing tools that supposedly don't care about readability.

[00:14:30]Um it it still does matter if you want your code to actually stand the test of time in my opinion.

[00:14:40]At the same time uh even if you keep it on a short leash and you review the code carefully um it can still save you time.

[00:14:52]Like that refactor I mentioned it would have taken me several hours to do manually.

[00:14:58]Um instead I iterated on it with Codex and I I made sure to get rid of that dynamic interface and clean up the code.

[00:15:09]So I I definitely had to baby sit it, but it still saved me a [ __ ] load of time.

[00:15:14]So it's likely that I will use it more for Haxe. I've not been using it much in Haxe yet um because in the early stages of a project, I don't think it's helpful, you know, I'm I'm still trying to figure out the design. I'm still experimenting.

[00:15:29]So, I've mostly been coding manually.

[00:15:31]But, I'm probably going to start using it more later on for more of the grunt work.

[00:15:37]But, I'm going to keep it on a short leash, and I'm always going to review the code. And, I'm not going to give a [ __ ] about the fact that vibe coders are moving 100 times faster than me.

[00:15:47]They may be moving 100 times faster, but they're increasing complexity by 1,000 times.

[00:15:54]And, that will come back to bite them eventually.

[00:15:57]So, that's why I think this relates to the philosophical debate between Zig and Rust or the the distinction I made between intellectual control and statistical control.

[00:16:09]It's all the same stuff, just restated in different ways.

[00:16:13]Um, how do you write robust software in the long run?

[00:16:18]Um, you need to focus on readability and and simplicity of the code for a human being.

[00:16:30]And, uh, secondarily, try to get automated guarantees as well.

[00:16:37]But, when they conflict, most of the time you should lean towards intellectual control.

[00:16:43]You should lean towards simplicity and readability.

[00:16:47]Even in the world of AI agents, um, I think it is still important. Um, I believe they they will eventually um, produce code that even they themselves cannot maintain if you allow it to happen.

[00:17:09]I think that's my rant for today.

[00:17:14]But, uh, yeah.

[00:17:18]We'll We'll see if uh what I'm saying actually turns out to be true or if this turns out to be sort of like the swan song of a uh old-school programmer that uh that you know, looks outdated in retrospect. But, that's my overall view. This This This philosophical war is really about managing complexity and your views on complexity.

[00:17:46]And uh people who don't take it seriously are exactly the sort of people who are diving headfirst into agentic programming and uh they're about to learn a lesson that we all learned in other contexts long ago.

[00:18:05]And uh that is there is no free lunch and complexity will eventually um cause your project to buckle under its own weight as it has happened many times in the past long before LLMs, long before AI um agents came to the scene.

[00:18:32]Anyway, I hope that made sense.

[00:18:36]If not, then screw you.