CoRecursive: Coding Stories - Story: Full-Time Open Source

Episode Date: August 2, 2021

Today's show: How to Quit Your Job and Work on Open Source Full Time. This story has it all, balancing open source work and full-time employment, building up enough supporters and enough savings to leave your job. The hardest part to me which is explaining leaving your job to your significant other and to your family and friends. And also what do you do if your project succeeds, and then someone forks it and builds a commercial business around it? There's a lot more as well dealing: with hacker news feedback, how to improve upon the C programming language and how to be super ambitious without seeming arrogant. Sponsor the podcast: If you go to patreon.com/adamgordonbell, you can find the Patreon page for the podcast, and if you are enjoying these episodes and want me to keep putting more time into them, think about setting up a recurring donation. Links: Andrew’s personal website Zig

Today, on Co-Recursive. Let me be clear about this. Commercially, forking Zig is fine. It's MIT-licensed. Like, go for it. But what they did with the fork was, like, be very tricky about it, right? So they actually deleted the license file,

put their own license in it, and made it look like you had to pay for the software. So they were deceiving people. That was the problem with what they were doing. Hello, and welcome to Co-Recursive. I'm Adam Gordon-Bell. Each episode, someone shares the story of a piece of software being built. Today's show, how to quit your job and work on open source full-time. This story, as it all, balancing open source work and full-time employment, building up enough supporters and enough savings to leave your job. The hardest part to me, which is explaining leaving your job to your significant other

and to your family and friends. And then also, what do you do if your project succeeds and then someone forks it and builds a commercial business around it? There's a lot more as well, dealing with hacker news feedback, how to improve upon the C programming language, and how to be super ambitious without seeming arrogant. And my guest is this guy. My name is Andrew Kelly. I am the lead software developer and president of the Zig Software Foundation. Zig is a programming language, and we'll get into why it's needed. But Andrew got started on Zig because of another side project.

I started working on a music studio project. And in this music studio project, you have more difficult requirements than you usually have in other programming projects. So, for example, if anyone's going to use your music studio software live for live performance, you have a hot loop where you absolutely must not skip the audio or their entire performance might be compromised. So you just have these new constraints where you really need control over how it's going to work. And likewise, if you want to support all the hardware that's associated with this, a lot of times you're not going to be able to rely on someone else's third-party library to do that for you. You're going to have to get into C, C++, or another low-level language that gives you the control that you need. And the other thing I noticed is that when I tried to use other people's libraries, if I ran into a problem, I wouldn't be able to fix it.

It's too slow. I'm trying to make progress on this big project, and I learned the value of inventing stuff here, right? People are always telling you don't invent, you know, NIH syndrome. But I learned the value of actually, yeah, that is the right thing to do sometimes. Like if you really want that much power and control, you got to do it. So that's when I started just really getting into programming stuff from scratch with C or C++. Even in C, reuse is common, but reuse can bring problems. I think that the natural first impulse was that if someone else solved a problem, just go use their solution, right?

It's already done. You write the glue code and then you're off. In a lot of ways, that's smart because, you know, we only have so much time. We only have so much ability to analyze a problem space. And the other person has already done that part. So let's see, what's a good example of this? The audio library would be an example. So I tried using port audio.

I tried using SDL, I think. These projects mostly work, but then the problem is that they solve 90% of the problem. And if you want to close that last 10% gap, you have to start over. So I ended up writing my own cross-platform audio abstraction called LibSoundIO. And that allowed me to do things that the other libraries didn't let me do.

So, for example, I had the ability to just display a list of input devices and have that automatically refresh. If you unplug the mic, it goes away. If you plug the mic in, it shows up. It seems so simple. It seems like such a reasonable thing for the user experience. But these other libraries just did not have that ability. And it would have taken me probably, honestly, years to get the feature into those libraries and then have enough time pass that those libraries got the updates into the various,

you know, open source distributions of packaged libraries. Because if you use a third-party library, people want to use the prepackaged versions. So then you're even waiting for their release cycle, and then you're waiting for the downstream maintainers to get it. But if you put it in your own code base, you just ship it when you want to ship it, right? And there's just so many problems with these languages that get in the way of progress. bugs take forever to find and fix progress is slower than it should be and so that's when the juices started flowing and i thought i think i can do better than this like i think i i think i see what these languages are bringing to the table

and i think i can take them to the next level did you fight that impulse did you immediately get sidetracked i'm i'm building a language or what happened i did i did fight that impulse? Did you immediately get sidetracked on building a language? Or what happened next? I did. I did fight the impulse. And I stuck with the music player project for quite a while. And then, to be honest, I just went through kind of a difficult life experience. It was a breakup at the time. And just as kind of a coping mechanism, I let myself say, you know, hey, you know, I

