Software Huddle - Building a Better C with Loris Cro from Zig Software Foundation

Episode Date: March 9, 2024

Zig is a new programming language with big ambitions: to be a better C. Loris Cro is the VP of Community at the Zig Software Foundation, and he takes us through the ins and outs of Zig -- how was it created, what problems is it trying to solve, and where is it being used. We heard Joran Dirk Greef rave about Zig during our TigerBeetle episode, and there are a lot of passionate Zig fans out there. Zig has some really unique aspects, particularly the comptime keyword that allows for running arbitrary code at compile time. We also talk about Loris's background and his rapid rise to lead marketing for a software foundation. Loris talks about how he got there, how Zig things about community, and how they're working to make Zig sustainable.

What is Zig? If I haven't heard of Zig before, what is Zig and what's it doing? Zig is a systems programming language. Well, we do say it's a general purpose programming language, and it really is. You can program anything with it. What's the origin story of Zig? How did it get started? Andrew Kelly is the creator of the Zig programming language, and he wanted to write a digital audio workstation. I think he started with a higher level programming language, figured out pretty soon that garbage collection doesn't play well

with real time stuff. And more in general, higher level programming languages, they kind of do the opposite. They don't give you access to the full capabilities of the machine. They describe a space in which you're supposed to operate in and you're kind of not allowed to get out of that space. So then he went into lower level programming languages, so C and C++. But those have also their own sets of issues. C, for example, is famous for having issues with metaprogramming and C++ has a certain take on it likes its own complexity. So he didn't feel comfortable using either. And so he ended up making his own language.

You know, C is an old language, but it's also everywhere. I guess, what are some problems that Zig aims to fix there? Hey, folks, this is Alex. Today's episode is about Zig. Zig is in the news lately for a lot of things. You know, Bun, the new JavaScript runtime, is written in Zig. I spoke with Joran from Tiger Beetle, who they're writing all their stuff in Zig. It's part of this new wave of lower-level systems programming languages, right?

Like Go and Rust and now Zig that are trying to improve on languages of the past. So Zig aims to be a better C. This is a really interesting episode. I have Loris Crowe here. He's the VP of community at the Zig Software Foundation. He walks me through, you know, why Zigg? How is it sort of improving on C, where it's being used, as well as just his rise to VP of community, which I thought was a really interesting story on how he got there and just, you know, following your passion and sharing what you're learning and things like that. So I hope you enjoy this episode. If you have any

questions, comments, guests that you want, anything like that, feel free to reach out to me or to Sean Faulkner. And with that, let's get to the episode. Loris, welcome to guests that you want, anything like that, feel free to reach out to me or to Sean Faulkner. And with that, let's get to the episode. Loris, welcome to the show. Hey, thank you for having me, Alex. Yeah, so I'm excited to talk to you. You are VP of Community at the Zig Software Foundation. I've been hearing more about Zig. We had Joran from Tiger Beetle on. They're all written in Zig.

So a lot of interesting stuff going on there. For those that don't know much about you, can you just give a little bit of your background and what you do at Zig? Yeah, sure. So I'm a software engineer. I studied computer science, specialized in bioinformatics. Never done much in bioinformatics. And at some point I went into developer advocacy, which somehow led me to the Zig Software Foundation. So now I'm VP of Community and my main job is to basically, I guess the actual job description is increase the total amount of effort being spent on Zig.

And that's a variety of things, helping people do more with Zig, getting money for the Software Foundation, do communication work, all kinds of stuff. Yep, absolutely. Well, you must be doing a good job because everyone I talk to about Zig just talks about how welcoming the community is.

I think that's part Andrew, but I think you've done a great job around that as well. So I'm excited to hear a little bit more about your path and about the ZSF generally. But I guess maybe just give us an overview of what is Zig? If I haven't heard of Zig before, what is Zig and what's it doing? Yeah, so Zig is a systems programming language. Well, we do say it's a general purpose programming language, and it really is. You can program anything with it. People sometimes see general purpose and they think,

oh, it's just marketing boilerplate. No, no, we actually mean it. The idea is you have a computer, you can use Zig. You have a tiny embedded device, you can use Zig. You have a GPU, you can use Zig. Well, with some caveats, but some stuff is still work in progress. But that's kind of the idea. But it is a low-level programming language. So you do many on memory management, you have full control over what the hardware is giving you.

That's kind of the idea. The idea is that what the machine is capable of doing, you should be able to make it do by programming it in Zig. So yeah, that's, I would say, the main point of Zig. Yep, absolutely. And I love, as I was doing research on it, just some of the, I don't know, claims or different things like that. But you hear Zig being called a better C, or Andrew called it C, but with the problems

fixed, or even saying Zig is intended to replace C. I think those are ambitious goals and really cool to see. I guess, what's the origin story of Zig? How did it get started? So the origin story is that Andrew is the creator, Andrew Kelly is the creator of the Zig programming language. And before that, he wanted to write a digital audio workstation. And the problem with audio is that it's real-time stuff. You need to be fast and you need to be there on time, otherwise you hear audio skipping.

So I think he started with a higher-level programming language, figured out pretty soon that garbage collection doesn't play well with real-time stuff. And more in general, higher-level programming languages, they kind of do the opposite. They don't give you access to the full capabilities of the machine. They describe a space in which you're supposed to operate in, and you're kind of not allowed to get out of that space. And for higher-level, you're talking like JavaScript, Python, like that?

Exactly, JavaScript, Python, that kind of stuff. I think he started with Go. I'm not 100% sure, but he also, I think, did try Go at some point. So then he went into lower-level programming languages, so C and C++. But those have also their own sets of issues. C, for example, is famous for having issues with metaprogramming and C++ has a certain take on it likes its own complexity, so he didn't feel comfortable

using either and so he ended up making his own language. And fast forward, that's where we are today. And this digital audio workstation, was this like a side project he was working on? Was this his full-time job? What was going on there? No, I think it was supposed to be a side project. And I think he never really went super far with it. It's not a project that you can find on his repo and try it out,

but I do think he plans to go back working on it once Ziggy is done. Yeah, well, man, those are some serious life goals to have a side project so good that I need to create a new programming language to replace C. You know, that's, that's pretty cool. Okay. So tell me maybe about, maybe let's start with the problems of C. You mentioned a little bit around metaprogramming, but like, where are, what are, what are some, you know, C's an old language, but it's also everywhere.

