Эндрю Келли, создатель языка Zig

[vak]

Целиком интервью можно посмотреть на Ютубе. Вот текст первой части. Остальные семь частей добавлю в комменты.

Part 1: Why Build Zig & Overcoming Technical Friction

[00:00]

What made you build Zig? I can do better. I can do better than C++, I can do better than Rust, I can do better than Go, I can do better than JavaScript. Strict no LLM, no AI policy, why? Invariably garbage. $100 million, would you take it? I'm sorry, but we will not do what you say, and if you take your money away, we will survive. You moved Zig's main repository from GitHub to Codeberg. GitHub simply stopped working for us. We moved to Codeberg and now our continuous integration server works again. When we tag 1.0, it will be like a true uncompromising labor of love. We will not have to be stuck with any like bad decisions. What's blocking it? Um, well, ultimately...

Andrew Kelley, we already have C, C++, Rust, Go. What made you build Zig anyway? Well, it's funny that you listed those languages specifically because that is exactly the set of programming languages that I first tried to use to build a digital audio workstation just before I pivoted to working on Zig. And when I tried to work on this project with each different language, I ran into a different set of problems that I found insurmountable. And at the end of this process, I concluded that no, it's not me that is having a skill issue, it's the programming language that's the problem. And so from there, that's where I developed the hubris of making a new programming language.

Comment: Andrew Kelley, creator of the Zig programming language, quit his tech job in 2018 to build Zig full-time. He runs the Zig Software Foundation on $670,000 a year and enforces a strict ban on AI contributions.

What problems exactly? The first thing that I tried to do was make the digital audio workstation in the browser using JavaScript, and what I quickly realized is that this is too high level. I don't have access to the computer's capabilities that will allow me to make a compelling user experience in this digital audio workstation. So I threw that out the window and I went to native programming language compilation.

The next thing I tried to do is Go. What I ran into with Go is, number one, trying to interact with libraries like for creating a window or making buttons or something like this using existing C code does not work very well with Go. And then I also ran into the garbage collector problem. So, of course, if you're trying to do audio, you have a real-time deadline. If you can't process the audio in exactly this amount of time, you get a glitch or a skip, and it's completely unacceptable for live performance software like a digital audio workstation.

So then I got rid of Go. Now I tried to use Rust, and this was before Rust 1.0. But what happened is that I really struggled to write code that would satisfy Rust's rules. Once I did satisfy them, I found that even trying to make little changes would cause a cascade of compile errors that would prevent me from making more progress. I remember just feeling very frustrated that I spent a whole month trying to get font rendering to work, and then felt stuck like I couldn't even make more progress after that point. So I gave up on Rust and I switched to C++.

Then I felt more productive at first. But what happened very quickly is that just a little typo here, a little mistake there, would result in a memory corruption bug that would cost me weeks in order to debug. This is just too slow. I can't create a project with this magnitude of difficulty when these little mistakes are costing me weeks and weeks over and over again. After that, I tried C++ but C-style. I would compile with the C++ compiler, but I would link with the C linker, and that would give me an error if I tried to use fancy C++ features. That limited me to only templates and a few other things, but even then, it was the same problem. It's just too easy to shoot yourself in the foot with C++. For me, that was when I said: "I can do better. I can do better than C++, I can do better than Rust, I can do better than Go, I can do better than JavaScript, I can do better than D." That was my hubris.

Comments

Part 2: Applications, Adoption, and the Road to 1.0

[vak]

[04:52]
Now Zig, what is Zig used for? What problems does it solve? Zig is used when you want to have full control over the computer. You don't want to leave any performance on the table. You want to have the best possible performance and the best possible memory usage, and ultimately, you want to craft a compelling user experience. That's the most important thing. Just before starting Zig, I adopted a new philosophy for myself to not compromise on the user experience. I would never say, "Oh, because I'm using Go or because I'm using JavaScript, I have this limitation in the software." I would say no, that's not acceptable. I will change my toolchain if I have to in order to make the computer deliver the best experience for the user. For me at the time, that was a different way of thinking about programming. It's not "what can I do with my toolchain?", it's "what can the computer fundamentally do, and how can I get it to do this using any possible toolchain, maybe even one that I would make?"

Let's talk about applications. Where is Zig used today? One application that comes to mind would be Ghostty. This is a terminal emulator created by Mitchell Hashimoto. This is a really nice project written in Zig because the code is very high quality. Mitchell does a really good job managing the community, fuzz testing, and making sure that it's good quality.

There's also TigerBeetle. TigerBeetle is a financial transaction database that's written in Zig. They batch operations together to achieve a level of efficiency that is not common in that space because other solutions are trying to use PostgreSQL or some kind of relational database and building the OLTP on top of it. They have built a special purpose database that's a thousand times faster than that kind of strategy. That project is really focused on pre-allocating resources and then never failing after that point. When that database runs, it will pre-allocate all the memory you will ever use, and then from that time, it will never dynamically allocate anything ever again. That keeps their latencies very predictable and very consistent. That's a good example of where using Zig was a nice choice because Zig offers you the choice between optimizing for low latency, predictable latency, and what I would call the opposite of that, which would be garbage collection high throughput.

What about Bun? Bun is a JavaScript engine that uses JavaScriptCore and a bunch of other C++ libraries, and then all the glue code is written in Zig. That project was recently sold to Anthropic, I think, and we've seen a lot of people consequently getting into using Zig for AI.

I also heard that Uber is using Zig? Yes, Uber is using the toolchain. Uber uses `zig cc` to build some of their things to cross-compile for ARM64, and specifically, they're using it with Go. They have a bunch of Go code, and the problem is that when you try to cross-compile Go code, that part works. But when you try to cross-compile Go code with C code in it, that does not work with Go out of the box. You can actually just use Zig as the C compiler along with Go, and then you have cross-compilation also for the C code that the Go code depends on.