know you've been trying to be this disciplined and stick with the same project for a long time, but go have some fun. Start a new project. Start a programming language. It'll be good for you. And then I just never switched back. So was it like you were like, my whole mind is occupied by this breakup,

but I think if I start this new project, it might be able to squeeze it out of my brain, at least temporarily yeah that was exactly right and did it work I mean I think just the natural you know emotional progress ran its course but just in the meantime I was having fun with a distracting toy project yeah I mean it's it's certainly more productive than like I don't know playing Mario Kart for eight hours a day or something. I like Mario Kart. I don't know. Yeah, Mario Kart's a great game. Andrew had always wanted to create a programming language.

The very first time I ever used a programming language, I always wondered, what would it be like to make one? You know, and whenever I listen to music, I always wonder, what would it be like to try and make a song like this? I've always enjoyed just consuming things by just wondering what the other side of the process looks like. When I was in university, I had a class where we built a compiler, like a toy compiler, and it was super fun. Andrew had a similar experience and went on to toy around with a fork of coffee script. I found playing with programming languages to be fun, but Andrew, he got something different out of it.

You know what it was? I actually ran my first marathon a couple years ago, but I don't feel like I did because I walked the last four miles of it. I hit that wall hard. And I guess most people do because I was still in like the top 50% for my age group. So I guess just most people walk at the end of marathons. But in my head, it's like you didn't do it. You walked part of it, right? So I always felt that way about the compilers that I'd made because, you know, if it's like a CoffeeScript one, you're actually just outputting JavaScript. And then for the one in college, the professor just had us do C as the output. So I

always felt like I walked the last part. I always wanted to say, no, I want to make it actually make machine code and make it do the whole thing. I don't want to cheat on some of the layers. I also don't want to devalue the work that people have done. That's all still a compiler. If you go from one input language to a different input language, that's a compiler. That's just my personal subjective experience is that I felt like I was missing some interesting part, but I hadn't had the experience of completing. Andrew understood before he even started what the C language brought to the table. And this is important.

C is a small language and it's everywhere. If you don't write C, it wouldn't be wrong to think of it as running underneath everything that you're building. C is still used by 20% of software developers, according to the Stack Overflow survey. So conditions may apply there. I don't know if the Stack Overflow survey is representative, but they have a lot of developers using it. And 20% of them say that they are writing C. That's one in five developers. That's more people than use Ruby and Swift and Rust combined. So anyways, Andrew has his breakup,

and he gives himself permission to start on his language. His idea isn't to start from first principles and create a new language, but to look for specific problems that can be addressed. Is there dirt under this rug? Maybe we can do this a different way. You know, let's, you know, a lot of software is built on premises of abstractions that previous generations have handed to us. Let's peel those off a little bit and take a peek and say, maybe we might want to make some different decisions now that it's, you know, 40 years later.

What's an example? One example would be static linking. If you're trying to ship a application on Linux, there's a common problem people have where it'll only work on one distribution of Linux. So for example, someone might provide their application on their website, you download it, but it only runs on Ubuntu

or something that's close enough to Ubuntu. I literally just had this problem. I was trying to install a Python library, matplotlib, and on macOS it was super easy, but to get it into Alpine Linux, I had to install all these dependencies. And the reason for this is that they dynamic link all the libraries they depend on.

They just expect you to install those libraries with the system package manager. I've chosen to make ZIGs so that the default on Linux is that you do not link libc at all. When we provide the download of a pre-built ZIG for Linux, it works for all Linuxes, all of them, because the binary has no libc dependency. It just uses the syscalls in assembly,

and the only dependency it has is a file system and the kernel. It doesn't depend on anything else. So that way we can provide a binary that just works for everybody's computer on Linux, just like on Windows and other systems. We got that benefit by questioning distributing things with dynamic linking and saying, well, maybe we should go a different direction. Go to something similar? Yes. I think it does depend on glibc though. I know that you can actually use ZIG with Go

and ZIG will provide the ability to have a static Linux binary and give you this benefit with Go programs. So were there other aspects of C that you were targeting that frustrated you? One is that there are just too many ways to accidentally introduce bugs that are not interesting bugs that you get because programming is hard, but they're unnecessary bugs because the C programming language

made some bad decisions. So as an example, there's a type system, and the whole point of a type system is to help you not make bugs. But the type system has some things that it allows with no errors and no warnings that just are bugs 99% of the time. And it's very easy to make that mistake. Just stuff like integer casting rules is one. So that's one complaint I would make.