I guess, what are some problems that, that Zig aims to fix there? Ooh, okay. There's, there's a few. I won't give you the full list. Let me think of a few highlights. And first of all, just your background. So you said like dev advocacy at Redis and things like that. Were you a low-level systems programmer like C and C++? Were you doing high-level stuff?

What's your background? So, no, I was never a low-level programmer before doing Zig. The reason why I learned about Zig in the first place is because when I was at Redis Labs, at some point I needed to find a low-level programming language to develop modules for Redis. So the idea is that Redis is this data structure server, and you can implement your own custom data structures. But that requires, it's like it's a plugin system, you can find plenty out there. And I needed a low-level programming language and I first tried that with C,

pulled it off, but the experience wasn't great. And so since I needed to do communication, I needed to explain to other people how to do this, I was trying to find something that would be less problematic than C. And that's how I found Zig. Yeah. Wow. Very cool. Okay. So anyway, I diverted us there. What are some problems with C? I think there are like two big ones. You know what? Let's do three. Okay. So first big one,

metaprogramming. That one is easy. C macros are famous for being a, I don't know, a Pandora's box of potential issues that come from macros. They are confusing, they produce weird unintended side effects. They're also very limited, because if you try to use macros to do something like generics, it's not great. It's like search and replace in your text files, doesn't work good. Okay, and just for clarity, macros, these are like, I mean, it's like search and replace in your text files. It doesn't work good. Okay. And just for clarity, macros, it's like code that alters your code. Is that right? It generates some other stuff? Exactly. But the problem is that it's code that alters your code

in a textual manner. So it doesn't understand text structure. It only understands text replacement. You know how SQL queries used to have this problem of query injection where people, since you concatenate things together, if you don't think about it adversarially, people could put into your query stuff that you didn't expect them to be able to. Now, with macros it's not exactly as adversarial, but

sometimes people use your macro as a function and there are surprising side effects when the macro is not well engineered. Yeah, that's interesting. And that macro just gets expanded or operated on at compile time, basically? Is that what's going on? Exactly.

Yeah, they have a pre-processing step. So you take a C file that has macros in it, give it to the compiler, So you take a C file that has macros in it, give it to the compiler, the compiler produces a C file where the macros have been resolved, basically, in the final text. Okay, okay. So issue number one is metaprogramming

specifically around macros. And the problem with that is that it comes, that's expressivity. You want to express something in language. In C, you're very limited, so you start trying to use macros. Macros give you superpowers, but man, do they come at a cost. So in Zig, we don't have any kind of metaprogramming that allows you to manipulate the source code as text.

We don't have macros. What we do have is comtime. And comtime is the idea that you write normal Z code and that code executes a compile time. And while you are at compile time, you can also pass around types that you are not able to pass around at run time. So at compile time, you can also pass around as values also types. So for example, generics in Zig is not like a special syntax with the diamond brackets, you know what people are used to from C++,

Java, I don't know, TypeScript, right? Diamond brackets everywhere specify types using its own tiny dialect, its own tiny sub-language. In Zig, a generic type is a function that takes in a type and outputs a new type. So an array list is of type T is a function that takes T as input and returns a new type.

Okay, sounds good. And so comp time, yeah, that was something that kept coming up. Is this mostly like a performance improvement? Is it more just like a complexity improvement for me, the developer, as I'm sort of writing out my code, this is less complex? What is comp time giving me

as a developer? Comp time gives you I think it gives you, I think, it gives you not just performance. Performance certainly is part of it because obviously when something can be done once at compile time instead of being done multiple times at runtime, that's a performance improvement. That's good. You want it. But it also helps with, for example,

expressing certain constraints. So types and generics. What's good about generics is that, like in other languages, so I'm thinking about it more broadly, but generics allows you, for example, to specify type constraints, right? You say, oh yes, this thing accepts a thing

that has, I don't know, can be of multiple types, but these types, they need to be able to do that thing. They can be added together, for example, or something like this. With Comptime you can express constraints that I think are either impossible or extremely hard to express with the diamond bracket syntax. Let me give you just one example. Which, by the way, relates also back to Redis. I was writing a Redis client, and I wanted my client to be able to recognize certain commands.

And Redis commands are, think of them as text queries. So you send get, set, and these are just text that you're sending over. And they are case insensitive. So lowercase get, uppercase get, it's the same command. So I needed a case insensitive equals function in my client because I wanted to recognize these commands when the user was providing them as a string. Now, it turns out that I had to do this case insensitive equality check.

But it turns out that since I'm hard coding one of the two operands in my code, like I'm checking if the user provided command is get. So that get string literal is hard coded in my program and I'm providing it. And it turns out that if you make sure to type that one in uppercase, then you can simplify the comparison logic just a little bit. Like you can remove one branch. Now, the problem is that only works if the provided string literal is uppercase, right?

If somebody provides a lowercase string literal or like a uppercase G, lowercase E, uppercase T or something weird, then it doesn't work anymore. Now, here's the idea. How can you say in diamond brackets, yeah, this first argument needs to be an uppercase string? It's hard. I'm sure there can be weird ways of pulling it off, but it's complicated. In Zinc, here's what you do. You take the string, you do a for loop character by character, and you check that it's uppercase. It's between uppercase A and uppercase Z. And if it's not, then there's a built-in called compile error and you output a compile error where you say, this function

expects the first argument to be all uppercase. But it was not. Wow, okay. That's pretty interesting. I can see how that would be powerful in a lot of ways. Yeah, just simplifying some of that stuff down. So every time people call that function, the Ruck custom logic runs and they get a good compile error. So you can imagine that you can do this

with any kind of arbitrary logic, because you can use normal ZIG code, for anything that is compile-time known. Yeah, okay. Okay, that's very interesting. Okay, so that's one sort of problem with C that you're talking about, that Zig works on. What are the other two that you were thinking of? Yeah. So, yeah, one is metaprogramming.

Another one, a huge one, is building and cross-compilation. Building C projects and C++ projects is a nightmare. I think there's a lot of developers out there, including me, in the past, where you give them a C project, they look at the C project and they have no idea how to build it. And it's not their fault, because some C projects are easy to build, so to be fair, not all C projects, but some, actually the majority in my opinion, are a nightmare to build. Because the build systems have their own implicit things that you're supposed to just know.

