CppCast - Zig

Episode Date: March 25, 2022

Andrew Kelley joins Rob and Jason. They first say Happy 25th Birthday to Visual Studio and discuss a tool for parsing GCC error logs. Then they talk to Andrew Kelley, the president of the Zig Software Foundation. He talks about the Zig language, upcoming changes to its build tooling, and how Zig can be used with C and C++. News Happy 25th birthday Visual Studio GCC Explorer: A utility for exploring GCC error logs GCC Explorer Divide & Conquer and Sets: The 114 C++ algorithms series C++ Best Practices Game Jam Links Zig Software Language Sponsors Use code JetBrainsForCppCast during checkout at JetBrains.com for a 25% discount

Episode 342 of CppCast with guest Andrew Kelly, recorded March 22nd, 2022. This episode of CppCast is sponsored by JetBrains. JetBrains has a range of C++ IDEs to help you avoid the typical pitfalls and headaches that are often associated with coding in C++. Exclusively for CppCast, JetBrains is offering a 25% discount for purchasing or renewing a yearly individual license on the C++ tool of your choice, C-Line, ReSharper, C++ happy birthday to Visual Studio. And we talk to Andrew Kelly from the Zig Software Foundation. Andrew talks to us about Zig and how it can be used with C and C++ developers by C++ developers.

I'm your host, Rob Irving, joined by my co-host, Jason Turner. Jason, how are you doing today? I'm all right. Rob, how are you doing? Doing all right. I don't think I have any news to share this morning. How about you? Well, we're going to talk about something in the news items in a moment, but otherwise, no. Well, at the top of our episode, I'd like to read a piece of feedback. We got this comment on Reddit from Greg CPP from last week's episode saying,

great interview, kind of ironic hearing Dave talk about how Boost Python has been replaced by PyBind11 when one of the authors of PyBind11 has just released Nanobind, a C++17 implementation of a Python binding library. Going on to suggest that we have the author of Nanobind on the show. That sounds awesome to me. Yeah, we should definitely try to reach out to him or her. And also saying I would be interested in hearing library authors discuss the value and cost of being part of Boost.

Is de-Boostification a trend? And if so, whether Boost seems like Boost serves its mission as an on-ramp to the standard C++ library in C++ 11 days, but since then, few libraries go through Boost before the standards committee. Yeah, I think we've probably made some comments on that sort of thing before. It doesn't seem like Boost has as much influence as it might have in the past, although certainly lots of great libraries still in Boost. I definitely have worked with clients that, you know, maybe I've mentioned this on the air, I'm not sure,

where, you know, if you've got Qt and Boost in a project, after so many years of managing all of those dependencies in your build chain, you start to think, okay, which one of these two can I get rid of? Because they're two fairly large dependency sets. And so we ended up doing the boost extract or whatever it's called, command line tool, to take out just the few chunks of boost that we want, which is part of the normal boost distribution. That's a thing to do. And so then we were able to limit it to exactly the pieces of boost that we want, which is part of the normal boost distribution. That's a thing to do. And so then we were able to limit it to exactly the pieces of boost that we needed for that project,

embed that into our stuff, and then move forward with just Qt as our main external dependency. It seems like that would be the better way of going anyway, to only use the parts of boost you're actually using. Yeah, and if you've got Conan or something, you can still only link to a couple of Conan libraries, but it's not quite the same thing. If you're not already using a couple of Boost libraries from Conan,

if you're not already using a package manager, then it gets more confusing and complicated. But just being able to extract a couple pieces, put them into your build processes can be handy, particularly for the header-only Barts boost. Well, we'd love to hear your thoughts about the show. You can always reach out to us on Facebook, Twitter, or email us at feedback at cppcast.com. And don't forget to leave us a review on iTunes or subscribe on YouTube. Joining us today is Andrew Kelly. Andrew is the president and lead developer of Zig Software Foundation.

When not working on Zig, he's out hiking with his fiance or playing a competitive 10-player arcade game. Andrew, welcome to the show. Hey, thanks for having me on. I'm sorry, 10-player arcade game? That sounds awfully specific without being specifically specific. Yeah, it's called Killer Queen. It's two teams, five versus five giant arcade cabinets, and it's a ton of fun if you get a chance to play it. So you're actually like at the same cabinets? That was kind of one of the design goals of the creators is that it actually brings people together outside their homes rather than, you know, people just playing games alone. Huh. I mean, it makes me think of like the old like gauntlet cabinets and stuff that would have four players,

but I think that's the most I've ever seen, personally. Yeah, it's a riot. I also must say, I think you're the first person with the title of president that we've ever actually had on our podcast. I could be wrong, but I think that might be right. I think we've had a couple of CEOs of small corporations, but I don't know if we've ever actually had someone with the title of president. Oh, yeah. That comes from the fact that the Software Foundation is a non-profit.

So we have a board with a president, treasurer, secretary, rather than, you know, CEO, all that stuff. Okay. Well, welcome. Thank you. All right, Andrew. Well, we got a couple news articles to discuss. Feel free to comment on any of these and I'll start talking more about Zig, okay? Sounds great. All right, so this first one is a post on the Visual Studio blog announcing that they had a birthday recently. Happy 25th birthday to Visual Studio. If I'd been thinking a little bit further ahead, I would have gone upstairs and I would have grabbed my Visual Studio 97 CDs that I happen to still own. I did not know that that was actually