By the way, why is it called Zig? I wanted a short word that had zero Google results for a programming language, and that was true at the time. When I named it, if you searched for "zig programming language," there were zero results. I made a little Python script that just printed some random words, and Zig jumped out at me, so I picked it. Why do you have the iguana as a mascot? It's a Ziguana. Zigguana.

Amazing. Well, Andrew, Zig is in the top five most admired programming languages, but there is no 1.0 release after 10 years. What's blocking it? Well, ultimately, 1.0 can mean different things for different projects. If we look at Go, they tagged 1.0 and they did not touch the language for a very long time. Rust tagged 1.0 pretty early, but they have this feature called editions, so even though they maintain the backwards compatibility guarantees with 1.0, they still can change the language quite a bit. Writing modern Rust is still different than writing 1.0 Rust at the time. Really, what is 1.0? It's a backwards compatibility promise, right?

The other thing I would say about that is the Zig Software Foundation is not a startup. We don't have any investment money; we don't have investors breathing down our necks. We're a 501(c)(3) nonprofit. We don't have to crash and burn, you know? We don't have to sell; we don't have an exit plan. Our plan is to make a great project and keep improving it over a long period of time. We have the time to make steady improvements. We're a very lean, very efficient, small organization. We don't burn through a lot of capital very fast, and so we're here to stay. We will keep improving Zig until we get there, and we don't have to do it prematurely. When we tag 1.0, it will be a true, uncompromising labor of love. We will not have to be stuck with any bad decisions that we had to rush to lock in.

I'll continue asking about that. There is a concept in software development called "worse is better"—like ship fast, fix later. PHP and Go did that and they became huge. You choose the opposite, why? This "worse is better" is a pet peeve of mine because linguistically it makes no sense. I think it's better to say doing less with less versus doing more with more. I think Zig is a third option: we're trying to do more with less. We still want to offer great things, but we want to find that sweet spot where a little bit can go a long way. You can find this reflected in the language with, for example, the ratio of a small amount of complexity of the `comptime` feature to the high amount of utility that you get from it. You can find that reflected in the toolchain where just one flag can tell the compiler to target a wildly different operating system and architecture, and it will just work.

Do you think missing 1.0 hurts user or company adoption? There is no doubt that when we tag 1.0, we will see a sharp rise in adoption. That's certain. But for me, I have my eyes on the long-term future. I want to make Zig a language for the next 50 years, and I think we will start to see those choices pay off in this upcoming 0.16 release. Can you share a deadline for that? Well, how about this: we can make this a race. You race to try to get this video uploaded, and I will race to try to tag 0.16, and we'll see who wins.

Re: Part 2: Applications, Adoption, and the Road to 1.0

[juan_gandhi]

This is heart-warming, really.

Part 3: The Zig Software Foundation & Leaving GitHub

[vak]

[13:02]
To develop the language, you founded the Zig Software Foundation, and in 2024 its total income was $670,000. Who are your main sponsors? If you look at the blog post where I presume you got this information from, there's a nice pie chart that shows the different parties that our income comes from. I'm really proud of how diverse that chart is. A lot of our sponsors are individual donors, and apart from that, we have a nice, healthy variety of different companies that we get donations from. We don't have any single entity that can say, "Hey, you need to do this or this." We could turn to any individual sponsor and say, "I'm sorry, but we will not do what you say, and if you take your money away, we will survive." It's a very mutually beneficial relationship, but with healthy boundaries between the business organizations.

Can some of your sponsors influence how you develop Zig? Well, they can influence it in the same way that anyone can influence it. They can participate on the bug tracker, send pull requests, chat in the development channels. Ultimately, it's humans talking with humans. They don't have a secret, high-priority channel. Everyone's on equal footing here.

Your salary is $154,000 per year, which is comparable to a senior engineer, but you are building the entire language ecosystem. How do you decide on your own salary? This was decided by the Zig Software Foundation board when we had our first board meeting. This was the median senior software engineer salary in New York City at the time, which is where the nonprofit was formed. It seems like in your question, you're implying that maybe I deserve more money, which—thank you for the implication—but honestly, I feel upper-middle-class. I feel like I get a lot of money. I can afford groceries easily, and I can afford the mortgage for a house in Portland, Oregon, where I live. So I'm comfy, you know? I don't need more.

To me, the autonomy of having a lean nonprofit that is sturdy and can withstand a chaotic financial environment is more valuable than having some more spending money. This is what allows us to say, "No, not yet, we need a little more time for 1.0." This is what allowed us to raise the rates for our contractors in a year where everyone else was having massive tech layoffs, and I'm proud of that. I think that what we have is a healthy organization, and that benefit fills me with a satisfaction that having more income would not provide.

If a large company offers Zig say $100 million with no conditions, would you take it? $100 million... to put this in perspective, our yearly annual revenue has been less than $1 million every year, though maybe starting to approach it this year. There are two limitations here to this money. The first thing is the sustainability of the nonprofit. What I would not want to do is take that money and then spend a significant fraction of it so that I would need to get more of that amount of money in the future. That would be a problem because instead of a surprise gift, now we have an obligation to try to get it again.

The second limitation would be team size. I'm managing a team of five. I don't think I have the skills to manage a team of much more than that, nor do i have the motivation to do it. I would certainly not take this money and then just grow and become a manager of 100 people or something like this. But you know what I could do? If it's $100 million, I could take that money, put it into the bank, and then never have to fundraise for 100 years. So sure, I'll take the money, but not grow. You see what I mean? Because I think what the question is fundamentally asking is, "Would you grow if you had the opportunity?" And I think the answer is a little bit—I think we could have more than five people, but I think maybe more than 10 would be pushing it for me.