And those are platform dependent. So you come from Windows, you have no idea how to build something for Linux because the idioms and customs are completely different. And then also the tools are different because like Make works on Linux, but it doesn't work on Windows. So for Windows, somebody has to provide the batch file. Oh, but then can I build this in PowerShell? So yeah, just put in also a PS1 file and then somebody else doesn't like Make, they want CMake. And there's like there's this soup of build files and build systems

and it's a mess. And so how does Zig fix this? They have one way to build, one builder, one compound for them all? Yeah, Zig has its own build system. They can build Zig projects and C projects and C++ projects. It's a very general purpose build system. That part is amazing to me. So if I have just a C project that's been lying around forever,

I could just pull in Z and build that without having the make or bat files or anything like that? Yeah, you can get rid of all those dependencies. But the idea is that it's not just because of the build system. Ziggy is also doing other things that build systems usually don't do to be able to support that use case. Such as? Making sure to set up everything correctly in the build pipeline because it's a compiler as well, so it knows how to build everything.

But more importantly, it has its own C libraries for all different targets. So not only it's more reliable and fewer dependencies, but it allows you to do, for example, okay, I'm on Linux, but please build this program for Windows. And you get a Windows executable that works, and vice versa. That's another thing that usually C projects don't do. for Windows and you get a Windows executable that works and vice versa. That's another thing that usually C projects don't do.

Like sometimes C projects, well, oftentimes they can be built on multiple, on different platforms, but they are usually, okay, you build for the platform that you're on and that can be Mac, that can be Linux, but you can't do from Linux to Mac. Well, for Zig, that's a core use case. Okay. And how does sort of, I guess, the time of compilation compare for if I'm using Zig versus if I'm using, you know, Make with my C project? Are those similar?

Like, what does that sort of look like? Yeah, those are pretty much the same because the ZigBee system isn't particularly heavy, and they both have caching. So with Make, you also get caching, but you also get that from the ZigBee system. Actually, to be precise, it's not just the ZigBee system. You get caching from Zig also if you just use it as a C compiler. So there's the zigcc subcommand. That one does caching.

If you just use Vanilla Clang and you try to compile with Vanilla Clang, that one does no caching at all, ever. Yeah. And this is just like fascinating to me. Like why was it a new project, a new language altogether that was able to build essentially a better compiler for C,

if I'm understanding? Like why couldn't C do that themselves? Yeah, that's a good question. I think I have an answer that, let's just say it's my opinion, because I don't have any hard evidence to present to convince everybody in a clear-cut way. But in my opinion, the problem is that there is a lot of things in software engineering

that we look from the outside and think is a solved problem. Or something that is too complicated for us to tackle. Or something we shouldn't touch. And so if we want to do something in that space, our usual approach is to build more abstractions on top. You could argue that CMake is an example of that. I might be misremembering, but I think that CMake is an example of that. I might be misremembering, but I think that CMake outputs make files. So it's a pile of abstractions.

So the Zig philosophy instead, it starts from Andrew. Andrew's philosophy, which then became the Zig philosophy, is, well, no, you don't just stop there. You peel the layers, you look what's underneath, and then if something needs to be changed, then you do change it. And the reality is that, and this is where I started really understanding this, is that there are a lot of things out there that we think are perfect that actually are really not. And even if you're not a super expert in that field,

you can do serious improvement if you want to. You have to put in some effort, but things are not perfect. I can give you an example of that if you want. Yeah, absolutely. I've been working recently on a static website generator. Part of my work, a lot of my work, is dealing with content that ends up on websites. Writing blog posts, Zig Showtime has its own website, I run the official Zig website, I also run a conference called Software

You Can Love, and I have to make a website for my conference. And so I use static generators a lot. And I started with a framework, like a JavaScript framework, then switched to Hugo, which is the Go one, which I liked, but there are some things that I wanted to improve. So one day I beat the bullet and said, okay, you know what? I'm making my own static website generator.

And while I was doing that, I decided to also make my own templating language. So instead of using Moustache or Jinja or one of the usual ones, I said, you know what? No, I want to have my own take on this. And as I was doing that, and I looked at Markdown parsers and this stuff, which are C libraries, which are the ones that everybody uses, like 3-seater, for example. Once you get to that level, you realize that it's not like they're bad. Absolutely not. 3-seater is great. But a lot of people, for example, 3-seater has this thing

which is very interesting. It's really good at rebuilding the tree incrementally from changes. So that's why people use 3-seater in editors. But people use 3-seater also for situations where you're not building an editor. And so that ability to rebuild the AST partially, it's completely wasted. But there are trade-offs that have been made

to allow for that use case. So the perfect parser for a static website generator is probably not three-seater. So I basically went down this path where I'm realizing that, yes, even parsers for very common data formats could probably use some better libraries for the use case that I'm interested in. Yep. Wow, that's amazing.

Yeah, that's super cool. Okay, so how is your static site generator coming along? It's complete enough to be able to build my personal blog. And that's where it is for now. But I'm working on it. Yeah. I love that idea, though. I think you're right. Like, you know, it doesn't take, you know, a huge team or anything like that. I feel like an individual person that just like has a clear vision of like, hey, this is where this could be improved and a little bit of of just energy and desire to go after that.

I think it's amazing how much better things can be. And you won't necessarily nail everything first try or really make something that is strictly superior than everything that was done before. Not really. But even the very good solutions out there are not good for everything. And the problem is that what stops people, really,

in my opinion, well, when it comes to C and C++, I guess what stops them is also the build system, those projects. But once you're able to peel that back, to remove that block here, which Z helps you remove, then it's really just a matter of not believing that this stuff is impossible for you to touch.

Like as a high level programmer for most of my past life, I know the feeling of, yeah, well, I'm a Python programmer. There is no way I'm ever going to be able to open this C dependency and make change its behavior. But instead, you can. You can. Yeah.

Yeah. That's very true. I'm surprised even at the people who are JavaScript, Python developers that maybe use a third party package in Python or JavaScript and won't go source diving into that to figure out something. It's just like, why isn't this working? And won't go figure that out on GitHub. I feel like that's how I learned to program. That's how I learned to read code,