the first version of Visual Studio. But yes, that was something that I purchased as part of my computer science software kit or whatever for my sophomore year at Virginia Tech or the second half of freshman year. I definitely don't have anything that early, but I definitely started using Visual Studio in the very early 2000s.

Yeah, definitely come along a long way. What C++ standard are they up to these days? Last I checked, it was, I don't know, pretty old. Visual Studio fully supports, yeah, fully supports 2020 now, as much as any C++ 20, as much as any compiler does. And I think Visual Studio has a couple of features from C++ 23 rolled in now as well, as much as any C++20, as much as any compiler does. And I think Visual Studio has a couple of features from C++23 rolled in now as well.

That's great. Yeah, I saw it on Twitter. I almost added it to the news, but they released another article, I think, talking about how they implemented deducing this already in Visual Studio. And you can try it out in Compiler Explorer, I believe. I did not know that. Now I'll tell you something that will truly blow your mind. Clang is the furthest behind in implementing C++20 now.

Wow, that actually is pretty interesting, yeah. So what is it, MSVC, GCC, then Clang? Is that what we're thinking of? Effectively, yeah, but everyone still has bugs in their C++20, and certainly in their 23 features that they're starting to roll out. So, you know, there will be people who will say, well, sure, Visual Studio has C++20 and certainly in their 23 features that they're starting to roll out. So, you know, there will be people who will say, well, sure, Visual Studio has C++20 support, but it's got bugs in these three places. Well, yeah, it does.

Everyone's got bugs, yeah. Okay, next thing we have is a video on YouTube, and this is a utility for exploring GCC error logs. And I think a listener shared this with us on Twitter. It's a pretty short video, and there's a link in the description to the actual website where you can go and post a long template metaprogramming error log that you get from GCC, and it'll help you try to find the actual error, which is pretty cool. I forgot to actually click on the video, and I just played

with the website without any instruction as to what I was supposed to do with it. Okay, hold on. I got to ask you about that, though. So you played with the website. Did you just happen to have an insane error message lying around to paste in there? At that exact moment, I was actually prototyping some code and it wasn't an insane error message, but it was 50 lines or so that I was able to paste in there. And it did some color highlighting and some stuff and then generated links which theoretically would have opened up my project in CLion if I had CLion up on that system and whatever.

Yeah, I think they also have support here for opening up VS Code. Yeah. But you found it helpful, Jason, with your 50 line error? No, not at that particular. I'm like, okay, I could see how this could be interesting with a larger or more insane error. And I totally forgot to click on YouTube. That was pretty neat. It seems like the kind of thing to me where once you see, it was one of those recursive template errors, right? And once you paste it through the system, it looks like a stack trace

after that. Oh, that's cool. After I saw that, I thought, once you see it, you just think, well, this is obviously what GCC should do after you instead of what it does. It's just so clearly the correct way to display the information. I wonder, now the video you said is, you're talking about recursive template instantiations. Did they demonstrate like a constexpr error? Oh, I don't know what exactly was the error. I don't think it was constexpr related. Okay. No, probably not because debugging a failure at constexpr time can be very difficult. And if you get enough of a trace from GCC that you could paste it in there and then actually almost get like a stack trace

of what was actually happening in your code then that could be really helpful too. Yeah, I feel like it was kind of like that but not constexpr. It was just when you just have a lot of template parameters and it's like, well this one was instantiated from this one from this one, from this one. That was what it turned into, the stack trace.

Awesome. It seemed pretty useful. It seemed like that's what Gs should do out of the box. I feel like they need a version for Visual Studio's errors too, because I usually find them actually harder to decipher than GCCs. Maybe just because I spend more time with GCC and Clang, but anyhow. All right. Next, we have a blog post from Simon Toth,

and this is Divide and Conquer and Sets, the 114 C++ Algorithm Series. In this post, I think he was going over, I did read through this, some of the bound algorithms. Definitely seems like a useful set of posts for digging into all the C++ algorithms, you know, in a little more detail. I've skimmed through this one, and I flipped back through the first two in the series and skimmed through those. I didn't realize when I linked to this that I was linking to the third post,

and that's the third of N as far as I can tell. Yeah. When I read the title, I thought, is he saying there's going to be 114 of these posts? But I think that he's referring to the number of algorithms, not the number of posts. I think there's definitely like, there's something to be said about the process of learning here. Like, even if you don't find this particular set of articles interesting, the idea that the author is going through exhaustively and documenting and creating

examples for each of these things, when the author's done with exhaustively and documenting and creating examples for each of these things, when the author's done with this, they're going to know the algorithms better than 99% of people out there. With that 1% being Sean Parent. And then Jason, you had one more thing here, which is a GitHub repo you put together.

What's this? Yes, so I am decided to host the first ever C++ Best Practices Game Jam. I'm going to do this probably April 1st is when I'm going to announce the topic and things are going to go live. I've done some interesting twists to this. First of all, to be a valid submission in my Game Jam, it has to compile on three platforms with three different compilers with no warnings. And it must execute with address sanitizer and undefined behavior sanitizer enabled. Oh, wow. That's a fun idea.