Too easy to shoot yourself in the foot. And then have an unnecessarily complicated debugging session to solve the problem. And then the second complaint I would make is that while C code is usually very simple to read because it's just functions and data, that's the best case scenario, it does have just another different programming language on top of it, which is the C preprocessor. It's not C, it's a different language that's based on text concatenation. And people abuse that language too much. And then

it's just too hard to figure out what's going on. Like you see a function call. Is it a function call? If you're not super familiar with the code you're reading, you're always wondering, is that a macro? It might be a macro, right? Yeah, like it requires like global knowledge of like what all of these things are. Global knowledge is a great way to put it. Yeah, one of the big design considerations that I made with the Zig language was,

let's reduce the amount that someone must remember when they're reading code. Another thing Andrew thought he could improve upon was more cultural. Some people are so defensive about a norm where people are mean to each other. And don't get me wrong, I'm a

very blunt person. I'm very comfortable with conflict and I can tell someone I think that they're full of shit. But have you ever gone into the C free node channel and just observed? No. That is one of the most toxic, hostile chat rooms I've ever been in.

Before the Freenode drama, the C programming language channel on Freenode. Like you can go in there and ask like some simple question. Like how do I, I don't know, how do I align a field in a in a structure some some very reasonable question and you'll get one person who calls you a name one person who says you can't period passive-aggressive doesn't explain it at all one person who gives you like just wrong information and like the actual answer is that you can do it. It's fine. And there's some tricks you can do. It's one of the worst places in the world. I don't know what's up with that.

The one word I'd use to describe it is pedantic. There's even a flag in a C compiler that's pedantic. And I always think, oh, it's the C chat room flag. With this vision in mind of a better language and a better, less pedantic community and a working version of the language up on GitHub, Andrew starts to get some users. The number of people who file an issue per week has just gone up slowly over time. The number of people who wanted to help out,

submit pull requests, which were up for grabs since the very beginning. It was always done in the open. It's just slowly gone up over time. One of the first projects that I got to see that someone did with Zig was the Pokemon ROM randomizer project. So they used Zig and made a set of command line tools

to take the Game Boy ROMs that were Pokemon ones and just did some ROM hacking and then gave you a new ROM that you could then pop into an emulator and it would shuffle around all the which grass have which Pokemon and stuff. Building a programming language is just a lot of work. You have to find time to keep pushing it forward. I would describe Zig as kind of like a flower growing in the cracks of the concrete of my career. When I started it, I was taking a break from full-time work and then I needed a job.

So I got a job at a startup called Backtrace. Did that for a little bit, saved some more money, quit. Worked on Zig full-time for a few months. I interviewed with Apple and they just flat out said, you may not do that in your spare time.

So I said, fuck off then. And now I have getting donations from Apple to the Zig Software Foundation, by the way. That's awesome. Joined OkCupid, moonlighted Zig during that time.

Was there ever any tension? Like I imagine you're at OkCupid or the other place. And I don't know, is work building up or is there things to do? Do you constantly try to evangelize how great your language is to your coworkers until they get angry? What happened? Oh, yeah. When I joined OkCupid, I had to have a whole negotiation with the recruiter.

Because a lot of companies just put in the contract something like, anything you do in your spare time is owned. The IP is owned by the company. It's ridiculous. So I just said, you have to strike that from the contract. Like, I'm going to own all the IP of everything I do in my spare time on my own equipment. company it's ridiculous so i just said you have to strike that from the contract like i'm gonna own all the ip of everything i do in my spare time on my own equipment and the guy was like oh no one asked for this like we don't we don't usually do this like i'll see what i can do and like i had to take a real like hard line stance with him eventually he caved you have to protect

your baby or someone's gonna take it away away. Yeah. That's silly. Right. And you know that they had no problem striking it. It's just, they didn't want to go through the problem of like, like he didn't want to find out who to ask about that. Yeah. He was just like, didn't want to bother. Yeah. But what about like your actual like coworkers? Did they know you were working on Zig? Did you, did you talk about it? Oh yeah. I wasn't shy about that. And yeah, I tried not to be annoying, but I couldn't help if we had some problem in the code base. I couldn't help point out like,

well, in Zig, if you wrote, the code would be written this way and this problem would have been a compile error instead of a bug. In some ways, I think it helped me design the compile errors because I was just seeing the problems that we were hitting in practice what like what technologies were they using at okcupid it's a big c++ code base it's