A team of five, your salary—is that where all the money from the foundation goes? The foundation has one employee, which is me, and then five contractors. We have other contractors who are not active, but about five who are paid full-time. I believe the number was 91% of that money last year went to paying contractors to work on the project. The vast majority of the income that we get from donations is going directly towards paying contractors for work on the Zig project.

Being this open with the money, is it because of some obligations that a nonprofit has, or is it something important to you as well? There are some obligations that nonprofits have. This is a United States 501(c)(3) nonprofit, and I'll take this moment to point out that it's different than a 501(c)(6). A 501(c)(6) is a business league; that's what the Rust Foundation is. Amazon, Netflix, Microsoft, Meta—they all have a shared interest in the Rust project succeeding, so they all donate to this 501(c)(6) so that it can help them lobby the government and do all these things. A 501(c)(3) is not allowed to lobby the government, and we don't have other businesses that are in control. It is serving the mission statement alone; that is the purpose of the 501(c)(3). The blog post where we break down this income and these expenses and share more of these details, that's voluntary transparency. But that also acts as marketing for us because we do well on these metrics. It helps people have confidence that we're doing a good job, and it serves as an opportunity to fundraise as well.

In 2022, you left Reddit and Twitter. Why? I think that posting on these websites is becoming a lot like posting on Slashdot or Digg; they're just becoming kind of irrelevant. We're software engineers; we want to do as little marketing as possible, and so these things just aren't giving us returns on our investments anymore. We're starting to do more in-person events like Zig-Zag Days, as opposed to social media where you interact with trolls or the algorithm controls what gets seen. This is what we're currently thinking is a better investment of our focus to grow the community.

Then in late 2025, you took another step: you moved Zig's main repository from GitHub to Codeberg. GitHub simply stopped working for us. We would not have results for our continuous integration runs anymore; it just would stop working. So we moved to Codeberg and now our continuous integration server works again. But you had sponsors on GitHub. Did they follow you to the new platform? That was a tough choice to leave those behind because anytime that funding is concerned, it's a bit spooky to potentially take a risk and lose a source of income. But ultimately, we're here to write software, and if our continuous integration server doesn't work, we need to find one that does. So that was the highest priority. Did the foundation lose some money? We're doing completely fine on that front. We're creating software with the MIT license. This is a no-strings-attached donation, if you will, to the world of software, and people who donate money to us likewise are making no-strings-attached donations. Under this relationship, I've found that there is a high amount of respect for the other party. If someone stops donating, I don't say, "Hey you jerk, why did you do that?" No, of course not. It's no strings attached, right? And when we make these choices to move off GitHub or do this or that, I find that people are very understanding and very gracious.

By the way, why Codeberg specifically? Not GitLab, not hosting your own server? Codeberg is essentially a clone of GitHub, so it was an easy transition to make. Codeberg is also a German nonprofit, and personally, I find using nonprofits to be more stable businesses than startups or corporations. These corporations are always chasing the next thing and trying to make the next quarter more profitable, while the nonprofits are just trying to keep doing what they're doing. That stability is what I want for a code forge, so that was why I picked Codeberg.

Leaving social media, leaving GitHub—it all sparked huge discussions and huge debates in the community. Many say that this will stop Zig's growth, maybe turn Zig into a niche language. What do you personally think about that? I think that the code forge is not really a marketing arm of the project. I don't think that people are discovering Zig through GitHub or Codeberg. I think they're discovering it through, like we were talking earlier, talks, meetups, stuff like this YouTube video that we're making right now, Zig Day meetup groups. These are places that people find out about a language. Whether we use Git or Mercurial, or where the bug tracker is—I mean, they affect how convenient it is to work on the language, but that's not marketing. So I think that this idea that it's some kind of crisis of popularity, I don't understand the reasoning behind this at all, really.

Part 4: Moving Away From LLVM and the Strict Anti-AI Policy

[vak]

[24:20]
Let's talk about some things around Zig that have sparked a lot of discussion. You moved away from LLVM. Why? I play a 10-player competitive arcade game called Killer Queen, and it's quite fun. But the developers made the choice to use Unity for their physics engine, and the problem is that the physics engine is extremely load-bearing for competitive play. Even tiny little changes to it will make competitive players feel completely different and reset their skills. These developers can't even update to the new Unity version because even the bugs fixed in the physics engine will cause an uproar in the community of people who play this game. They made the mistake of using a dependency for their core product, and I think that's a key insight: you want to avoid a dependency for your core product.

We have done this with LLVM with Zig, and so we're in the process of rectifying this mistake. I think of it like training wheels on a bicycle. I've been working on Zig for over 10 years now, and I know more about compiler development than I did 10 years ago, so I can take the training wheels off and we can compete with LLVM at this point. By owning our core product and not having a dependency, this has enabled us to unlock things that we could not do before. For example, when you're using our own x86 backend, we now have incremental compilation that brings even massive, million-line codebases down to 50 milliseconds or less for changes. You make a change to your code, and you have a new binary already updated in 50 milliseconds on a million-line codebase. This is simply not possible with LLVM, but this is something that we can do now with our own code.

Zig has a strict no LLM, no AI policy for issues and for pull requests. Why? The first reason is just that those kinds of contributions are invariably garbage. People are sending us contributions that have no value whatsoever. Not only that, they have negative value because they take review time away from the team, which is very limited. We have over 200 pull requests sitting open right now, and those are all waiting for review. We try to be on top of it as much as possible, but when you have a small number of people on the dev team and you have a large number of contributors, this is always the problem: this bottleneck of review time. When we get these slop contributions, they take our review time. After a few reviews, we realize they have no clue what they're doing; they're just pasting what we say back to the chat and then laundering the chat back to pretend that they're not using chat, but we can still tell. At some point, we realize this is never going to be good quality because they have no idea what they're doing. So now we've wasted everybody's time. All those other people who are waiting patiently didn't get a review, and the code never gets merged. It's worthless.