But I give you a template starter project. So all you have to do is go on GitHub, say use this template, and you're out the door running with something that already does that. So if anything breaks, you did it. That's neat. What abstraction did you use for the media for sound and audio? That is what makes it truly unique, is that I am using FTX UI. Are you familiar with that? I've never even heard of that. Rob is going to get in a minute here. Yeah. This is all in the terminal. Okay. Yes, it's a terminal GUI. Oh, no, you're a monster. But the template that you start from has an example of a turn-based game engine already in it. Well, turn-based game already in it. And that's like 50 lines of code. And I just this morning proven that you can do a normal game loop also with it.

So the template will have both in it and you can choose which route you want to go. Yeah, I hope you're looking forward to playing 100 NetHack clones. Well, hopefully the theme that I have not yet announced will reduce it so it's not just NetHack clones. Don't get me wrong, I love NetHack. I'd play NetHack clone. I've never actually played NetHack, I guess I should say. That's fair. It's not for everyone.

I feel like I probably should someday, right? Like, I mean, it's been a part of geek culture for what, like 40 years or something crazy? Yeah, I feel like it's worth it for the geek culture. It's also delightful. You know, there's just some old, fun, a lot of code in there that you can kind of have fun with. And there's content, you know, it's good. Cool.

Yeah, I'll have to try it at some point. So yeah, that's the gist of it. We'll link to it and I'll make an official announcement. And so that's one Friday after this goes live. Yeah, so just over a week until April 1st, right? And then I'm going to give people that whole weekend, the middle week, and the next weekend to wrap it up. The topic will be announced on Friday,

and submissions are due on Monday. So you'll have a full week with two weekends. So I figured that probably will work for everyone's schedule in some way. And I'm doing Friday announcement instead of Saturday morning, because I wanted to make sure Oceana has the opportunity to go hit the ground running on Saturday morning. All right. So Andrew, for listeners who have not heard of Zig, could you start off by describing the programming language? Sure. Zig is a general purpose programming language

and tool chain for maintaining robust, optimal, and reusable software. You say that like you've practiced it before. The big bold letters on the homepage, which I thought carefully about. So if I want to change the tagline, I got to change it everywhere, right? Don't repeat yourself. So that's the tagline. What is the elevator pitch version, I guess, if you're trying to sell it to the CEO on the way up to his office, her office? The elevator pitch is, it's so simple that if you two can already read ZIG code right now, if you looked at ZIG code, you could just read it. You could familiarize yourself with the official language reference in a day and be done reading documentation forever for the language. And then you'll be immediately extremely productive.

The foot guns are just missing. You just forget that the foot guns are there until you switch back to your other favorite language. Then you remember that they're there. It's just this feeling of incredible productivity that you're going to have combined with the software that you end up writing going real fast. Obviously we'll go into a lot more detail about what makes Zig different than C++

and how it works together with C++. But I guess, do you want to tell us a little bit more about what first inspired you to start up the Zig project? Yeah, before I was working on Zig, I was actually working on a digital audio workstation in C++. And that's the hardest thing I've ever worked on. I plan on picking it up again someday. But after I've leveled up

a little bit more as a programmer, compiler is a piece of cake compared to a digital audio workstation. But anyway, that was my actual project. I don't know, I just had some life stuff happen and I was just kind of like feeling down a little bit. I don't know, I just had some life stuff happen and I was just kind of feeling down a little bit. I was trying to stay focused, but I gave myself a little break

just to kind of chill out and to try a new project. I just always had these ideas kicking around in my head. After you're a programmer for so long, you start to develop opinions about your primary tool that you're using as a programmer. So finally, I got my shovel, broke ground. And then I just felt like there was always a clear path forward. And then here we are six years later, and it's like I'm not alone.

I find the genesis interesting because a friend, who I will not name names at the moment, just decided, I think I'm going to try slapping together a video editor real quick because I hate all the ones that are out there. I'm like, you know, that's going to be hard. Yeah. If you thought an audio workstation was hard,

I'm guessing video is approximately at least as hard. Yeah, it's kind of a similar problem with more dimensions. Yeah, I mean, I guess you could argue that the video track is just another track that you're editing. But anyhow, it's still, it's going to be a hard job. Yeah, digital signal processing.

The hard part, too, is that not only is it a monumental programming task, which necessitates multi-threaded programming and all of the foot guns that that brings, not only does it have the hard real-time requirements where that sounds playing out of the speakers. If you don't fill it up in time, you get garbage. Not only does it have that, but then it also brings in digital signal processing from math. That's like linear algebra, all the other digital signal processing stuff.

I've failed three Coursera classes trying to learn digital signal processing. I'm going to do it, but it's hard. Okay, so is Zig currently to the state where you could go and write your audio processor today in Zig? It is, but it'll be so much even better suited in a couple months after we finally launch the self-hosted compiler that has been under construction for a while.

Okay, so you've got GUI components and threading constructs and all of those things are possible? Well, those two things specifically, well, sure, threading we got in the standard library, that's no problem. GUI components, see, this is another thing where Digital Audio Workstation brings in extra complications. You can't just go grab Qt for DAWs because God knows what they're doing in their functions. And you're in the real-time path of the hardware. You can't just go grab Qt for DAWs because God knows what they're doing in their functions. And you're in the real-time path of the hardware. You can't call malloc inside of the audio callback. And everyone calls malloc.