kind of unexpected to me that it would be c++ like I just assume all like sass stuff is like I don't know not c++ yeah so the funny story there is that the company was founded, I don't know, 15 years ago by Maxwell Cron and this other guy's name. Their PhD thesis was called OK Web Server. And it was just like some, it had nothing to do with dating. It was just a way to do security on a C++ web service. And so basically they did their research and they thought, okay, now what? I guess we'll start a company. So OKCube is actually named

after the research paper OKWebServer. That's funny. Yeah. Yeah, so it's like arbitrary that they use C++. Well, it's actually arbitrary that they went into dating.

Right, exactly. Yeah. Yeah. It was always going to be C++. They just didn't know what. And the funny thing too is like when you join the company, they just have you read the paper

because it just is still accurate about how the code base works. I mean, in some ways that's great because most places have code bases that there's not a single person that can explain the entirety of it, right? Yeah, I agree with you. Although I will say,

just having spelunked through a bunch of that old code, I could tell that like the founders were just having a lot of fun and just like experimenting a lot, just playing with stuff. I'm just like, who cares? Like we're definitely going to exit from this startup and like leave in like four years. Like I don't give a shit. Right. Like you can see it in their code. You can tell they're just like screwing around and they really don't care about like the longevity of yeah it was pretty i i feel like i have kind of like a parasocial relationship with the founders because i don't i didn't actually like interact with them but i interacted with their code and i'm just like why did you do this to me yeah what is i don't give a shit i'm gonna exit like c++ look like there was like a file that was like a Perl script and a C++ file. And to update it, it's self-updating. So you run it with Perl, and it edits itself.

But then you're supposed to... It's for the C++ project. Does that make sense? It's a polyglot file. So the same file is a Perl program, and it edits itself like a weird hack so that it could be parsed by both. That's amazing. It's a polyglot file. So the same file is a Perl program and it edits itself like a weird hack so that it could be parsed by both. That's amazing.

It's very cute. You know, before you went full time, did you ever feel like this is too much to do this and my job? Oh, I was definitely stressed out. Yeah, my fiance can tell you about some of the times I just kind of just showed up very very stressed and just like unable to like be a good partner but I never even considered quitting doing zig

stuff the only thing I ever considered was quitting work my my the thing that was causing me so much stress was the feeling that I was wasting my life just on just bullshit, like wasting my life just being a pawn in someone else's just like play to get money, you know? Whereas what I felt like I was doing with this open source project was more meaningful. I mean, we create our own meaning in life. Like I'm not here to judge what anyone wants to do with their life.

If you want to make money, go make money. But I don't want to be a pawn in your gambit to make money. I want to do what I think is meaningful in my life. And for me, a large part of that is just contributing as a collective to open source software. And I could tell as Zig was picking up more steam, I could tell that I was missing out on opportunities because of the full-time work. People who would become contributors were kind of just turned away because they didn't get enough attention that I would have given them if I had more time. Or just the progress, the rate of progress didn't match up to my ambitions of what I wanted it to be.

I think I just became very, very aware of the opportunity cost I was paying by being employed for someone else. And that was rough. That was probably a low point in my life. Fortunately, Andrew had a plan that he got from Alan Webster. So that's someone from the handmade community. I met him at Handmade Seattle. But I noticed that he was making a text editor and he had a Patreon and he was getting something like 400 bucks a month or something like that. And you know, that's not

enough to live on. That's like maybe enough for groceries, for food for a month. But I thought like that's progress and that's a big amount of money. Like even if I'm just going to try and save money and then quit and then go back to work when I run out, that would help me delay, that would help me give me more runway. So I thought maybe this can work. So I started just paying really close attention to everyone who did this, just kind of imitate them. And so, yeah, so I did a Patreon at first and there was never a spike. It was always just like very, very slow growth. I started doing live coding streams.

I started, I just put like, you know, links to donate to me at the bottom of my blog posts. You know, every time I got a blog post on Hacker News or Reddit or something, I'd get like a few more donations. But the point is they're recurring. People are going to add and remove. It's going to go up or down. But, you know, because of statistics,

you can just kind of count on it more. You can plan your life a little bit more about how much income you're going to get. And that was a total game changer. So like after a few months, I realized that it was predictable and I could actually like find out how to quit my job. And then that's when I started crunching the numbers and figured out that if I quit and if my donation growth kept up, that my savings would start, they dip and then they start going back up before I hit zero. Oh, that's clever. Yeah. You calculated like not just the amount you would need to survive, but how far you could dip into your savings before you'd come back out, the rate of growth or something. Right. Yeah. With conservative