We like to call it contributor poker. The main point of doing code reviews and having contributions instead of just doing all the work ourselves is mentorship. The whole point is that a contributor can become a core team member eventually, or they can become a more valuable contributor, and this will help the project because we'll have more people who can contribute to Zig skillfully. It will help their resume because they can be a better systems programmer and they can take those skills elsewhere. The idea of contributor poker is that we have limited time, so we want to notice: okay, who can we invest our time in to help them become better programmers and better contributors for the project? And who is maybe a drive-by contributor—they're going to send something, they're going to go away, so it's less valuable to invest in them. People who are using AI are always in the second category. It's not worth it to invest in them; they're not learning anything, and they're not going to join the core team later. Not a chance.

For us, this policy just makes sense because the Zig project is also an education project. That's part of our mission statement: we're providing guidance and education to students. We're all trying to learn; we're all trying to get better at programming, and so people who are sending AI pull requests, those people are not helping this goal, and in fact, i think that they're detracting from this goal. For our project, I think that the strict no AI policy is an appropriate policy. If I tried to say, "Oh, only good AI PRs can come in," now I have to be the judge of that, whereas if it's none whatsoever, then it's a very easy policy to enforce.

By the way, how do you detect AI-generated content? Is it easy? It's not always easy. I'm sure that some have gotten through, some have gotten in. Lately, I think they've been laundering the LLM text—they don't copy-paste it directly because that's way too obvious, so they try to rewrite it in their own voice or they say "try to sound human" or something like this. I've reviewed so many pull requests, you know, so at some point, I realize this is not what a human does when presented with this feedback, and then it becomes obvious. But it's pretty relentless lately, so I think we might need to have a different strategy than the current policy which allows anyone to contribute. I think we might need a stronger filter for getting in and getting the permission to send a contribution, unfortunately.

The Zig codebase uses the MIT license, so what's that? It's very close to public domain. For people unfamiliar with software licenses, it's effectively public domain. Can you give an example of how it can be used? It can be used almost for anything. The only restriction that the MIT license makes is that you have to reproduce the license if you are copying the code, and you can't hold us accountable for problems—no warranty, basically. This means anyone, including big companies, can use your code to train AI, but at the same time, you ban AI from contributing to Zig. How do you feel about this contradiction? It's ironic, isn't it? Personally, I have no issue with this. I really firmly believe in the no-strings-attached gift that Zig is to the world. If someone wants to use Zig for AI training, great, I don't care. That's fine. The fact that these companies are doing things that I don't like—I don't like that they're doing it, but it doesn't bother me that they're using Zig. I think that the more that Zig is being used, it just shows that Zig is valuable. That's the way I see it.

Is it true that LLMs struggle with Zig code compared to Python or JavaScript? I haven't tried it much myself, but my understanding is that it's actually just fine. I know that Mitchell Hashimoto uses AI coding extensively for Zig with Ghostty. Another person I know, his screen name is Rocker, he made a tool that makes AI work better for Zig, and he's having success; he's reporting success with Zig. I've seen some people say it doesn't work well; I've seen some people say it works perfectly fine.

I recently read your Mastodon post: "AI coding blogs are a snoozefest, like reading restaurant reviews instead of watching the chef cook." What do you mean, and what's your opinion on vibe coding? I love computers, and I love learning about what people are doing with them. There's a sense of mystery and magic that you can get from reading someone's explanation of a project that they did that took them a very long time, where they had to learn lessons and increase their skill as a programmer and as a user of computers in order to accomplish this goal. When you read a blog post like this, it's brilliant. It captures the imagination, it makes you think about what you could do yourself, it teaches you something, it connects you to them emotionally.

But on the other hand, we're seeing people say, "Oh, I tried this version of Claude or that version of OpenAI and sometimes it works surprisingly well." I'm always hearing people say that AI code works surprisingly well, but to me, this is not the bar that I want to hold software to. The bar that I want to hold software to is uncompromising perfection. I don't want to be surprised by the absence of a bug. That's a horrible quality bar to believe in. So I mean, it's just so many people saying, "I don't know, I tried coding this app and it kind of works." Okay, you know... it's just so uninspiring.

Have you tried AI coding yourself? I did a private call with Richard Feldman, a friend of mine, and he showed me how to use vibe coding with Zed. I tried it out, and I think that the technology is fundamentally interesting. What really turns me off is the fact that it's centrally controlled by, I don't know, four companies, and they have total control over what it's doing. They have total control over the models. I'm not going to go from using my own computer and my own electricity to do my code in order to use closed-source programming on someone else's computer through the network that I have to pay for monthly. Some people are paying $300 a month for this. To me, this is an insane proposition. I would never want to give up what I have in order to get the results of generative AI.

In general, how do you feel about the future of programming? In 10 or 20 years, will humans still write code? People will never stop writing code because writing code is really fun. It will always be, at the very least, a hobby. I will say, on my phone and on my computer, the apps that I use—the very best ones are the ones that were made by people in their free time for a hobby. The ones that are made by companies that I have to use because of whatever reason, I feel like I have a hostile relationship with these apps. They're always trying to get me to buy stuff, or advertise to me, or coerce me into doing some kind of engagement metric that they've decided they care about. But whenever I use an app that was made by someone as a hobby, it respects me. It treats me as the boss of the computer, and that's the relationship I want to have with my software. That will never go away. People will always want to make software for a hobby, people will always want to make free and open-source software, and people will always want to have a relationship with their devices where they're the boss. That will never go away, no matter how much these companies try to become the bosses of our own hardware.

Part 5: Admired Projects and the Chromium Monopoly

[vak]