You can't trust anyone. So you got to write your own GUI. I just, as you were saying that, recalled, I have right beside me, which will be completely unseeable. Oh, Juice, yeah. Juice swag. Yeah, yeah, yeah. Well, that's why Juice did the gooey, because they knew they couldn't trust anyone else's not to call Malak, you know?

Wow. So then you said Zig just removes the foot guns and you forget they're there. How did you remove the threading foot guns? Oh, that's a good question, because I didn't. That's not a solved problem yet. Oh. Okay. Those are all still there. Wonder if the discussion for just a moment to bring you words from our sponsor.

C-Line is a smart cross-platform IDE for C and C++ by JetBrains. It understands all the tricky parts of modern C++ and integrates with essential tools from the C++ ecosystem, like CMake, Clang tools, unit testing frameworks, sanitizers, profilers, Doxygen, and many others. CLion runs its code analysis to detect unused and unreachable code, dangling pointers,

missing typecasts, no matching function overloads, and many other issues. They're detected instantly as you type and can be fixed with a touch of a button while the IDE correctly handles the changes throughout the project. No matter what you're involved in, embedded development, CUDA, or Qt, you'll find specialized support for it.

You can run debug your apps locally, remotely, or on a microcontroller, as well as benefit from the collaborative development service. Download the trial version and learn more at jb.gg slash cppcast dash cline. Use the coupon code jetbrains for cppcast during checkout for a 25% discount off the price of a yearly individual license. Let's talk about kind of one of the main things that Zig advertises itself as being able to incrementally improve your C and C++ codebase by adding little bits of Zig. So how exactly does that work? The first thing you're going to do is you're going to swap out your build script from CMake to ZigBuild.

So you're going to remove your CMake dependency, add your Zig dependency. We've got a build system built into the language. So instead of CMake code, you write Zig code. That's a lot more mainstream of a language than the CMake language, so it's easier to understand the control flow and whatnot. It's still declarative. It gives you roughly the same APIs and everything like that. And then this will also work on Windows and macOS without Xcode installed. It'll work everywhere because

we bundle Clang in with Zig, seamlessly integrated. So it's not a separate binary, it's just the Zig binary. We ship lib C++, we ship lib C++ ABI, we ship C headers for every target with a custom kind of like way of not duplicating all the content. And then everything, we ship compiler RT, and then everything is lazily compiled from source for the target upon request. So by switching your build script over, you actually get cross-compilation

without any separately installed tools. You just say, pick a different target, and then it just works. Compiler RT gets compiled for that target. Lib C++ gets compiled for that target with special flags, depending on whether you enabled thread sanitizer or not. We do have thread sanitizer built in.

Okay. Oh, yeah, if you got cling, yeah. Yeah. That's kind of step one is your build system. You get some of these benefits from your build system. And then the thing is, like, oh, now you have Zig as a dependency, and you maybe need to write a new file,

you could write it in Zig instead of C or C++. Communicate over the C API like every language does. And then now you've got your hybrid project. So what does it actually look like to call a C function from Zig? Do you have to do an import statement or forward declare yourself or whatever? Pretty standard. Yeah, you have to put, you know, extern function and then the signature. We do have a translate C feature, which is pretty advanced. So even right in the language, you can call a C import built in and give it an H file. And it will auto translate that into all

that stuff. We even have a special pointer type for auto translated pointers that gives it different semantics so that your code can look the same as the, you know, the C or C++ code that you would expect to see that uses that H file. So you kind of have a choice, you know, you could go with the auto translated header and have your code look like the corresponding C++ code. Or you could pre-run that translation into a buffer, clean it up, clean up the type system to have more metadata, to kind of get rid of some of those foot guns, and then just save that file.

And if you have a really stable header file that's not changing all the time, that's probably going to help you not make bugs. Right. So it sounds like you're focused on, oh, I mean, that C is your calling convention, basically. Yeah. So if I wanted to share like a standard to bring the C type system into Z code.

So you're going to want to find a boundary where having a separate memory management philosophy is going to make sense. Okay. Yeah, I'm just trying to figure out where the boundary layer is here exactly. Everyone takes a different approach to this. I find it interesting because we were just talking to Dave Abrahams last week, right? And he said that the Swift compiler also fully embeds Clang for similar kinds of reasons. I actually did not know that. I had no idea either. Now I've learned that two compilers do this in two weeks, and I had no idea that anyone did it. At first, we just had Clang so that we could do the translate C functionality

because we used Clang to tell us about the abstract syntax tree of the C code in order to then translate it into these function signatures and types and things like this. And then I thought, well, we already depend on libclang for this. We could just export main,

just rename it to main2, and then call it, right? Yeah. The dependency is already there, so we're paying for it. Might as well exploit it. So you just said at the start of this that you soon will have a self-hosted ZIG compiler. Can you want to dig into that?

I would love to hear more about that. Yeah, we're actually starting to compete with LLVM directly. So we do have a self-hosted LLVM backend, which is ZIG code that interacts with the LLVM API and provides that lowering. We also have a few more backends. So we have a pure ZIG web assembly backend, x86, ARM, ARM64, and C as well.