numbers, but the math checked out. Yeah, it was really nerve wracking and scary, but it turned out even much better than I expected because the thing that I hadn't considered is if I quit full-time work and I got to spend full-time work on Zig, that would help me make more progress faster. Did you run this idea by others? Like, did you tell your mom, like, hey?

I told my girlfriend. She was really supportive, especially considering the fact that we were renting an apartment in Manhattan and she was still in school and wasn't like, you know, ready to start pulling a bunch of money in with her career yet.

So kudos to her for, you know, supporting my dream, even when it is like, maybe not financially completely stable. She was on board right away? Yeah. In fact, she actually encouraged me to do it. I think I was wavering a little bit and she was the one who was saying like, I don't know. I don't know why you're so worried. The numbers check out. I think you're good.

Was she the person you were afraid to run with this idea to? Like, I just keep thinking of my mom. Like your mom, what would you tell your mom? Like she doesn't really totally understand what I do at all, right? Like I think that it involves computers is the extent of it, right? So like, so telling her that I was going to leave my like paying job that involves computers

for like a non-paying job that involves computers. Like I don't think. Right, yeah, I see the point that think. Right. Yeah. I see that. I see the point that you're making. Yeah. I think for me, like telling the older generation about this was all kind of fun and games to me. So for example, my parents are like pretty financially conservative. So just like telling my dad like, yeah, I'm quitting my job and, you know, do this like donation thing.

And being just completely like I don't actually care what his feedback was because it's not relevant. But it was fun to just kind of like make him think like, oh, what is my son doing? Like it doesn't make any sense, but all right, I guess if it works for you, you know? And then my girlfriend's grandma was the other fun one. I recall she was saying something like, so what does he do?

He has a tip jar. It's like, yeah, close enough, I guess. That's great. Once you did quit, was it everything that you thought it would be? Like day one, you start? It was even more. I have, first of all, I've never been happier. Second of all, I realized that the freedom that I have has allowed me to open my mind up to just like other, even just like different politics and ways of thinking about society and how the world works.

It's harder to think about maybe more like radical ways that society could run when you have to play the game and you're spending, you know, you're spending 40 plus hours per week, you know, clocked in and just like doing the labor, you know. Not only was it everything I thought I would be, but like once I tasted this freedom, like I know I will never have a boss again. Like I will go start a farm if I have to like I my my just like sense of worth of self-worth has just skyrocketed and like I just I don't even want to be subject to like another person's you know like domain anymore like I want everyone to feel this way I want everyone to feel like they get to decide what they do with their life and no one's going to tell them what they have to do. Did you have a really bad boss?

Actually, no. Well, I did have one or two, but actually, no. I've had bosses that are fine. I've had good bosses. I had a boss that was like a friend, a coworker before who just kind of went into a manager position. I think that's why I realized that I never want to have a boss again is that I had a good one and I still really hated it. One thing Andrew hated in his work as a software

laborer, which is what he calls it, was the presumption of growth and growing profit. So to support Zig and to support himself and future contributors, he started the Zig Software Foundation and he started it as a nonprofit. So all the income just comes from satisfied users. And I mean, the product is free. So the point is, we don't have to grow. There's no venture capitalists who are breathing down our back saying that we need to monetize our users. The motives that we have for doing features and making progress is just intrinsic. There's no monetary incentives to do anything in Zig.

It's all just people-driven. And I think that, to me, I'm really happy with it being this way. And it's something that I didn't get when I worked at any startups. Another thing he didn't get to do when working at startups was show his work to the world. With Zig, everything was out in the open. And early on, Zig showed up on Hacker News. A lot of the comments were, you know, oh, we don't need another programming language, or, oh, this guy's an idiot. He hasn't even made a programming language before.

This is, like, his first one. Like, not actually true, but people just say whatever they want to say. It was all just kind of like, there's too many, you know, too many players in the field. Just get out of here. You know, shoo. That kind of thing.

And I wasn't phased at all. I was ready. I knew that that was the, I knew that was the game. And just kept working on making progress in the language and just kept peeling off those layers and reevaluating, like, what's the better way to do this? Like, how should the standard library work? Like, how should the language work? But I also did pay attention to the people

who had legitimate complaints. So some of the early legitimate complaints were that the sigils were too noisy. They had, like, percents everywhere. And they're all gone now. I think that was a legitimate complaint, and that's now gone. It looks a lot cleaner.