was reading through Django, or the actual source code, and trying to figure out how it works. Same, same, yeah. That was my same experience. In university, my classes were doing Java, which I didn't really like, so I did everything in Python. And at the same time, I learned Django.

And yeah, the Django codebase also for me was the first codebase. The Java standard library, not a great experience. But the Django codebase, that one was pretty good. It was a great mix of really good documentation, a good Stack Overflow community, but also this code base that you could actually dig into and figure out what's going on and how you do some of this stuff. It was super helpful for me.

That's funny that it worked for you as well. Okay, so in terms of being a C and C++ compiler, was that part of the very early vision of Zig or is that something down the road, you're like, oh, this has become such a hassle for us? How did that get pulled into Zig? The idea is that Zig started, depending on LLVM, I think since the beginning.

For people who don't know what LLVM does precisely, the idea is that when you want to make a compiler and you want your compiler to work on multiple platforms, and multiple platforms means different CPUs, so ARM versus x86-64, for example, and also multiple OSes, then you need to write code. You need to be able to output the correct instructions

for the specific OS plus CPU combo. And that's a lot of work. So a while ago, some people started this project called LVM where basically they are making one, let's call it a compiler backend. One compiler backend, let's say to rule them all. Basically, they take care of the instruction selection and optimization passes

and you just output something called LLVM bitcode which is like an intermediate representation that their backend understands but you then do the work once. So you kind of target LLVM and then LLVM is able to output for specific platforms. So Zig was using that from the start. And LVM is also the library, the backend,

that powers Clang, the Z compiler. So the idea is, first of all, Zig needs to have a lot of interoperability features with C because it's a systems programming language. And the reality is that you can't forget about C because OSs are written in C or in any case they expose a C ABI, dynamic linking, it's a C thing-ish. So in any case, you need to have all these bits and pieces figured out in your language if you want to be a

low-level programming language. And then Zig was already bundling LVM, so adding Clang, it's like just a tiny step. I think that LVM is like 40 megabytes or something. Well, no, maybe less. In any case, it's a chunky piece of data, and adding all of Clang on top of it, it's not that much work. So what Zig does basically, so Zig is able to compile C and C++, but it does so through Clang, by bundling Clang. Now it's not just exposing to you a rebranded Clang, it's doing more than that, but the idea is that it's a solid C and C++ compiler because it behaves exactly like Clang because it has the exact Clang code in it that does the building.

So what Zig does on top is caching defaults, providing libc stubs, like the libc for the target system. So, for example, one reason why a C compiler out of the box from Linux cannot target Windows is because it doesn't have a copy of the libc that Windows uses, the header files. And Zig bundles all of that in. But it's not just a matter of copy-pasting those files. There's some work that needs to be done to deduplicate, compress, make sense of things, etc.

So that's what Zig basically does on top of Clang to be its own C compiler. Gotcha. And so you mentioned how Zig can compile these C and C++ projects, but a Zig project can also use C and C++ libraries within it, is that correct? Yes, a Zig project can link against C static libraries, C dynamic libraries. You can also link against C++, but ZIG cannot use, for example,

C++ types and functions directly. Because the problem with C++ is that it doesn't have a well-defined ABI. So if you compile a C library, you have a C library compiled to a static library, compiled maybe with GCC, and then you link it against other code, be it ZIG or another C code, to make an application that you then compile with Clang that works. But with C++, everything

has to be the same compiler, otherwise it doesn't work. And then you have other problems because C++ has a runtime. It has exceptions, and so you have to have something that is able to run exceptions. So in general, C++ is more hostile to interoperability than C. Gotcha. And this may be my ignorance here,

but does the typical ZIG project use a lot of C libraries as part of it? Or are they mostly like pure Zig? Or like, what does that sort of look like? I would say it's a mix. So for example, my static website generator right now is using TreeSeater and the Cmark markdown parser, which I do plan eventually to maybe removing if I decide to

bite the bullet and write my own parsers for Markdown and HTML. But the point is that the choice is very easy to make. The C dependency, like three-seater for example, it's one package that I depend on and I just need to swap it out with a different package with my implementation and everything will work transparently. Gotcha. Okay. swap it out with a different package with my implementation and everything will work transparently. Gotcha.

Okay. Okay, so going way back to the sort of three problems of C that we talked about, one was metaprogramming, we talked about comp time, we talked about compilation of C and C++ projects. What's the third big area where Zig improves on C? So the third big area, in my opinion, which Zip improves over C, is more about the details of programming when it comes to safety and, let's say, the day-to-day. So, for example, in C, there's a lot of things

that are undefined behavior. And for people who are not familiar with undefined behavior, it's basically when you write something in the code that the spec says that you should not write in the code. And when you do that, then the consequences are generally a program crash, but by the name undefined behavior means that actually it's undefined how the program will behave at that point. Undefined behavior is a thing that you can't fully remove from Turing-complete programming languages that want to give you full access to the hardware. So it's a thing that has to be there. Just to give you one example. One thing that is considered undefined behavior is

accessing memory that you haven't allocated yourself. It's like reading out of bounds. So you have an array of 10 elements, you try to read the 11th element. That's bad. And that's undefined behavior. But at the same time, the machine can do that. And there are cases where something of this kind is still correct, even though you can't express that, even though you haven't expressed that in a safe way in the program. So the line between that being correct, something correct to do or not,

is not something that is self-containing in the program. It's like the result of your program running in a system that behaves in a certain way, etc. Just to give you an example, talking about accessing memory that you haven't allocated yourself. I think Windows gives you performance counters for the CPU as an address, as a piece of memory that is made available to every program. And that address is not allocated by you. It's given to you by the OS. So on Windows that's this one special address that you can read into and that's perfectly fine to do that on Windows.

Yeah. So in C it's very easy to trigger undefined behavior though. C is very, also the type system for for example, doesn't have generics. And so it's very, how can I say, the type system is not very strong. So a lot of people oftentimes cast stuff, pointers to numbers, back to pointers,

do pointer arithmetic, and do all kinds of unsafe things all over the place that in Zig you can still do, but it's not the preferred way. It's not the natural way. And doing those kinds of things requires you using operators that make it very clear that you're doing something fishy. It's not like just an ad. Yeah, okay.