And these do not depend on LLVM. It's 100% pure ZIG code all the way to the ground. So that's kind of like a longer term investment there. The main thing that we're doing is the same thing that D does, which is you have your debug builds, get LLVM out of the picture because that is not a fast compiler. So for your debug builds, you're focused on compilation speed. And it's just pedal-to-metal compiler speed,

runtime performance, not as important. We need to build a debug. We need to have the dwarf info or the PDB info in there and just compile it as fast as possible. And then for release builds, then we bring in LLVM and we say, okay, you're the one for this job. We know you can handle optimization.

Oh, interesting. That is, yeah. Because, I mean, writing a modern optimizing compiler is extraordinarily difficult. Yeah, and think about this for a second, too. So LLVM has labor. Like, I don't know if you've seen how active the project is, how many different developers are active at it from different big name companies. I mean, they really can just throw labor at the optimization problem. And it's roughly organized in such a way that it works. You add an optimization pass,

you don't have to coordinate too much with the other people. You just keep adding optimization passes. The pass manager runs them in some order. LLVM is a project that is designed to exploit, not in a bad way, just to utilize the ton amount of human labor going into all these optimizations. And it's pretty good at doing that. Like, it's good code. But if your goal is to compile fast,

you can't just throw labor at it. Actually, just like one or two people thinking very carefully from all the way from the top to the bottom, how can we make the compiler fast? It's going to be more effective than thousands of people on LLVM trying to add optimization passes. So we can beat LLVM at compilation speed. That's something a small team can do.

Right, but not for release build, you're saying. You can compilation speed, yes, not runtime performance. Not runtime performance. We can't compete with them. I mean, we can get 80% of the way there with 20% of the complication, but closing that last gap is not... It's the other 80%. Yeah, it's not going to happen. So what are we talking about? I don't know if you can even try to throw numbers around,

like a debug build of a large ZIG project versus a release build of a large ZIG product. How long does this take? Okay, I want to try and stay in the realm of real numbers here. Yes, that's difficult, I know, sorry. Yeah, the largest project I can talk about right now would just be the compiler itself. So with the old compiler, the slow one,

I'm waiting about 50 seconds for a rebuild. Based on my timings, the backend that we have ready, that's actually almost ready to ship, is the LLVM backend, So it's not the fast one yet. But even with that, the new compiler is about twice as fast, down to about 25 seconds for a similar size codebase. Okay, that's significant. That's not even it, right? That's the LLVM backend. Right.

In some other tests that are honestly a little sus, not really real world, so take this with a grain of salt. We're looking at about twice as fast as the DMD compiler, which is known as one of the fastest ones out there. The other thing I can tell you is that this is a new project. This is some groundbreaking engineering because we have a new compiler and a new linker. We're not depending on an existing linker. We're writing a new one from scratch that is tightly coupled, not loosely coupled, tightly coupled to the compiler. Normally you want loosely coupled, right? Because that's better design.

Right. Not if you want that little metal performance, then you're going to tightly couple it, right? So what we've done is we've made an incremental linker. And so we're going to actually parallelize the semantic analysis and the linking so that it happens at the same time. So there's no linking step. It's just function gets analyzed, function gets sent to the linker.

At the same time, the next function is being analyzed, and then that function gets sent to the linker. And all these things happen in debug builds. All these functions are independent. They go through an offset table for function calls, which means you can independently update them in the next compilation. In my earlier tests, we're looking at sub millisecond updates to individual functions if they don't drag in dependencies. Linker running is like a daemon process or something at this point, so that you can just like link live while typing, basically. I mean, we have we have a leave the compiler running flag,

which uses memory for the cache. The plan is also to serialize that to disk at some point. And right now, we need to do a lot more fuzz testing before that would be realistic to turn on by default. Wait, you just said leave the compiler running lag. So every time I what, like write to one of the files that the compiler knows about, it's going to just recompile and output another binary? Yeah, so check it out. You run it, it does the compilation. And now, let's say we're on Linux, so you have an ELF file. Now, the linker infrastructure, the compiler,

it knows where all the stuff is. It has pointers to where all the functions are, it knows how long they are, it knows how much extra padding it gave them so they can grow or shrink. Every function call goes through an offset table. The linker remembers all this information. And it also remembers front-end information. So it knows the last time that files are modified and stuff like that. It has like little checksums of each function's source code. So now let's say you go touch a couple files, and in your IDE, you hit the like rebuild button. Now this is going to send a message to the running compiler. It's alive from

the last compilation says, we're requesting an update. So then the compiler goes in and it says, okay, I noticed that three files are changed. I look at these, I noticed that within these three files, only these, you know, five functions are changed. Now I have a dependency graph, so I know that other functions are going to call these at compile time, so I have to go touch those. That's it. We end up with 50 functions or something that have to get analyzed again. Those all go

through the main pipeline, and then each function independently can be updated in the output file. We know where they all are. All the function calls are indirect. All we have to do is go into the ELF file in the output, change the function bodies to the new contents. We already left some padding so they can grow. If they grow too much, that's fine.

We just move them somewhere else. And then we have to go update a couple more things. Make sure all the debug info is correct. Make sure all the line numbers are correct. And then that's it. We're done. If you had a million line code base, but you only touched a couple functions, you only had to wait for a few things to recompile.