It's a lot more keyword based and it doesn't seem to be an issue anymore did you jump on when people said this is his first language or this can't be trusted like did you respond to them i wasn't shy but i i just kind of tried to only respond if i felt like i could like look good what are you trying to do in a hacker news thread right you're not actually interacting with someone. What you're actually doing is putting on a show for the lurkers, of which there's like hundreds of thousands of lurkers. And those are the people who are going to read your comments and be like, oh, this guy's cool. Like maybe I want to actually check out the project. I was actually just trying to like sell my personality at that point rather than engage

with just people saying stupid shit, you know. In that first Zig post on Hacker News, a lot of the comments were about the impossibility of replacing C. But Andrew hasn't slowed down. And things being impossible is not the main thing that people bring up right now. It's funny how it just kind of changes course, you know, as the language gets taken more and more seriously. And now the comments are even starting to shift to kind of like the philosophy of memory safety and like whether Zig is immoral. The morality comments, they come from people who see Zig as competition to Rust.

But Andrew doesn't see it as competition. So there's a lot of ways that these languages can be complementary and it doesn't have to be like a zero-sum game. And there's a lot of ways that these languages can be complementary. And it doesn't have to be like a zero-sum game. And there's a lot of ways that these projects can help each other. So as an example, both projects depend on LLVM. So on the ZIG side of things, we've submitted a lot of bug fixes upstream to LLVM, especially regarding non-x86 architectures, because we just have a really good cross-compilation story. Likewise, Rust has submitted

a lot of fixes to LLVM having to do with aliasing because that's just an important concept in that language. It's not as an important concept in C++, so that's kind of the changes

that they've made. So in this way, we can team up, right? That's great. We're on the same, we're all just players in the open source field helping each other out. But there you know people who want to make a

you know competition like which one's better which one am i going to use that sort of thing and so people just find ammo to fling you know and so the obvious one that you would pick is well rust gives you memory safety and Zik doesn't. And the talking point is that's a fatal flaw. Like it's 2021. We can't have memory on safety in a modern language. I think that they just kind of missed the point. So the way I would describe it is that Rust has a kind of like vertical memory safety approach where on the top it's safe and then on the bottom you hit the unsafe block and it's not safe right like let's acknowledge that rust is also unsafe because it has unsafe blocks in it at the at the bottom layer zig is more of a i would say horizontal safety approach

so there's no unsafe blocks where it's all contained in, but each feature of the language models safety in a different way. So as an example, the pointer type in Zig actually can represent alignment. In Rust, if you want to mess with pointer alignment, you have to use an unsafe block and you've turned off safety for alignment. In Zig, you have pointer alignment in the type. So it's actually completely safe and in Rust it's not. Okay, pointers. This is a really cool example. So pointers in C are just raw memory addresses, just integers that tell you where to look in memory.

And you can screw them up in a lot of ways. A pointer can be null, it can be incorrectly aligned, and so on. Raw pointers leading to buffer overflows are responsible for many security problems. But pointers are also super useful. In certain system calls, you can't make them without pointers. So Zig works to make pointers safer. They can't be null, they have to be optional instead, they know about alignment, and so on. Rust has a different strategy. Rust keeps pointers mainly the same as C, but it puts

them in unsafe blocks and says, you really shouldn't be using these. We have the borrow checker. Zig could have taken this unsafe keyword approach. I mean, if we did that, it would just kind of be rust. I think this question is also asking why not add a borrow checker? And the answer is, Zig also wants to be optimal. And optimal means you want to fully use the hardware that you have. So my hardware lets me use virtual memory, and it lets me use intrusive data structures, and it lets me write code in a certain way that's the most efficient way to use all the CPU and the memory. So if my language doesn't let me use all my hardware features, it's not optimal. Another way to think about this is Zig is less ambitious intentionally.

It's a smaller language. It's what if C were better? And one place you can see this is with the handling of undefined behavior. I think undefined behavior is a misunderstood beast. So a lot of people think it's just a crime. Like, why does it exist? Like it was a mistake to ever have it in the language. But I think it's actually a tool. I'll give you an example. Integer overflow is a simple example. So you can define it so that if you overflow 64-bit integer, it wraps. That's one way to do it. Now you don't have undefined behavior.

Okay, but now if you add something in your code and it overflows and you didn't expect it to, now you have a bug. And this is a really contrived example, but let's say it's like the bank balance or something, and you just went from a million dollars to zero or something like that. That's a critical bug that happened because of well-defined behavior. Whereas if we make integer overflow

for just like the regular plus operator undefined, then we can compile the program in a safe mode that doesn't allow it and crashes if it happens. And that's what you get in debug and release safe builds of Zig. So my point is that undefined behavior lets you catch bugs. Then also, let's say that you had this code now and you've tested it. It's battle tested. It's done.