And that was one thing as I was reading more about Zig, is it looks like it really favors explicitness, explicit over implicit, and that sort of thing like making it clear on what's happening on on these sorts of things, even if that's more, you know, takes longer to write out or whatever, but at least just like being more explicit about what's happening. Is that is that correct? Yeah, that is absolutely correct. So for example, on pointers, you normally don't do arithmetic.

Another thing to see, for example, does is when you have an array in C, an array becomes a pointer to a not defined number of items. You have to then have a second variable that is like your counter that tells you how many items are going to be there after that pointer. And these are two separate values. And if you get it wrong, then you will do a readout of bounds. In Zig, we favor instead slices. A slice is a pointer that also bundles a length. And so every time you talk about pointers in normal Zig code, you always know what the length is, and you don't get it wrong by mistake very often. As another example.

There's a long list of things that Zig has improved from that perspective. And also, when you do get a crash, in Zig you also get a stack trace, while in C, oftentimes, you get seg fault. Actually, segmentation fault. You get an error message or a bad status code, it exits, and that's all you get. Don't know what happened.

Yeah, exactly. And to be fair, you can get that behavior also from C, you just don't get it out of the box. And there are reasons why you might want to strip from the executable the information necessary to produce error traces, sorry, stack traces and similar things. Oh, also errors. In C, errors usually are like integers, like a function returns an integer and the integer

tells you if the function succeeded or not. And sometimes you have the like zero is success and then every other number is a failure. Some other times it's the opposite. Some other times it's a Boolean because also C likes to use integers as Booleans. And when it's Booleans, then zero is false. That means failure. And one is true and that means success.

I mean, in Z instead, we have a dedicated error type. In an error type, you can't ignore errors, and they have dedicated syntax to handling errors in a better way. Yeah, that's interesting. Over the last, I would say, maybe decade or so, we've seen some innovation is this, uh, area of like systems languages, right?

We, we have go, we have rust, we have zig. I think go is a little more clear on maybe when you shouldn't use it, given that as a garbage collector and things like that. But, but especially with like rust and zig,

where do you see people reaching for one or the other? Is it mostly personal preference or are there types of projects that are much better suited for, for zig or for rust? Is it mostly personal preference, or are there types of projects that are much better suited for Zig or for Rust? Yeah. So I don't think I can give you a full answer about which type of projects are better served by which language. I do think that this might be the case,

but I myself am not really a proficient Rust programmer. I've written maybe a hundred lines of Rust, not more than that. So based on that, I cannot comment on projects specifically. But what I can tell you is that at the very least, I think it's true that there are different types of developers. For example, you have people who like C++ and who can make it work for them. They use all the features that C++ offers and that's how they make software.

For example, let me think of a positive example. A positive example of this is, in my opinion, Andreas Kling with Serenity OS and the Ladybird browser. And they use C++. Well, now they are transitioning to their own language, but their own language is still influenced by C++. It compiles to C++. And in their case, they make it work for them, and that's great.

But if you give C++ to me, I'm not going to be effective with it because I don't like it. I find it overcomplicated. I find it a bit foot-garny. And also, I've seen all kinds of, in my opinion, bad software behavior that I do believe is caused by people doing what is common, what is idiomatic with the language, but in a way that causes bad behavior.

One example. So I gave you a positive example. I'll give you a negative example. Visual Studio code takes, sorry, no, without code, just Visual Studio. Visual Studio takes forever to load, takes forever to do anything, and then it takes forever to close.

And what I think is the reason why it takes forever to close is because it's using destructors. Like every object in C++ has a constructor and a destructor. Well, not every object, but most do. You can define them and people do use those features. And so when you click the X on Visual Studio, it starts running those destructors object by object by object by object instead of just exiting, which is like save the files and exit. That's the correct behavior. it starts running those destructors object by object by object by object instead of just exiting, which is like save the files and exit. That's the correct behavior, but that's not how it behaves.

And ultimately, in my opinion, the outcome is wrong. That's not how it should work. So on the other hand, you have people instead who don't use C++ and who instead prefer C. One example of that is like the Linux kernel. The Linux kernel has been C only for a long time. They never wanted to allow C++. And so for these second type of people, in my opinion, Zig can be a better tool than Rust.

Because Rust is not C++, but it's another language that has destructors and complexity and complex features and all kinds of stuff. Do you think we'll ever see Zig in the Linux kernel? Or are they going to just stay hard and fast on that? I don't know. They are starting to get Rust into the kernel,

although I believe it's only for drivers right now, so it's not the main thing. Still, not to downplay the kernel, although I believe it's only for drivers right now, so it's not the main thing. Still, not to downplay the achievement, I honestly have no idea. If I have to be honest, what I'm most interested in, in the case of ZIG, what I'm hoping for is... So, first of all, obviously being in the Linux kernel would be amazing, but ultimately it's up to them. In my opinion, what I would consider the symbol of success of Zig would be getting into complex hardware, like digital cameras, for example. Those are embedded devices that have extreme needs in terms of efficiency, performance.

They have budgets over everything available in memory and they have to do hard stuff, hard real-time stuff. And I think that they could definitely use Zig, in my opinion. Yeah, very cool. Are there any projects you're excited about that are written in Zig? Tiger Beetle is the big one that comes to mind for me, a financial database designed for speed and correctness at very high levels. Any other ones you're pretty excited about?

Yeah, there's a couple. These are community projects that are big. They're not financially backed by any venture capital or similar, but they're still pretty big. One is MicroZig. MicroZig is basically a hardware abstraction layer for embedded devices written in Zig. So the idea is you have a microcontroller, like you have an Arduino or Raspberry Pi, and you just type in the model and you automatically get types that describe the pin layout correctly,

etc. etc. That's one. Because I do think that the embedded space really needs... For example, the embedded space... People do use C++, for example, in embedded space, but C++ for embedded is very different than normal C++. It's C++ that usually doesn't have exceptions stirred on, doesn't use destructors. It's a very different language. While that would not be the case with Zig.

With Zig you would be using just normal Zig. There's nothing that you turn off. Because Zig doesn't even assume that you always have a heap available to you. Even the standard library, data structures, like basic ones, like an ArrayList or a HashMap, they always ask you to provide an allocator because there's no assumption that you always have a heap.