[36:46]
You've mentioned those projects, and you often criticize bloated software. What are the top three software projects that you actually admire, and what makes them great? Well, number one would have to be Linux. It's maybe hard to imagine a world in which we didn't have it, but a world with only proprietary operating systems would be significantly worse than the one in which we get to enjoy Linux. I think we can all agree that Linux has been not only incredible for free and open-source software developers, but it has also been a boon for just the economy—countries around the world, businesses around the world being able to build their businesses on Linux for free is really good for the economy. So however you want to look at it, from a hippie perspective or a fiscally conservative perspective, it's really good.

Next, I would say Blender. I really respect Blender because it's used professionally, and it's an open-source project where it's competing with companies that have a lot of money and a lot of software development labor to spend on the problem, and it's winning. It's open-source software; that's brilliant, and it's also a nonprofit.

And the third one would be VLC. VLC is another nonprofit organization. I think that if I remember correctly, the president is still JB. I met him in person in Paris, and I think that that is a really well-run nonprofit. Earlier on, when I was just out of college, I contributed to FFmpeg, which VLC uses as a dependency. The VLC organization paid for the travel to go to VideoLAN Dev Days for anyone who had contributed to VLC or any of the libraries it used. I was this kid, and I got to go to Dublin and Paris for VideoLAN Dev Days on that nonprofit organization's dime. That was an incredible experience that I got to have there. I was really impressed with how JB handled the organization, and I mean, who doesn't love VLC, right? Everyone loves VLC. I used to teach Blender to kids many years ago, and of course, I'm using VLC.

Our showrunner noticed that you use the Firefox browser on your streams. I use it too, but she was very surprised. Why Firefox? I'm a little concerned with how little browser diversity there is. After Microsoft killed Internet Explorer—good riddance, I guess—now there's only Chromium, Safari, and Firefox left. Chromium has the vast majority of the market share, and i think that that's a problem for the web. I think it's a pretty uncontroversial thing to say that, in general, monopolies are bad, and having a monopoly on the web browser would be worse for users than if there was healthy competition. Originally, I just picked Firefox because it was the underdog and it's a nonprofit, and that's my contribution as a user to trying to not be part of the Chromium monopoly.

But I have to say that lately, I've been not very happy with Mozilla. Even though it's a nonprofit, I think it's an example of one that has a lot of corruption, and their alignment is not with their users, it feels like to me. That's an area where I feel really frustrated because there is not really an alternative. Chromium is Google, Safari is Apple, and then we have Firefox, which seems to be in a tailspin. So I don't know, I don't know what to do about this. There are some new browser projects being made, but until those come to fruition, I don't know what to do.

Part 6: Replacing C and Comparing Zig to Rust

[vak]

[40:57]
Andrew, Zig is sometimes positioned as a C replacement, but C is everywhere: Linux kernel, embedded systems, 7 million developers. What makes Zig better than C? Zig is better than C because Zig does not give up any of the power that C offers, while improving the flaws and the weaknesses that C has. The other attempts to replace C always give up something that C has. I think a good example of this would be Go. The Go programming language is really nice for writing server software; it has HTTP in the standard library, that sort of thing. But there is a whole class of tasks that you can never use Go for that you can use C for, so it's a trade-off. You had to give up something to get those nice things with Go, for example. That's why Go is not a C replacement.

With Zig, you have not given up anything. Anything that C can do, Zig can do, and it can do it better. It can do it with fewer footguns, and it can do it in a way that's more debuggable if you run into a problem. In a way, Zig embraces C more than C embraces C. C only has optimized integers for signed integers, and C only has wrap-around semantics for unsigned integers. In Zig, you can have whichever one you want. You can have wrap-around signed or unsigned, and you can have promised no-overflow signed or unsigned. This is just a glaring missing feature from C; it's a lack of power that C has. Zig is actually offering you—arguably, it's being more C-like than C is, if that makes sense.

But is it even possible to replace C? In order to replace C, you have to beat C at its own game. You have to offer people a way to write code that is reusable everywhere: code that can run in an operating system kernel, code that can run on embedded devices, code that can run in video games, code that can run in WebAssembly. This is why C sticks around. If we provide these features and we become as stable as C, then people will make the right choice. They will choose what works better, they will choose what has better performance and leads to fewer bugs, but they will never give up what C has. That's why I think that Zig will succeed in replacing C, because we did not give up anything that C has.

How is Zig different from Rust? The core feature that's different between Zig and Rust is the type system. Zig is a simpler language than Rust in the sense that the type system does not have a meta-language that describes what types are allowed to pass to which functions. In Rust, when you have a function and you take a parameter, you have to say, "Okay, this parameter supports cloning, or it supports this interface or that interface," and you have to describe in its entirety the rules about what you can pass to this function. Zig does not have any of this machinery. In Zig, you have to pass a concrete type or you have to pass a generic type like templates. They work like templates in C++ in the sense that the code will get substituted with what you pass in. That is a trade-off. With the Rust code, you're going to have more guarantees about the type system, and with the Zig code, you're going to have more simplicity in the code that you're reading.

But beyond that, there are some deeper differences between Rust and Zig. I think one would be around memory management. Rust is leading you down a very similar memory management style to C++. People like to say RAII, and what that basically means is that you have objects, those objects have links to other objects, these are all reference-counted, and when the references go back to zero, then things are deconstructed. In Rust, this happens automatically, just like how destructors are run in C++, and that's how you kind of have to manage memory in Rust. That's what the language will lead you towards doing; you will not be fighting an uphill battle if you do it that way.

In Zig, allocators are much more explicit. We can do this kind of reference-counting style, but it will require writing this reference-counting code explicitly. In reality, what we end up doing usually is a memory allocation style more tailored towards the application. Maybe we use an arena allocator to group these allocations all together and then toss them all at once—very common in Zig. Sometimes we use a general-purpose allocator for this more object-oriented approach, and you can even come up with other kinds of mixes of different ways of doing it for very specific applications. But this focus on optimizing your memory layout, I feel, is more of a Zig programming language feature than it is in Rust. In Rust, you are more tied to this object-oriented lifetime strategy, if that makes sense.