You know, it's like some low-level library. No one's reported a bug in it for 10 years. Like, we're done working on it, right? It's finished. It's like the MP3 encoder or something. Now you can compile it in a different mode. And instead of putting a safety check in for the undefined behavior, now we tell the compiler, assume that that will never happen. And now if it did happen, it would be undefined behavior. But because we know that there's no bugs we can actually generate much better code

assuming that the undefined behavior will never happen. So in Zig, if you're not doing the fastest build then you're always asserting that this won't overflow and you crash if that's the case. Yeah, exactly. And that's better than setting that person's account

from a million to zero or whatever. That is in accordance with the Zig philosophy, yes. If you're running in your kind of release mode, you won't crash on it, right? In release fast mode, which is unsafe, you will get actual undefined behavior. So you might crash or you might get an overflow. You might go down to zero or you might get an overflow. You might go down to zero

or you might run an unrelated function. Run an unrelated function. That sounds super scary. That's why you don't really want to turn off these asserts unless you're certain that they're not needed.

I can see Andrew using this for the hot loop of his audio software where missing the timing of the audio is almost as bad as crashing. The reason for being able to turn these off is for speed. And not only that, but by not having the checks,

you're allowing the optimizer to notice patterns that would not be there if the checks were present. So for example, there may be like the array bounds checking maybe is inside a function. And by not including the checking, we were actually able to inline that function into the place of the call site. And then because of the lack of bounds checking, it was then able to see another optimization and flatten that out. It can have snowballing effects

to not have these extra checks in there. So while Andrew is pushing Zig forward, trying to tell people that undefined behavior is a tool, not a crime, something bad happens. Oh yeah, this story, huh? Yeah, we had this character come in and at first he just seemed like a really enthusiastic contributor. He did a lot of help with his pull requests, but I didn't mind. I would just kind of throw in a couple commits, some fix-ups, and just merge it and say, yeah, good enough.

I'll help you with the rest. But then all of a sudden, he just blew up at some kind of language decisions. He created a commercial fork, translated the documentation to Japanese, and then if you downloaded it, all the files were just the ZIG files, but he just changed the extension to Zen.

But he was a contributor to a certain extent. Oh, yeah. It said in something I read that other contributors left with him. I think that's not an accurate way to put it because it implies that there was some kind of controversy. But what actually happened was that just that one person, this guy's name is Chris Tate. The thing that actually happened was that just Chris Tate

just got pissed and left and no one else left. But then he offered actual money to one of the core contributors of Zig and that person accepted the job and started working on the fork. So that's what happened. And you know what? Fair, because at that point,

we didn't have the Zig Software Foundation yet. We couldn't offer any money to core contributors. You got to put food on your table. So I really, I don't even blame them for taking it. They got to probably improve their resume and work on something more fun and get some more money fine so where were there people in japan who were paying for a fork of of zig i really don't know

honestly this guy is a total weirdo it's like yeah like it's the kind of person where like they'll like share like conspicuous photos of themselves like shaking hand with some important person and then you're like what what's going on like what did you do with that person and it's like oh we had like a business deal business transaction it's like well what what did you do and then it's all show you know like it's a super weirdo guy like i don't even know i don't even know how to explain it. I'm not giving you a good synopsis of the story.

But let me be clear about this. Commercially, forking Zig is fine. It's MIT licensed. Go for it. You're supposed to just acknowledge

in the license that it's a fork. If you just take a file that's Zig code and you rename the extension, you have to keep the MIT license in there. That's fine. Go for it. But what they did with the fork was like be very tricky about it. Right. So they actually deleted the license file, put their own license in it and made it

look like you had to pay for the software. So they put like, oh, this is licensed by the, you know, our company's license and you have to pay like a hundred dollars a year or something for it. So they were deceiving people. That was the problem with what they were doing. As long as you don't trick people, you're welcome to do a commercial fork of Zig. Like legally, it's fine to fork Zig. It's allowed as part of the license, but it feels a bit wrong to me. Like Andrew built this and he deserves some credit for creating it. And if I were Andrew and I left my job to work full-time on this project and now it had just been forked by a commercial company,

I would have freaked out. Andrew is much more calm though. Honestly, it was just more of a curiosity for me. Like I wasn't ever worried about it, but I was definitely kind of just like curious about what is this guy's motive? You know, didn't seem like a effective strategy that he was taking you know um the thing that strikes me as strange is like like stealing something that's free and then trying to sell it like this kind of i guess that's not totally what's