So sometimes you don't have a heap, and so if you want to have an ArrayList, then fine, but then you provide an allocator that takes the memory from the stack, for example. I thought that was super interesting. Again, just that explicitness of just always requiring an allocator and things like that. That's pretty interesting. And I know some of the stuff...

Yeah, that helps a lot with portability also when it comes to WebAssembly. WebAssembly, in some ways, you can imagine it as a weird and meta device. It's not really, but it has those constraints. Like in WebAssembly, you have a chunk of memory that's given to you at project when the module is loaded. And that's what you start with. You don't have a real heap. And so, for example, in Zig, there is no special stuff being done for WebAssembly. You're just passing a WebAssembly allocator.

It wasn't an allocator. Anyway, here's another project. Mac Engine. Mac Engine is, think of it as the Godot of Zig. But with a higher focus on performance, in my opinion, than Godot, and also a lot of focus on cross-compilation and portability. So the idea is that you write your game in Mac Engine, and then not only you can target different platforms, which is important for games, but you can also cross-compile, which is key, in my opinion,

because oftentimes it's tough for game makers to support multiple platforms. Okay, that's very cool. I saw you at a post, this was October 22, talking about Zig being self-hosted. First of all, can you just tell me what it means that Zig is now self-hosted? So what it means is that originally Zig had what we call the stage one compiler, and the stage one compiler was written in C++. And that meant that if you wanted to, I don't know, do any change to Zig,

like add a new operator, fix a bug in the compiler, change anything, you had to write C++ code. Problem is, we are writing Zig kind of also because we don't want to write C++ code. Yeah, so there always was an interest in writing the Zig compiler in Zig. The problem is, well, you can do it. And for a while, at some point,

people started writing the Zig compiler in Zig. And that was the stage two compiler. The problem is, well, okay, you have the Zig compiler written in Zig. But then how do you build it? Because the idea is that you need a Z compiler to build a Z compiler. So how do you get started? And that pulls in the bootstrap problem.

So long story short, now we are at a stage where we completely discontinued the C++ compiler. Now there's only the Z compiler and we have a fancy bootstrap process that involves WebAssembly to make sure that you can go from just having a C compiler

to getting up and running with a Zig compiler written in Zig. Wow, yep. And one thing I think is interesting, just looking back on that, you posted this 15 months ago now. You said, hey, this took two years to build, it slowed some momentum.

We sort of knew that it would, but there's going to be a lot of benefits going forward. So now looking back 15 months, are you like, hey, yeah, I'm grateful for having done that. I feel a little momentum growing there. I guess looking back at that, what are your thoughts on it now? Oh, no, no regrets at all. Absolutely worth it. For me personally, so I'm sure that all core contributors would agree that it's so much nicer to be able to write in Z than in C++. And you can watch also, there are some talks from Andrew where there's one specifically about data-oriented programming, where he

explains how certain optimizations that are currently in the Z compiler, and when I say optimizations, I mean not in terms of the generated code, but I'm talking about the compiler itself. So making the compile process be faster. A lot of us could use less memory, for example. A lot of those optimizations, he said that he would not feel comfortable even attempting is in plus plus because they would be huge sources of bugs because you wouldn't be able to express exactly what you want to express

and you wouldn't have tools to check, to catch when somebody makes a mistake. Like a contributor adds a piece of code that doesn't account for a certain thing, and then you get misbehavior instead of a compiler or a nice crash. Yep, absolutely. Okay, let's switch gears a little bit, slightly away from Zig, but I just want to hear a little bit more about how you got to be VP of Community at Zig. I think it's kind of interesting.

So again, you're working at Redis Labs as a dev advocate. Is that right? And then, so what was this initial module that you were creating for Redis that, I mean, was it doing something or was it mostly just showing people how to create modules or like what were you trying to do with a Redis module? Yeah, so, well, the full origin story

of even how I got hired at Redis Labs is because I wrote a Redis module that I made available publicly, like I open sourced it. And it was a module that implemented a data structure called Cuckoo Filters. So it's like Bloom Filters, but with some twists. And it's like a probabilistic data structure. It's one of those fancy things that makes sense to do with things like Redis.

So I implemented that. Somebody at Redis Labs noticed and they told me to apply to speak at RedisConf. So I did. I spoke at RedisConf and one thing led to another and I got hired into the job. From there, yeah, I needed to explain to people how to do more modules, more in general. Also because I think at that time the modules API was being extended

and also Redis Labs was pushing out their own custom modules with their own take on data structures, etc. So I wanted to explain to people. And at the time, the choices were like plain C, like Redis. Technically, I guess C++, but I wasn't the right person for that. Then Rust or Zig. And when I discovered Zig, I immediately read the description of how ComTime works. And that clicked for me immediately. And so that really convinced me to try Zig out and prioritize it over Rust, even though Rust at the time was already more further ahead,

more popular. So I guess it would have been the better choice in many ways. But really, my brain was immediately captured by Comtime. So I started using it, started interacting with the community, and I started getting more involved with the language. And I started writing blog posts. At the time, I think I wrote a couple blog posts explaining to people how to use the ComTime.

At that point, the pandemic happened, and the lockdowns started. And if you're a developer advocate, lockdowns are not good. Or more in general, if you're for marketing, lockdowns at the time were a nightmare because a lot of marketing branches were used to this idea of having in-person events happen all the time, having people on the ground go to events, set up a booth, give a talk, shake hands, and this was not happening anymore.

So all my managers were confused and didn't know how to move forward and at the same time, well, it's not like I knew necessarily how to move forward when it comes to marketing company-wise, but I knew that for my personal job, the obvious choice at that point was to start streaming. Do live coding, be more present online. Yeah, and then you started doing Zig Showtime, is this right? Yeah, exactly.

And that's when I started doing Zig Showtime. So Zig Showtime was basically just me contacting people to come and give a talk on Twitch and show the project that they were working on in Zig or explain a systems programming related concept. But the idea was that at the time, too many people were running these types of events on Zoom. So it's not a huge difference, but the idea is that they were around on Zoom like an in-person meetup, except everybody's like, the webcam on. But it feels like an extra meeting. What I did instead was, think of it as a show. So people open Twitch, they don't share their own webcam because they are the audience. And there's a stage, conceptually speaking.