That's about language features, but what about technological domains? When would you choose Zig over Rust? You would choose Zig over Rust if you want to have more control over exactly what your code is doing. In Rust, you're going to try to make your source code match the Rust way of organizing and modeling reality. You're going to try to make the borrow checker happy, you're going to try to create traits that satisfy your constraints, and you're going to try to satisfy the type theory of everything. In Zig, you're going to think about: "What do I want the CPU to do?" and then you're going to write the code that makes it do that thing. If you have this latter mentality, then Zig will be a more natural fit for programming than Rust.

Part 7: Developer UX, Strict Errors, and the Role of BDFL

[vak]

[47:18]
What's Zig's killer feature and why? The killer feature is the toolchain. When you use Zig, you're using a software suite that has no dependencies on the system, so it will work on any operating system that you choose, and you will be able to target your code for any operating system that you choose. You have independence from the system that you're running on. One thing that I like to focus on as a measure of how easy it is to hack on a project is the readme check—the steps to contribute in the readme. What do I have to do? Do I have to install a bunch of packages from my system? Is it different depending on which operating system I'm on? How many commands do i need to run in order to get an environment? Do I need Docker? Do I need to have specific hardware or something? For me, the gold standard is one line, one dependency, and it always works for everybody no matter what computer they're on. When you use Zig and the Zig toolchain, we have accomplished this. If you look at a Zig project, in the readme it should say steps to compile/steps to build from source: `zig build`. That's it. That is what the Zig toolchain offers projects: all the contributors will need to do is `zig build` and it will always work.

Many people argue that Zig is unnecessarily strict with unused variables. Why are they treated as compilation errors? This is an opinion that tends to flip the moment that the person has to refactor a large amount of code, because the bottom line is that it saves time. That error actually saves time because it catches bugs, and those bugs take a long time to find. It does not take a long time to add your annotations to discard the variables.

The thing is that, thanks to editor support—specifically, thank you to the ZLS team for implementing this—you can enable a setting in your editor to have these annotations added automatically. An annotation, I mean, it will just discard the variable if it's unused, and then take away the discard if you use it again. You may think, "Well, what's the point of this? You're just getting rid of the error." But the point is that now you can have two people who are collaborating on the same code, and they both can have their preference met. The person who wants the errors can uncheck the setting in the IDE; the person who thinks that they're annoying can check the setting in the IDE. Now this person doesn't have to care about getting the errors, this person does get to get the errors, and they can both edit the same code. In source control, the annotations are always present, so everybody wins, and it just saves so much time when you don't have to solve these bugs resulting from this error.