So can this go to the next step and work in like an edit and continue kind of way that like Visual Studio supports and developers like that kind of thing? You could just jump in and start contributing right away because you get it. Yeah, we have a hot code swapping prototype for Elf and for Jacob just did it for Macho right now too. So that's also coming. Yeah. That process, like you just said, it's 90% of the way to the hot code swapping feature. It's almost the same problem. Yeah. I don't know if you can tell, but I'm really excited because I've been working on this for so long and it's finally about to see the light of day. That is very exciting, just thinking about lots of random things.

Now, I'm curious, because you just said Elf and Mach, but is Windows supported for your compiler? That one's lagging behind, just in terms of developer effort, but it's on there. It'll happen. You just need to do the work. And I also kind of want to take a couple steps back, because I feel like when I first look at Zig, I kind of made the assumption that it compiled to C and then compiled C, but that sounds completely false.

You're using the LLVM backend, but you did say you have a C backend if I really wanted that. So let me be clear. As it stands right now, it's March 22nd, 2022. And the compiler that everyone is using is written in C++ and it uses LLVM. That's it.

That is the zig everyone knows. The stuff that we've been talking about is the new thing. Haven't shipped it yet, or rather it's behind a flag. Soft shipped. And that one we have a bunch of different backends that you can choose from depending on which target you pick or which flags you select and there's reasonable defaults. That one has a C backend.

Okay. In addition to other backends. In addition to its own home role, x86 and whatever. Yeah. Do you have a release date in mind for this work that you are so very excited about? I do. It's the 0.10 release, which I believe I gave it the date of, I think I gave it May 10th, if I remember correctly.

That's a tight squeeze, but I think we can pull it off. Well, then the other thing that we haven't really talked about at all is you said you're doing this full-time. And we covered when Andreas Kling managed to go to full-time development on Serenity OS, which I'm always just fascinated by what seems to be a relatively small open source project able to fund one or more full-time developers on it. And I'm just kind of curious, what was this process like? How did you go from normal job to now I work full-time

on my own personal hobby project? Well, it took long time, and there was never an immediate change. It was always gradual. So I started this project six years ago. It was open source 100% of the time. The first Hello World, Read Me commit was on GitHub. And obviously no one is paying attention, right? Why would you pay attention to a nobody doing nothing? But then I just kept working at it over time. I saw some of these

other people doing like the Patreon model. And I just was fantasizing and dreaming about the idea of getting paid to do this the whole time. Seemed like difficult to pull off, but I wanted it to happen. You know, I threw up a Patreon page and just kept working on it. And just so, so slowly, I really want to emphasize how gradually this happened. People started donating. That's it. I mean, it took six years. And, you know, at some point, I just did the math on a spreadsheet. And I thought, if I quit my job, then my savings go down. But then they start going back up again after a couple years, they don't hit zero. So that's assuming support continues to increase over time at the rate that it had been increasing.

Exactly. Yeah, exactly. Sorry, I left a step out there. Okay, just making sure. Yeah. That's how the math works out. So yeah, that happened. GitHub Sponsors has been helpful because they don't take a 12% cut like Patreon does.

Don't get me started ranting about that. And then anyway, finally, so I had enough to survive myself, but all these people were donating to me personally, and I wanted to be more accountable. I know that sounds weird, but I wanted to give a gift of accountability back as kind of like a thank you. So then I started the Zig Software Foundation, which is a 501c3, non-profit,

official legal entity, which has a mission statement that's copied, basically plagiarized from the Python Software Foundation mission statement. Why break what's not broken, right? Python's great. Are mission statements open source? How does that work exactly?

And are you the only one working on this full-time, or are there other developers working on Zigg as part of the foundation? Two more. So we have Loris Groh from Milan, Italy, and he is the self-titled VP of Community. He is excellent. That's an important role. It is, but he also takes on a lot more.

We're a very small group of people. So we all have to do more, more than one job. There's a great job bringing in money, talking to companies, that sort of thing. So he is worth his weight in gold, as they say. There's also Jakub Konka from Poland, over in Warsaw. Yeah, he's pretty stressed out right now. Yes, I imagine. He's also amazing. So he's a full-time engineer. He wrote the Macho Linker from scratch. Didn't know anything about linking before he started.

And he ended up figuring out how to do all the code signing stuff on the new M1s. He just did the hot code swapping prototype for that stuff. And he's been working on the native x86-64 code generation backend. He's been doing awesome work. I can't believe he started working for Microsoft, but he was contributing to Zig in his free time. I can't remember who offered who the job

or what, but anyway, we basically poached him for Microsoft. That's pretty crazy. Yeah. He was working there for like a month and they did not understand this man's potential. Like, they were giving him bullshit jobs to do. Oh, okay. We'll probably let that fly. Probably let that fly. But anyway, so now he's working at Zig,

and he's doing these just incredible feats of engineering, like, repeatedly. Like, I don't know what they were thinking with this guy. I don't want to spend too long talking about this, but we did mention Ukraine last week. And I think it's worth noting because we've had so many Polish guests on this show. It looks like the war is getting awfully close