And they look at the stage, and for example, the show had an opening sequence with an animation and music playing and I was acting as the host. And those things did make a difference enough that people just wanted to watch it. And one thing led to another, Andrew started the non-profit foundation, like the Zig Software Foundation and when he started the Zig Foundation, he basically asked me if I wanted to come on and join him and I accepted.

That's very cool and I love it because it shows like there aren't rules. You don't have to work your way up step by step inside some internal organization to get to the top. You are VP of Community at the Zig Software Foundation. What happened is you were super interested in this community. You started building stuff on it. You started writing on it. You started streaming on it.

And all of a sudden, now you're VP of community. If you get passionate about something, just put it out there. It's kind of fun how far that passion can go with that sort of thing. Yeah, absolutely. It's a lot of these paths in life. Nobody knows that they even exist, right? You yourself don't know, but like, it's not just that what people point out as one possible path. Oh, that's, that's the exhaustive, exhaustive list of all the things, the all,

the all and only things that I can do. No, there's more out there which are unknown and you can stumble upon them if you're lucky and do try. Yep. What is it like working for, you know, a nonprofit, the Zig Software Foundation, as compared to, you know, working for an enterprise like Redis Labs? I would say that the two main differences is that the Zig Software Foundation is a tiny organization and it's extremely lean.

So, for example, there's a lot of things like we don't have HR. And I don't mean that necessarily in like, oh, yeah, I don't have to deal with HR. I do think that sometimes having people whose job is to create services within the organization for other people can be good. But we are a tiny reality, so we don't have that. So something to keep in mind. But on the other hand, that also means that we are extremely efficient

with our money. And so even though this is something to keep in mind, I do like what we're doing. Last year we spent 92% of our money to pay developers. So the overhead is very minimal. The other big difference is that, and that comes also from my title, I guess, I have a lot more decision on power when it comes to what I do from the day to day. And that comes, you know, great power comes with great responsibility

because at Redis Labs, I would occasionally get certain assignments, things that I had to do that I kind of disagreed with. And, you know, maybe it wasn't right all of the time, but at least in a few situations, I was definitely being asked to do the wrong thing, in my opinion. While at the Zist of our nation, this doesn't happen anymore.

The flip side, though, is that now, if anybody is wrong, that's me directly, right? Now I'm the bottleneck. Yeah, very cool. So you said 92% going straight to developers. Are those mostly developers that work full-time for Zig? Is it some sort of contracting situation? How many people work full-time for Zig and do you have any contractors?

Right now, it's four people working full-time and a handful of people building hours, let's say more or less part-time. It varies month by month. We would love to grow more, to hire more people full-time. The problem is that we depend mainly on donations. So depending on the amount of donations that we get, that decides how many people we can hire full-time.

And what do those donations look like? Are they a lot of small donations from just developers that love Zig? Are there a lot of companies that sponsor ZSF? What does that look like? It's a mix. It's also intentionally a mix, because we want our income to not be tied to one giant sponsor who on paper might be technically not in charge

of everything, but if there's one actor that owns all the money, then of course they are in charge, at least of certain things. So for us, balance is important. And right now what we are getting, I think it's more or less 60% donations from individuals through GitHub sponsors and Avery and others. We're a 501c3 nonprofit foundation, so you can find the ZSoft Foundation listed on almost every charity donor program.

So we get money from different platforms. And then the remaining 40% is more or less coming from companies either who are already investing in Zig. So for example, Tiger Beetle donates to Zig. BAN also donates to Zig. Or also companies who don't use Zig, or at least not as much as Tiger Beetle, but who still are interested in our mission and want to support us.

Oh man, I totally forgot that Bun was written in Zig as well. That's awesome. Definitely the talk of the JavaScript ecosystem right now. It's been a good year for Zig in that sense. So we're recording this at the end of January. Just speaking on funding and things like that, you all just announced donor bounties. Can you tell us a little bit about donor bounties

and how those work for the ZSF? Yeah, so Zig as an open source project is definitely not unique, but it is particular in the sense that there is a nonprofit foundation behind it. And there's a lot of projects out there who don't have any financial structure behind them. And at the same time, there's also a lot of contributor activity. And so given the situation in which we are in, we had in the past not exactly positive experiences with feature bounties. Meaning somebody, like a company,

who would like for Zig to have a certain feature be developed and so who was willing to put money to make that happen. The reason why we didn't have a great experience was because if you make a bounty where basically you're offering money for something to be coded with a deadline, there's the problem also that there's an implicit competition. Multiple people will raise to implement that thing because only the first one is the one who gets the money. So that was a problem for us

because we don't want people to do duplicated work where only the first one wins. And also you can bet that the first solution is not going to be the most polished one. So there were quite a few issues with that approach. So we originally had this rejection of this idea of feature bounties and we said, please, just don't do that, we don't like this. But after thinking about it for a while, we kind of

said, okay, let's try to tweak this idea, the design of a feature bounty, so that we can make it work. Because the reality, so our initial take was, you shouldn't do feature bounties, because if you have money to spend and you want for something to happen, you could just have a contract.

Like you start a private contract with somebody who is potentially a Z-contributor, so somebody who has already shown that they can contribute Z-code, and you have this private contract with them where you pay them a certain amount of money to make the thing happen within a certain time frame. The problem is that if you do a contract, it's more cumbersome for the person offering the money, but it's more fair for the person doing

the work. And it prevents the duplicated effort type of thing. So that was our preferred thing. But we said, okay, maybe people don't want to do this because understandably it's more work. So how could we tweak bounties to make this happen? And what we ended up with is this idea where it's a feature bounty, but the money doesn't go to the individual completing the work first,

but instead it goes to the non-profit foundation, which then eventually will basically end up paying contributors because that's the business that we're in, that's what we do. But then at this point, there is no competition. There's only cooperation because the money goes to the cause that hopefully people care about.

But it's not a zero-sum game anymore for participants to the bounty. And so that's what a donor bounty is. Yep, I love it. It aligns incentives in a slightly nicer way where you're still getting prioritization of certain features that are important to big- time customers that are willing to pay for it, but without, um, the racing aspect and the duplicated effort aspect and just a little

bit more sort of, um, streamlined process and collaborative process. Yeah. So I think that's, that's pretty interesting. Like great, good luck on that. I hope that that works. Is that something that you had, uh, you know, you're announcing it today, is that something you sort of developed this with some enterprises behind the scenes? Or are you like, hey, here's our idea on how to do this going forward, and you'll see how it works? So we developed this as a response, not exactly to an enterprise, but to an individual supporter, long-time supporter of the ZSoftware Foundation who was interested in doing something like this