Some developers struggle with the new IO interface. Is it too complex or just different? I do think that I found an optimum here. The purpose of IO streams is abstraction. The purpose of it is to write code once. Maybe you are writing an image loading library, or code that will serialize to a data format, or code that is supposed to be reusable. To do that, you want to take a parameter which is either a reader (because you're consuming data) or a writer (because you are outputting data), and you want to write this code that can be independently put into a package and used in this application or that application, and this logic can be unchanged. That's the point.

The problem when you do this is you might throw away performance, because if you have your reading and your writing underneath this abstraction layer, it can be hard for the compiler to perceive that logic and do these optimizations. I found this optimum where this interface has the buffer in the interface, and that helps the compiler to make good code while still allowing the user to achieve the main goal of reusability. I think that it is simple to use the interface, but there is a complexity in implementing the interface; that's what I think is more difficult. However, I would argue that that complexity is not accidental. That complexity is the natural consequence of finding this optimum of both performance and reusability, and that just means that this is what the implementation has to look like. I would make it simpler if I could, but this is the way that we write reusable code that will make the computer do what you want it to do, and that is our order of priorities in Zig.

Zig has a lot of unique features. What's the best way to learn Zig? I would highly recommend for new users to pick up Ziglings, and I want to really thank Dave Gower for creating the project and drawing the really cute picture in the readme, as well as Chris Bosch for dutifully maintaining it. That project has been consistently popular with new users. It has a series of exercises where you have almost-working code but there's a problem, and then you have to try to fix the broken program in order to learn a new language feature. Over the course of doing these exercises, you learn the entire language, so I would highly recommend for beginners to pick that up.

If you know C, is it easy to move to Zig, or is it a completely different mindset? I think that C to Zig is a particularly smooth transition. Everything you can do in C you can do in Zig, and with fewer footguns along the way. Just a simple example: if you get a segmentation fault in C, typically you will see no output other than "segmentation fault." You know, good luck, hopefully you know how to use a debugger. If the same thing happens in Zig, you will get a full stack trace pointing to each line of code where you were when this happened. But you can do the same things as you can do in C. When C people come to Zig, they find that all of their skills transfer over perfectly, and then they find that all of a sudden they make fewer mistakes, debugging is easier, and their productivity skyrockets. So that is a particularly smooth transition, I think.

There is a big debate in forums: should someone learn Zig as their first programming language? What do you think about that? I think that really depends on the person. Some people have a functional mindset and they really want to learn Lisp first or something like this. I do think that Zig is a nice language to learn if you are trying to learn how computers work. You will learn about CPUs, you will learn about memory, and any skills that you pick up in Zig will transfer to other programming languages. You're not learning—Zig does not have a borrow checker or something like this—you're not learning Zig rules, you're learning computer rules, and so that information will be valuable to beginners even if they give up and decide to go to a higher-level language.

What's your personal setup for writing Zig? What tools do you use? Well, because I make breaking changes a lot—or because at least I used to—I don't have a very high-tech solution. It's just the terminal and Vim. Because Vim is very resilient, you know, if I change the syntax of the language, I can still edit the code. Some of these other advanced things, like Tree-sitter or a language server, require a stable syntax tree or a stable language, and things kind of will break if you break it. I needed a setup that is resilient towards these things. But I have to give a shout-out to the ZLS team because they've really done a good job filling a gap where people need this language server, and it's not something that we provide yet.

ZLS in simple terms, what is it? ZLS stands for Zig Language Server. It is an implementation of the Language Server Protocol for Zig. That is a third-party project that's not run by the Zig Software Foundation, so those contributors are doing all that work of their own volition. If you enjoy their work, then I would suggest visiting their homepage and considering making a donation.

Zig's website also recommends some JetBrains products. Have you used them yourself? I have never used a JetBrains product because it's closed source. What's missing in Zig IDE support today? What do you wish tools like JetBrains CLion or VS Code did better? Back in the day, I saw the high-level refactoring tools that things like JetBrains or Eclipse can do with Java—things like "extract to function," or reordering function parameters, or globally renaming something. Just these things that can take a lot of time to do by hand, but the computer can do perfectly and instantly with type information and syntax information. I thought that was really nice, and that is something that I eventually want to add to my workflow personally, instead of using Vim macros or `sed`. I would also imagine even a more sophisticated refactoring tool, almost like a query language for making big changes based on type information and other cues, where you can make 10,000-line diffs that you're confident are correct because all of the changes verified that the type matched a certain type. Eventually, I dream of these productivity features. One could say that an AI agent can solve it for you, but then I have to review it. If my task is to rename a variable, and I use a tool to rename a variable and I know that that tool will work, I can then do that, make a commit, and never look at the commit. I don't need to review that; I know exactly what that did. I have 100% confidence that it's correct. If I ask the AI tool to rename the variable, I still have to review the code. That's worse; that will take so much longer than the other change.

Your other label: Benevolent Dictator for Life (BDFL). Can you explain what it is? Yeah, you know, it's funny, every time I jaywalk in front of a bus, I think about this. In software projects, you kind of have to choose between having hierarchical control or having some kind of democratic process. A lot of projects choose hierarchical control because it's simpler, so you don't have people struggling for power or you don't have to try to build consensus on changes through some kind of voting system. As we know, democracy is difficult, and so a lot of projects will choose BDFL-style for simplicity, if nothing else. That is the default style that a project has when only one person is the maintainer. Unless you try to introduce a more democratic process into a project, then BDFL is what you will get by default.

Why is one dictator better for language design than a committee, like in C++? The trade-off here is if you have one person in control, then that person has the responsibility to try to understand everything and have a coherent vision for the project. When you have a committee, sometimes you can have the problem where many different people have disagreeing visions for the project, and these disagreements are valid. This person has a valid use case, that person has a valid use case, but there is not a single way to do the project that will support both of these use cases—they're at odds. If you compromise, then you end up with a worse product than if one of those persons lost and one of those persons won. With a committee or with a more democratic process, we try to find these compromises more because we try to cooperate; we want to be nice to each other, we want to help each other. That is what the process leads to: compromise. While I think that that has social benefits, it also has the trade-off of lacking a coherent vision for the software project.

Don't you feel this model has a risk? Zig today is you. What happens if you leave tomorrow? Software engineering-wise, I think we'll be fine because my colleagues are very talented and they're very capable of carrying on the operation. However, from a political perspective, from an organizational perspective of the Zig Software Foundation, i think that my work is not yet done. If I were not doing BDFL style, then the project would suffer from, if you will, oxidation from being in contact with money. Whenever money flows through a system, the system becomes corrupted, and having a strong hierarchical leadership—as long as the person in charge wants to resist those influences—then that will happen. But when you try to set up a democratic process, the money corrupts it. I don't think that a strong leader controlling everything is sustainable. At some point I want to retire, at some point I want to do something else. We've all seen European history where monarchies are fine under a good leader, but their offspring is a bad leader and then everything goes to shit. It's not sustainable; you need a democracy for long-term sustainability. Then the challenge is setting that up so that it does not get corrupted over time with the influence of money.

Part 8: Personal Motivation, Work-Life Balance, and Burnout

[vak]

[01:02:34]
You've been working on Zig for over 10 years. What motivates you to keep going? I love my job. I wake up every day excited to work on Zig. To me, it's—it's kind of dorky, but the Zig project is kind of a shrine to computers. I love them. I love computers, and I want computers to serve people. Zig is my optimistic gift to the world that a great programming language and toolchain will lead to this outcome, and i'm putting my faith in my fellow humanity to use this tool to do this task. I love it. I think that it's very satisfying to please users and to make software that creates this compelling user experience. It's like a performance. The same feeling a musician gets from performing on stage, I get from making great software for users.

What is the hardest part of this process? Taxes. Mostly kidding, but the paperwork of running the nonprofit, yeah. Running the nonprofit, it's completely necessary to be legally above board and to accept larger donations, and obviously, this must be done. Someone has to do it, and right now that someone is me, and it's just, you know, nobody likes paperwork. Some days I hold my nose and do the accounting work, and some days I get to do programming, and those are the good days.

When it comes to actually coding, are there hard parts? Sometimes it takes a long time to update code when making changes. For example, earlier we talked about IO reader and IO writer changes that came out in 0.15. Initially, working on these interfaces was very satisfying because I solved a problem, I found an optimum, I came up with an API, I tested it, I got it working, I found a novel solution to the problem space compared to other programming languages—great. Then I spent the next six months fixing the standard library and projects in the ecosystem, updating the code, rewriting code that was working before now to use these new interfaces. In other words, taking on the same suffering that I was inflicting upon my users. I also had to suffer in the standard library, and that took a long time. Some days I had to rally the willpower to continue, but I got through it, and so we got to where we are today. Sometimes these big changes do require willpower and determination to get them finished.

Have you ever experienced burnout as a programmer or as a leader? I think that burnout happens when you're putting in a lot of effort but you're not seeing a lot of rewards for this effort. I think that I'm largely protected from burnout because while I am putting in a large amount of effort, I am seeing rewards. I do see happy users. I do get to make a release of Zig and look at all the release notes that I just wrote up and see all the improvements that we made. Sometimes the reward is delayed, like when I was doing this big change to IO and it took many months to update the code—that starts to feel a little bit like burnout because the reward does not come for many months. But eventually it comes, and I feel better. To a large degree, I think that I have not experienced burnout because I do derive a large amount of satisfaction from my job.

Do you have any advice for those who struggle with that? If you mentor someone, is it a topic to discuss with them? Okay, so the first thing I would say would be: don't forget to exercise and get good sleep, and eat healthy. These things compound, so just check those boxes and maybe that will solve the problem. But now let's move on in the flowchart. I think that a lot of people's jobs are unsatisfying. If you don't like what you have to do, if you think that what your company is doing is not valuable for the world, and then you have to work hard—that's a recipe for burnout. You have two choices in that situation: you can do the hard work of finding a different job or trying entrepreneurship (create your own job, which will be a lot of work), or you can slack off and stop trying at the company that you work at. We don't want to believe that that's a good solution to the problem. I think if you have the motivation, energy, and drive, the first one is better. But if you work for a soulless corporation, then stop trying. Go home at 5:00 PM and do something else. Don't try so hard. That would be my advice for people who feel burnt out.

What brings you joy outside of programming? When I finally quit working as an employee for my career—at the time it was for OKCupid—I went from moonlighting Zig, working on nights and weekends, which was very stressful, to now it's my main job and now I have free time. That was a really beautiful turning point in my life because I got to have hobbies again. The first thing I did after that was run a marathon. I've done exactly one in my life. I think that's enough for me. Is it possible to quit doing marathons? I still run. I have to agree with you, yeah. I think I will try to run another one because I did finish, but I walked part of it at the end, and i feel like I want to run the whole way. So maybe I will try another one. I also remember getting to mile 21, hitting that wall really hard, and starting to walk, and then a man ran past me who must have been 70 years old. I thought to myself, "How are you doing this right now? How am I...?" Even when I saw this man pass me, I couldn't run; I still walked. I still think about that to this day. That's a lot of motivation, I believe. Yes, so maybe I'll try again—a marathon.

But I also read somewhere that you are learning Japanese, right? Yes. Why? It's hard. It's very hard to learn Japanese, and I'm United States born and raised, so I only know english. I always wanted to know a different language just to be part of the world, and so I picked Japanese. I've always loved animation, I like the challenge of learning Japanese, and i think the culture is very interesting. I have to say, shout out to my tutor, Yuko. She's a very, very nice teacher who I found recently in Portland, Oregon. Because it's so difficult to learn Japanese, I've sometimes suffered from a little burnout trying to learn it, but after I found Yuko—Yuko Sensei—my motivation has picked up and I feel motivated to keep studying every day. So I wanted to say thank you to her. How many hours per day? Maybe one every day.

What does success look like for Zig? I think there are two answers to this. In one sense, you could say it's already been achieved because we have a diverse income stream, so we have financial independence from any single entity. We already have users who are happy and who continue to use Zig. We're already working on improving it; every year we have about two releases, and so this is nice, this is sustainable. We don't have to change course; the course is good already. From one sense, that's already done. From another sense, I would like to see more adoption. One measurement of success would be adoption on the level of Go and Rust.

When you say adoption, is it important for you to have commercial adoption, or does it not matter? Commercial adoption is useful because we can get money from corporate donations—we have to be careful to keep those diverse, but it's still very useful. I would not ignore this use case. Also, to make something that's generally useful, it will certainly be useful for corporations, and we can see this reflected in how many companies or how many people are using Zig for AI right now. If you make something useful, people will use it, so that's good. Even if I find someone's vibe-coded project personally to be boring, I do think that it would be a sign of a useful programming language that people are doing what's popular with it today.

If you could go back to 2015, would you still start Zig? Absolutely. The day that I quit OKCupid and started to work on Zig full-time was the best day of my life as far as the trajectory of where it went. I'm so happy that I did it, and it's just given me a profound sense of fulfillment and independence, and just a value of myself—how I see myself and my contributions to society. I think that I'm basically unemployable, and I got lucky through my career that no one found out. I needed to be my own boss in order to be happy, and so once i was able to do that, then I achieved happiness. Now I am happy.

[b0p0h0k]

К человеку, который знает как сделать DAW from scratch, я уже отношусь как к небожителю. Такого знания должно быть вполне достаточно для хорошей карьеры на всю жизнь.
И тут он берёт и всё бросает, и начинает from scratch создавать язык, который должен победить всех.
Невероятно.
Интересно, вернётся ли он в конце концов к своей DAW.
Это напоминает мне Вирта, который говорил, что вся его карьера с языками была всего лишь diversion, подчинённая главной задаче - написать программу управления модельным вертолётом, которая поместится на одной страничке. (Задача была им решена в 1995 на подмножестве Оберона).

[juan_gandhi]

This is amazing. He's absolutely right regarding all the languages mentioned. One thing is not clear to me, why he couldn't use plain C. Zig is basically like C, but with details.

Well... I would use Forth, but who uses Forth these days.

Oh, and thank you so much for posting all this long read. So inspiring. I mean, the very fact that such people exist IRL. People with such honest opinions. Amazing.

[straktor]

Как наверное уже сто раз шутили, "зиганул".

Нишево, пусть цветут все цветы. Практически, даже питон средний питонист знает средне. Если чел на старте меняет Io API, и исправляет юзерам код, то это цирк и несерьёзно. В си вызов creat() так и зацементирован.