to Poland's border right now. And from the numbers that I saw, Poland has taken in an order of magnitude more refugees than their surrounding neighbors which is just you know shout out to all them i don't it's crazy yeah it's hard to watch because if you looked out on the street and you saw someone getting beat up you'd go out the door and you'd go help them. That's how you resolve your feeling that something's wrong. But what do we do? I don't know. I know the situation will change drastically if Poland gets directly involved because they are party to several treaties, which will drastically change the situation. But I'm not an expert on these

things by any means. Same. I'm going to try not to make comments that I'm not qualified to make. Yeah. That's the hard part. Yeah. Let's back up a little bit. You said that, you know, the two of us as C++ developers could learn

Zig in a day. How does the syntax of Zig feel to a C++ developer? How does it look different? What's unique about it? Can you give us a little

detail? Yeah, I'd say there's probably less syntax going on. It's going to look a lot like C2, I think. It is context-free, so some of that stuff is fixed. Like, you have to use a keyword to make a function type, and you have to use a keyword to declare a variable. And that just makes it so that the parser

doesn't need to know any information about what types things are. We don't get the most vexing parse kind of nonsense or whatever. Yeah, that whole thing. So that changes it a little in very predictable ways. Other than that, it should look really familiar to you. Okay.

One of the premises I've had on the syntax the whole time is, I want someone to look at pieces of ZIG code who has never tried to learn ZIG. They're a programmer, but they've never actually read ZIG documentation. And I want them to be able to understand all of the code. Wow, that's a pretty big goal. Do you have like generics or macros or templates or anything like that that helps you like stamp out code depending on parameter type? Yeah, so semantically, it's going to work very similar to C++. There's a different way to think about it. So instead of having a separate template parameters,

what we have is a way that you can mark any parameter as required to be comp time known, sorry, compile time known. But we actually have a new keyword, it's called comp time, it's for compile time. And it's a keyword that you just put in front of a parameter. And it means that at the call site, you get an error if that parameter is not compile time known and in the function body the parameter is guaranteed to be compile time known and in zig this has important effects because if expressions and switch expressions on compile time known conditions are conditional compilation the not taken branches are not analyzed. Not analyzed at all. Wow, okay, yeah. Yeah, so there's no preprocessor in Zig.

That's another thing I should mention. If there's no preprocessor, how do we do conditional compilation with if statements and switch statements? I have to think about that one. You couldn't just put anything in the unevaluated branch. How do you end an if statement? Is there a close brace?

What do you do? It's exactly the same syntax as C++. Okay, so if I had a close brace randomly in the else block, then that could still cause a compilation error. Yeah, it's not semantically analyzed. It's still going to be parsed. Okay, okay, okay. Yeah, so the types could be wrong. You might call a function that doesn't exist from a namespace, but it has to look, it has to parse correctly. Okay, so it sounds like any if statement on a comp time value

is implicitly a constexpr, if constexpr from C++ 17. I think so. That sounds about right. Yeah. Interesting. And now what about for loops or that kind of thing? Does the same kind of thing fall out? You need another keyword for that.

So if you want to inline a for loop, you can use the inline keyword on a for loop. So inline for. So what that's going to do is it requires the for condition to be compile time known. And then it makes the iterator, sorry, what do we call this? The element or the capture value of the for loop? It makes that compile time known. Okay, yes. I don't have a good word at the moment. So then you also were very careful to say you can corrected yourself from if statement to if expression. So we can actually in Zig use if as an expression,

like it can be assigned to a value or whatever the result of an if. Yeah, that's your ternary. There's no question mark, colon, yeah. That's similar in concept to Rust and a few other languages too, I believe. Yeah, it's pretty trendy for new languages to make more things expressions. Yeah, did that in my scripting language, mostly because my cousin who wrote that part of it chose to do it that way.

In a way, it's almost easier because in the compiler, the parser, if you treat everything as an expression, well, then you don't have to deal with multiple types of things. I feel like it's simpler both for the compiler and the programmer. Right. It's one of those, you know, just make everything kind of this uniform and uniformity is just easier to understand. Yeah. It's nice having switch as an expression, I will say. Right. Also, we solved the break

fall through thing. Also, the syntax is a little terser. So making switch a little terser and then also an expression is pretty handy. Switch is a really common control flow pattern in Zig. I always have a question about that. When languages say they solved the fall-through problem, sometimes the best way to express something

is to intentionally fall through. Is that possible? I have an accepted proposal to make that possible that's not implemented yet. Okay. That's actually a question I had. You talked a lot about these improvements are working for the Zig build system.

How about new features going into the Zig language? How is that managed? You know, do you allow people to suggest proposals that you then go implement? How does that work? It is a BDFL run project. I don't know what that means. Yeah, what is BDFL? Oh, that's the charming term for one person decides everything, but hopefully they're a good person. Benevolent dictator for life. Okay, right. I should have known that. I'm the VDFL. I try to encourage and let people kind of, you know, own different parts of the code base and bring their own

ownership sort of. But ultimately, I do reserve the right to make all the technical decisions, veto any decision, and enforce my vision, my singular vision, which is both a limitation of the project and a strength, having one unified vision. But you know, that's what Zig is. That's what you're getting. It earned the Marvel Cinematic Universe tens of billions of dollars to have one person with a single vision overseeing it. Is that right? Yeah, Kevin Feige or whatever his name was, was the one who oversaw all the MCU up to the end of the last movies or whatever. I don't know if he's still doing it or not. But yeah, that's why people argue that those movies are actually good and the DC movies aren't.