happening but it's it's sort of what's happening yeah like people don't tend to pay for programming languages right now that that often i guess right right i mean it's possible that he was on to something he was on to something in the sense that he translated the documentation and then it became accessible to people who didn't speak english a lot of countries don't have a big enough like i don't know cultural impact on the world that they can get away with not speaking English. So in that way, English is one of the lingua franca of technology, for better or worse. But, you know, China, Japan, Russia are big enough that you can just be someone who only speaks those languages. This language barrier is the heart of the issue. But the Zig team had a solution for that.

We put out a little blog post just kind of explaining, hey, this thing that you're paying for, you can get it for free over here if you want. We're sorry we don't have the translation of the docs yet. Hopefully we can get that soon. And I think after that blog post, we got that blog post translated into Japanese. And I think that once people saw that and it went around,

they realized, oh, okay, that's better to just get it from the upstream rather than go for this guy. It's strange how this stuff, it doesn't faze Andrew. Of course, I can improve upon C. Of course, I can take on a commercial fork. People have talked to death the imposter syndrome, but this is the opposite. Andrew is just very assertive and

confident in what he can accomplish. From the very beginning, my attitude was, let's fucking do this, right? Let's go. I'm not fooling around. When you first make a project, like obviously you're not unique. You're not a unicorn. A lot of people have made a programming language. It's not impressive. It's not interesting. So, you know, people are calling it a toy language at the very beginning. And that's good. I just let it slide. Part of the job I have to do is like marketing and like getting people to be excited about it. So I know that like having a reputation of a toy language in the beginning is okay. And I'm not going to, I'm not going to fight about it. But in my head, I was thinking, oh, just wait.

This ain't no toy. That's awesome. I love that. Like if, if you were going to run a marathon, a lot of people have a goal to like finish the marathon, I guess, but you're like, I'm going to win it. Like, yeah, I can take down C. Let's go. Yeah. I do feel like I have a sense for like, what would, what's like cool and what's like kind of cringy, you know, you you know if your posts make it under reddit or something and so I definitely have been very conscious about how am I going to come off to people so that I don't seem like too arrogant and too like big for his britches or something even though I am yeah because in the back of your head you're like yeah let's we're taking down C, but you're like, let's get people slowly introduced to this concept.

Yeah, exactly. What does the world look like when you take down C? Oh, it's beautiful. It looks mostly the same, except all your apps just work slightly better, and they just crash less often, and they use less memory, and they just go faster. When professors teach operating system courses, it'll just be like obviously assumed that you just use Zig.

Like that's not the focus. That's just the setting. You know, when, you know, textbooks try to do, you know, how operating systems work or how embedded devices work. It'll just be like assumed that you're going to use Zig as like the example code because that's just what everyone does. The world won't really be that much different. It'll just be just a better programming experience

for everyone. So in one sense, I have a lot of ambition because I am trying to like dethrone this entrenched player. But on the other sense, Zig is not actually a super ambitious language. It's just trying to take it to the next level of like

faster, less memory, less bugs, like better development experience, better end user experience, just a little bit better. So it's just like an incremental improvement on C. Yep. So that's kind of the yin-yang

of ambition there. So like there's no vision of you like accepting, you know, your Turing award. Nope. Everyone will just be like a little less stressed in their daily lives as a programmer. That's it. Andrew is five years into building Zig and five years is a long time. And Zig is more than just him now. The Zig Software Foundation is now supporting other full-time employees. And this is all through donations. Andrew has some tips for self-funding your own open source projects.

I think that there's no better time than now for people trying to make a living in an unconventional way. My advice is do it because you love it and don't be afraid to put yourself out there on the crowdfunding platforms and ask for tips and don't expect overnight success. I also think that people do want a, they want something to believe in, right?

I think with early days of Zig, the feeling that I was kind of offering was we're going to take on C, right? This is an ambitious project, but like, I'm here to, I'm here to stick with it. I'm here to pull it off, you know, like, let's go, let's do this. And that's, that was a vibe people can get on board with. Let's do this. Let's go. A big thank you to Andrew for being on the show. He's a very inspiring person. You'll find a link to Zig Lang, the Zig language website and his personal website in the show notes. You'll also find a link to a Patreon page for this podcast. I'm very inspired by Andrew, so I've decided it's time to put out my own tip jar. So if you go to patreon.com slash Adam Gordon Bell, you can donate to the show. If you're

enjoying these episodes and you want me to keep putting more time into them, you know, I would really appreciate a donation. It takes me a lot of time to make each episode and I'm just me. It's just me in my home office. And that's why I'm only able to make one a month right now. So if you want to support the show, follow the link, check it out. And until next time, thank you so much for listening.