for a feature of Zig, but who contacted us privately. And when they did that, that was even just a few weeks before we had all the issues with feature bounties. So my point is that they were very polite and asked that in private but we didn't know how to make that happen right away and we had just had the bad experience while we were evaluating that.

So we wanted to basically say, you know what, what we were discussing with this individual in private made sense to us but we wanted to basically say, you know what, what we were discussing with this individual in private made sense to us, but we wanted to formalize it as something that is just not a feature bounty, because otherwise it would have seemed maybe a little bit inconsistent to say, oh, you guys cannot do this, but this guy's fine. Yeah, very cool. I like it. It's cool, and I hope that works out for you all. Yeah, so by the way, just to conclude the answer, the point is we have an open donor bounty right now.

So after announcing now this individual has offered to pay $4,000 to give Zig the ability to create DAFs devices. Have you ever heard that expression? A DAF device? No, I haven't. Yeah. So it's a funny thing. I discovered it also fairly recently. A DAF device is basically using a combination of while loops plus which statements to create something similar to loop unrolling. So loop unrolling is when you have a for loop, but instead of iterating eight times, you iterate twice,

but then you copy paste what you do in the loop body four times, for example. So basically you copy paste some of the for loop so that instead of doing the for loop eight times, you do it or n times, you do it only a fraction of those n times, but each loop you do more work. And the reason why that might make sense

is because sometimes that does produce more efficient code. As a very hand-wavy general way of thinking about it, imagine copying byte by byte something from one array to another array versus using SIMD instructions that copy larger chunks of data from one place to another. Sometimes when a loop is expressed in an unrolled fashion, so with the body copy-pasted multiple times, the compiler, the optimizer, recognizes that pattern more easily and can produce more optimized code.

DAF's devices are a fancy version of that, named after one guy who used to work at LucasArts, who discovered that in C at some point in the past. I don't remember when. Well, cool. Yeah, if you're interested, again, go check out that bounty or any other open bounties that are at the ZSF there. We're coming up on time, so I want to close with just some common questions that we started asking all of our guests. So six questions here, semi-rapid

fire, but we'll just see how it goes. If you could master one skill you don't have right now, what would it be? Reading from a teleprompter. It's very narrow, but if you're used to watching good YouTube channels, like I watch camera gear reviews, for example, they are very dense in information and they are very polished and very nice. The communication is very effective and mostly thanks to a teleprompter, but you need to learn how to read it while looking natural.

Interesting. So do they have pretty much their entire script written out? I think so. I don't know for sure for every single channel, but for example, one channel that I like a lot is Gerald Undone. He makes amazing year reviews and he does use a teleprompter all the time. Cool, that's a good one. Second question, what wastes the most time in your day? Wastes the most time in my day? Software updates.

Software updates. Man, when I need to update something, it's always a pain. And I hate auto-update more than anything. At least it's not failed C and C++ builds anymore. That doesn't waste the time in your day. Oh yeah, that's a good point. It truly is not. It used to be at some point, but now it's not. Yeah, there you go. Good to hear.

Okay, if you can invest in one company, that's not the company you work for, which is a non-profit. I do have a private company. So who would that be? I would probably invest in Tiger Beetle or one of the companies around Tiger Beetle because Tiger Beetle exists as a technical solution

at least partially in the water scope of Interledger which is this idea of having very cheap micropayments and micro not as in a couple bucks micro as in fractions of a cent and I think that would enable a content creator economy that doesn't exist today that I do think should exist. Yeah, I am bullish on some of the things that they're going to do, whether that's in gaming or just other types of very small payments.

I think they're going to open up some new worlds in terms of what's possible there. Yep, so I like that one. What tool or technology could you not live without other than zig other than zig i knew i was gonna say i was gonna say other than zig but you got it okay um well given what i do obs obs has been fantastic like uh it's probably the most rock solid um open source project that I've ever used. It's not perfect, but man, is it good.

Yeah, very cool. Which person influenced you the most in your career? In my career, maybe Antires, Salvatore Sanfilippo, the creator of Redis. He had this idea of looking at writing code, not just as pure engineering, but also as a form of, let's say, art. He does use the word art. Of course, art is a very generic term. You need to understand his particular take on the term. But yeah, I do think that that's a perspective that

we could all use more. Yeah, it's true. And Redis is just such a beautiful piece of technology and just so amazing and fascinating. So yeah, Antirace, that's a great answer. All right, last question. What is your probability that AI equals Doom for the human race? Very low. Because, well, first of all, we need to get to AGI.

I think we're not quite there yet. But I think we've been in the business, like humanity has been in the business of creating systems that it doesn't fully understand since the dawn of time. And it hasn't killed us yet. It could be AI, the one that finally seals the deal, but I don't think it will.

I think there are bigger things that might doom us all more quickly than AI. Yep, yep, I agree. We're pretty adaptable and creative as a species. So I feel pretty good about it as well. It's been fun sort of watching the debate on that over the last year as this rolls out. Loris, this has been great. I loved learning about Zig and just seeing what you're up to. And I think it's so cool what you're doing there.

And I think the innovative things you're doing at CSF. If people want to learn more about Zig, about you, where should people look for you? So, well, you can find me on Twitter slash X. I'm at Crolloris, C-R-O-L-O-R-I-S. Or you can search for my nickname, which is Christoph, K-R-I-S-T-O-F-F. And from there, you can find my personal blog. You can find me. There's the Z Showtime YouTube channel.

I live stream on Twitch also. I was going on Twitch also. I was going to ask that. Where did Christoph come from? Christoph is my mother's surname. So in Italy, it used to be in the past that you would only inherit your father's surname. This was changed fairly recently, like five years ago, maybe seven. Yeah, not that long ago. So I never was able to use it legally as my surname, but I like it a lot, the way it's written. So I just use it as my nickname.

Very cool. Well, Loris, thanks for coming on. We'll link your Twitter, ZigSotime, ZSF, all in the show notes. And yeah, for those of you listening, be sure to check out Zig and see what could be used in your next project. Loris, thanks for coming on.

Thank you very much, Alex.