Just saying. Oh, is that what people argue? That is what people argue, yes. I see. Because there's one person seeing the vision through. Yeah. Well, it is what it is. Yeah.

You did say three people are full-time development. And including myself. Including yourself. That's pretty cool. I'm impressed. I'm really thankful. I love doing this full-time. I hope that people will agree that their donations are well spent

and that we're bringing something to the world. I sure love my life, so I'm thankful for it. I guess with that, with this project being able to support six people, or I'm sorry, three people, and you've been working on it for six years, do you have any idea of like how much production Zig code is out there? It's a funny question because we actually discourage people to use Zig in production yet. Oh, okay. At the stability level, it is. Okay. We've already had one person give a presentation on how they are using Zig in production.

And it was kind of funny. Their opening slide was just like my tweet saying, please don't use Zig in production. Nice. The title of this talk is how we're using Zig in production. So I don't actually know what the answer to that is, but the answer is not much

because most people are following the guidance and saying, okay, I'm going to hold off. The roadmap roughly looks like finish the self-hosted compiler, which is coming up in a couple months. Package manager, finish all the language proposals. There's not many. We're trying to keep it small.

We're trying to get done. The goal is to be done with the language. Stop changing it. Kind of like C. Interesting. Yeah. So that stabilizes standard library, tag 1.0, and then we're just coasting. We're just in maintenance mode. We're not going to try and change too much. Do you have a date set for when you think you'll get to 1.0? A rough date?

I have said in about two years for far too long. I don't think I'm going to stop saying that now. Okay. I don't know. How long did Rust have to get to 1.0? It took him like 15 years, right? I don't know.

We're only six in. Give us a few more time. In six more years. It is tough not wanting to change stuff. We don't want to get stuck with any bad decisions. And we also don't want to change anything. So I do want to be very careful before. I don't want to jump the gun on 1.0.

There will be a point where I'll say, look, we're not 1.0 yet. But I do think that it's okay to use it in production. Still reserving the right to change stuff. But I think we're mostly done. We'll get to that point first, but I think we're still years away from that point. Again, backtracking a little bit, but you mentioned before,

like if you had an IDE and you hit build, is there a recommended IDE for using with ZIG? I think VS Code is decent. I have an opinion, and actually this is a controversial opinion within the ZIG community, but... But your opinion's the one that matters. Well, I mean, it matters for the language specification.

But if my goal is to inspire people to do volunteer labor, then my opinion is not really important compared to what people want to do. Right. But my opinion about IDEs is that let's say that VS Code is the IDE we want to make work well with the Zig okay right now how it looks is there's an extension for a Zig syntax and there's a different extension for like a language server protocol

but you gotta like tell it where the path is to Zig and stuff I think that's all too much configuration my opinion is that there should be one extension to rule them all and the darkness bind them. And it should not ask you where Zig is, it should just go get it and install it for you and manage the version for you and do everything. And if it wants to make a language server,

then it should go fetch that code and it should compile it from source because Zig is a compiler and it can do that. We don't need to ask people where stuff is on their machine. Okay. That extension doesn't exist at the moment. Doesn't exist. But I do think the best,

some people are happy with VS Code plus a couple extensions. There's some guides you can look up on how to configure that all. And you do get some language server protocol features. You get syntax, you get all that stuff. But I'm kind of answering in a roundabout way because I do envision a nice

IDE experience. I know the experience I want, and that experience doesn't exist. So who knows, maybe that'll be a post 1.0 project that I pursue. I've been spending a lot of time lately thinking about how to make C++ more accessible, and if you

told me that ZIG, I can install VS Code on any platform and choose the ZIG extension, and that's all I have to do, and now I have the compiler, the package manager, the build system, I mean, that would be incredibly powerful. That would be incredibly powerful. That's what I want to do.

So maybe I'll make that happen at some point. Have to clone yourself or hire a fourth person or something. Cloning be incredibly powerful. That's what I want to do. So maybe I'll make that happen at some point. Have to clone yourself or hire a fourth person or something. Cloning myself, yeah. That's what you do. You invent a reverse aging formula and a time machine and go back in time. Do you think that you would be friends with your

clone self or would you get into fights? I could get awkward. I think it would probably get awkward I don't know if I would Andrew, if our listeners want to go check out Zig for themselves what should they do?

The homepage is pretty good, should get you started Awesome, well thank you so much for coming on the show today Hey, thanks for having me, a lot of thank you so much for coming on the show today. Hey, thanks for having me. A lot of fun. Thanks so much for listening in as we chat about C++. We'd love to hear what you think of the podcast. Please let us know if we're discussing the stuff you're interested in,

or if you have a suggestion for a topic, we'd love to hear about that too. You can email all your thoughts to feedback at cppcast.com. We'd also appreciate if you can like CppCast on Facebook and follow CppCast on Twitter. You can also follow me at Rob W. Irving and Jason at Lefticus on Twitter. We'd also like to thank all our patrons who help support the show through Patreon. If you'd like to support us on Patreon, you can do so at patreon.com slash cppcast. And of course, you can find all that info and the show notes on the podcast website at cppcast.com. Theme music for this episode is provided by podcastthemes.com.