This is has quickly turned into my favorite tech podcast. The only "issue" I have is that after every episode I feel like switching programming language 😋
@@elirane85 agree! Really appreciate how Kris probes into how things actually work, at a high enough level that I don't get bogged down with detail, but not so high that it's just buzzword soup.
I was blown away by the first episode I watched a few months ago. The depth of discussion and knowledge in this is just amazing. I wish there were more channels like this!
It just keeps getting better and better the more you use it. I was admittedly skeptic at first, I initially thought the syntax looked strange. Finally gave an honest effort to learn it, and absolutely love it now, and understand "why" some of the syntax exists, and the convenient things it allows for that just feel satisfying.
Great introduction. Dealing with a C/C++ library will never not seem daunting. Even being packaged by my distro won't guarantee that it will play nicely with my current project and the build system I'm using there. So it's usually down to building it myself and lord help me if I need to make any modifications there! Zig is making bold statements about being the last build system you'll ever need, so It's definitely on my radar in that regard. Can't wait to dive into this episode and see what Zig has to offer and where it's headed!
Well there are many cross-platform build-systems making that claim: CMake, meson, Scons, autotools, Jam, ... I mean, Zig provides some nicerr out-of-the box-cross compilation but otherwise it is not going to solve the problem of there being many different build systems that are all not really compatible with each other.
Another great interview! It was so valuable to learn how Zig prioritizes building in a sane way on the world of static/compiled programs. I'm dealing with Python + C dependency issues as I was listening to this... gotta give Zig another try.
I wanted to get excited for Zig but the experience is so different than the perspective shared here-one might not reasonably expect seamlessness but for entire concepts to only exist in github discussions is a bit beyond my tolerance.
I'm not a Zig developer in any way, but I like C and I write a lot of code in it. I think that the problem stated is not about C and the pain of building C, but mostly about the complexity that operating systems provide, which often limits one's ability to compile/build projects. The fact that some operating systems doesn't ship with a C compiler seems so stupid to me. However, I'm not stating that C is perfect, and I think that Zig could be a great successor, maybe even better than Rust.
I'm no build or C expert by any means but I believe you are right in the sense that the problem wasn't created by C. But it also wasn't solved by it and for decades people for lack of an alternative lived with it and programmed everything in C. But from todays perspective since all the powerful libraries are written in C, building those is the problem that a successful language needs to solve.
This came out at the perfect time. I am trying to compile an open source game project written in C and I've felt like I've been banging my head against a wall lol
Not another Zig episode...every time I hear about Zig, it makes me wanna give it a go. But I know I can't control myself, and I won't be able to sleep because I'll be wanting to spend my whole time learning, so I know I need to wait till I'm off work, and don't have other plans. Though on a more serious note, I did love listening to Loris last time, can't wait to listen this time too.
I LOVE the idea of Zig, comptime, and its C compilation superpowers... But I've bounced off it HARD twice as a Windows user because it requires workarounds on Windows for things that are fine on Linux and Mac, and that's at the learning stage -- examples in tutorials and documentation. I'm SO on-board when it's resolved those things.
Hi, Zig core team member here! Would you be able to explain what the things you hit were? If there are usability problems which potential Windows users hit so quickly, perhaps we should prioritize them, so it'd be great to hear what the big issues are.
@@mlugg5499 hey -- great work so far! Really very interested in Zig. I would need to dig back through what I was working on for details, and I'll try to do that and point to specific docs and guides soon, but my (faulty) memory says that it has to do with setting up a general allocator, and that I got a (very clear) error message saying that that manner of constructing an allocator was not available on Windows and it gave a specific alternative... which I then couldn't find documentation on and couldn't figure out by usage. My main worry was less that I couldn't build on Windows (happy to use Linux) and more that I might be developing on Linux in a way that wouldn't produce working binaries for Windows users. Grain of salt here -- I'm not a low-level dev and when I do dip my toes in those waters, it's with Rust, which is decidedly NOT low-level. 😂 I could be fundamentally misunderstanding how allocators are meant to work.
I'll also add that my experience with Bun (WSL only on Windows) might have colored my interpretation of the issues I was encountering. It feels like there is a general sense that Zig is not Windows-friendly, so some of that may be a marketing / documentation concern.
I highly recommend trying a Linux VM inside your host OS (Either Mac or Windows). I have been coding this way for a long time, it’s so useful when trying new things. For example, look for Mitchell Hashimoto’s setup for a NixOS VM.
I really enjoy this channel. The content is very informative. It has the relaxed feel of sitting on a couch with a cup of tee. You've got great guests. There is a lot of competency going around. Thank you for all the work you put into this!
Many people would agree that the Zig proyect is aiming to achieve great things in system's development, perhaps the most visionary. And many more would agree that 'echo' is a better for the Developer Voices entrance, the most humanly resounding software channel on Earth. Just sayin :)
Getting zig as a pip package is so freaking smart and is a really good idea to get more zig into people's environments while using zig's strongsuits and providing incredible value.
I should really try Zig some more, been using Odin for a while but the lack of cross platform compiling/linking and well the lack of some more niche platforms like Cortex M7 has driven me back to C 😅. Maybe Zig is the answer I've been looking for although the build system is still a huge mystery to me
both are cool odin seems to be lacking on the platforms front for now and it packs a package manager/build system (due to project philosophy) but from my usage it seems quite stable and rarely breaks across versions and if it does it's not much zig is cross platform, has a package manager/build system but it breaks very often, it's less mature and the LSP is not as good as Odin's because it relies too much on comptime (supposedly a better LSP will be shipped with the compiler once the language is more mature)
Do learn from existing build dot zig files in existing repos. The zig build documentation is as lacking as you would expect for an unreleased language that is still in flux. I only use zig build nowadays, it's so powerful.
I am still an amateur when it comes to the build-system, but still manage to stumble through what I need without much struggle. I am sure it gets more complicated with cross-compiling C libraries for exotic architectures, but the typical use-cases of of building/linking some libraries and importing some Zig modules is painless. For a reference point, it is far less complicated than using CMake if you are familiar with it, but very different.
I use MSVC most of the time, and I love it. The problem is, there's nothing like it on Linux, and this is a deal breaker for me. My experience with open source IDEs is painful. What will be available for zig?
I'm experiencing those compiling issues right now! I wanted to cross compile an SDL2 program using SDL_gfx to Windows and I can't get the SDL_gfx to compile. I'm thinking of replacing that functionality with my own implementation, love C but getting to compile things is definitely a challenge.
In summary, it seems that the 'magic' of Zig as a Multi-OS Build System is that it is creating *another* build environment, which from the viewpoint of a library developer is *just another* build environment that the developer has to support in addition to already supporting build environments which are direct competitors to the Zig's build environment. No?
About make, always look up what commands are used in the makefile: I have worked on a open-source java project with maven used for the build, and make used on top of it for build steps orchestration. Problems were that 1) I work on Windows so need to find and install a version (but that can be done, there are projects that builds make for windows, its just not very common, and I could just drop a linux VM or use WSL2 for building the java project), But the worst was 2) the lead dev that made the makefile is on macOS and made it full of macos specific commands everywhere. The thing would not even build on linux ... first time I had seen a cross platform project made non-cross platform on the dev side. Ultimately, I unlocked the situation for the other devs and myself by finding and provinding the system specific maven commands that were simply reconstructed and called by the orchestration makefile.
I don't get how can you run Windows or MacOS linker on Linux though even if you have it packaged since the linker itself is a windows/macos app not a linux app?
5:18 C programmers will instantly disagree with you No. i think using C libraries from python with pip is easier than trying to configure and build C libraries yourself. Especially if you write C on windows, where there is no system package manager, when you do not use Visual Studio, where the configure shell scripts don't run, where there is no standard location where C libraries should be installed to, where the MSVC compiler and linker live in weird directories and are not on path. Basically the only C libraries that are easy to integrate into your C project are header-only. Especially when you want to also build for weird targets e. g. WebAssembly and so on.
@@iatheman Well, that is only if you use 3rdparty non-header-only libraries, if you write everything yourself (like most good C programmers) it is a joyful experience.
By learning Zig you will learn C as well...both are 1:1 in terms of structure. I'm doing both actually at the moment it has been an amazing learning experience so far. Previously I wrote Python webapps and used a bit of Javascript for dataviz.
You really don't need it. But C is syntactically very simple. So you can learn the basics of C in a day. Afterwards it's business as usual: You google less and less over time and get faster, cleaner and more comfortable over time.
It depends on your own personal goals. If you want to learn Zig, no, you don’t need to learn C. But, if you want to be a systems/low level programmer you should. It will also improve your skills. C is not difficult to learn, there is a lot of misinformation and some gatekeeping about C’s learning curve. Like any language becoming an expert takes time, but the language is very small and can be learned in a few days.
Honestly the main reason I can’t get into Zig is its poorly-documented build system. Where are the definitions for the structs being used? How does the build system find dynamic libraries? Why does it seem to change every single time a new Zig release drops?
the build system is entirely part of the zig standard library, see lib/src/Build.zig, everything is defined in there, also the Learn section on the official Zig website has a build system guide
@30'xx: one thing that always made me hate python was, exactly, the need to have c compilers installed to build some dependency of a package. Folks, I hated it so much to the extent that I started carrying the whole pip cache on a USB disk so I could copy things over to some other system I needed to work on.@40:xx I'm still not satisfied that one must expect a system to compile a dependency. If a package has a wheel, it should be "binary self contained", otherwise, it feels like the wheel system's whole purpose is defeated.
I gave a talk titled "Deinventing The Wheel" (it's available on youtube) about the limits of wheels. If you can be confident it will work reliably, there's a lot to like about building software precisely for the exact set of instructions that your machine support.
They have couple of benefits, initial parsing in the compiler is easier to implement as well as formatters, linters and syntax highlighting, it’s more explicit making it easier to reason about the code as well making greping through code bases with regexes slightly easier.
@@UnidimensionalPropheticCatgirl That's the only reason I don't want to try Zig on Windows. All other new languages are in my bucket list. I am doing hobby projects in D, Nim, Odin, C3, Nelua. I stopped Zig after the first hello world program.
@@DeveloperVoices At least then you can write your config in JSON or whatever, then write a script to convert to yaml. The extra steps is the price of freedom.
Ah, I think I’d missed your point the first time around. You’re saying that the advantage of config file is you’ve got many reader implementations to choose from? That I’d have to agree with. You’re tied to one way of expressing the answer, but free to choose how that’s interpretted. 👍
This is has quickly turned into my favorite tech podcast. The only "issue" I have is that after every episode I feel like switching programming language 😋
Indeed! Interesting topics, knowledgeable guests, insightful questions and discussions, clean straightforward editing. It's an oasis.
@@elirane85 agree! Really appreciate how Kris probes into how things actually work, at a high enough level that I don't get bogged down with detail, but not so high that it's just buzzword soup.
lol 😂
Odin and zig are my short list right now. Unrelated, they were the last two interviews I saw
💯 same!
Very cool. Zig seems to keep expanding and doing more and more fundamental things. Who knows what it might do some day?
Kris, your channels are the opposite of tech-influencer memes. I always come away having learned something and with other things to read more about.
I was blown away by the first episode I watched a few months ago. The depth of discussion and knowledge in this is just amazing. I wish there were more channels like this!
Recently got into zig after seeing so much of it online, did the whole ray tracing in a weekend thing and I'm loving every bit of it.
It just keeps getting better and better the more you use it. I was admittedly skeptic at first, I initially thought the syntax looked strange. Finally gave an honest effort to learn it, and absolutely love it now, and understand "why" some of the syntax exists, and the convenient things it allows for that just feel satisfying.
Can’t get enough Zig! Thanks for the new episode 🎉
Great introduction. Dealing with a C/C++ library will never not seem daunting. Even being packaged by my distro won't guarantee that it will play nicely with my current project and the build system I'm using there. So it's usually down to building it myself and lord help me if I need to make any modifications there!
Zig is making bold statements about being the last build system you'll ever need, so It's definitely on my radar in that regard. Can't wait to dive into this episode and see what Zig has to offer and where it's headed!
Well there are many cross-platform build-systems making that claim: CMake, meson, Scons, autotools, Jam, ... I mean, Zig provides some nicerr out-of-the box-cross compilation but otherwise it is not going to solve the problem of there being many different build systems that are all not really compatible with each other.
Another great interview! It was so valuable to learn how Zig prioritizes building in a sane way on the world of static/compiled programs. I'm dealing with Python + C dependency issues as I was listening to this... gotta give Zig another try.
I wanted to get excited for Zig but the experience is so different than the perspective shared here-one might not reasonably expect seamlessness but for entire concepts to only exist in github discussions is a bit beyond my tolerance.
I'm not a Zig developer in any way, but I like C and I write a lot of code in it.
I think that the problem stated is not about C and the pain of building C, but mostly about the complexity that operating systems provide, which often limits one's ability to compile/build projects. The fact that some operating systems doesn't ship with a C compiler seems so stupid to me.
However, I'm not stating that C is perfect, and I think that Zig could be a great successor, maybe even better than Rust.
I'm no build or C expert by any means but I believe you are right in the sense that the problem wasn't created by C. But it also wasn't solved by it and for decades people for lack of an alternative lived with it and programmed everything in C.
But from todays perspective since all the powerful libraries are written in C, building those is the problem that a successful language needs to solve.
This came out at the perfect time. I am trying to compile an open source game project written in C and I've felt like I've been banging my head against a wall lol
Not another Zig episode...every time I hear about Zig, it makes me wanna give it a go. But I know I can't control myself, and I won't be able to sleep because I'll be wanting to spend my whole time learning, so I know I need to wait till I'm off work, and don't have other plans. Though on a more serious note, I did love listening to Loris last time, can't wait to listen this time too.
I LOVE the idea of Zig, comptime, and its C compilation superpowers... But I've bounced off it HARD twice as a Windows user because it requires workarounds on Windows for things that are fine on Linux and Mac, and that's at the learning stage -- examples in tutorials and documentation. I'm SO on-board when it's resolved those things.
Hi, Zig core team member here! Would you be able to explain what the things you hit were? If there are usability problems which potential Windows users hit so quickly, perhaps we should prioritize them, so it'd be great to hear what the big issues are.
@@mlugg5499 hey -- great work so far! Really very interested in Zig.
I would need to dig back through what I was working on for details, and I'll try to do that and point to specific docs and guides soon, but my (faulty) memory says that it has to do with setting up a general allocator, and that I got a (very clear) error message saying that that manner of constructing an allocator was not available on Windows and it gave a specific alternative... which I then couldn't find documentation on and couldn't figure out by usage.
My main worry was less that I couldn't build on Windows (happy to use Linux) and more that I might be developing on Linux in a way that wouldn't produce working binaries for Windows users.
Grain of salt here -- I'm not a low-level dev and when I do dip my toes in those waters, it's with Rust, which is decidedly NOT low-level. 😂 I could be fundamentally misunderstanding how allocators are meant to work.
I'll also add that my experience with Bun (WSL only on Windows) might have colored my interpretation of the issues I was encountering. It feels like there is a general sense that Zig is not Windows-friendly, so some of that may be a marketing / documentation concern.
Even on Linux it’s hard to get started with because the build system is so poorly documented.
I highly recommend trying a Linux VM inside your host OS (Either Mac or Windows). I have been coding this way for a long time, it’s so useful when trying new things. For example, look for Mitchell Hashimoto’s setup for a NixOS VM.
Loris is absolutely right about python democratizing access to C libraries.
And (surprisingly often) Fortran libraries.
I really enjoy this channel. The content is very informative. It has the relaxed feel of sitting on a couch with a cup of tee. You've got great guests. There is a lot of competency going around. Thank you for all the work you put into this!
Thanks Michael. I'm glad it's appreciated, and I'm pleased you're here. 🙂
Many people would agree that the Zig proyect is aiming to achieve great things in system's development, perhaps the most visionary. And many more would agree that 'echo' is a better for the Developer Voices entrance, the most humanly resounding software channel on Earth. Just sayin :)
great discussion, really relevant for not just zig but the process of building and shipping native projects in general
remember bun build using zig, that's why i love zig.
Such a fantastic watch.
omg stop. This makes me wanna learn Zig while I have Nix, Scheme, Lisp, Emacs, F#, C, Q#, Assembly and Clojure ongoing currently 💀💀
Haha, I have the same problem. 😅
Jajaja
Getting zig as a pip package is so freaking smart and is a really good idea to get more zig into people's environments while using zig's strongsuits and providing incredible value.
Step 3 is profit!
I should really try Zig some more, been using Odin for a while but the lack of cross platform compiling/linking and well the lack of some more niche platforms like Cortex M7 has driven me back to C 😅. Maybe Zig is the answer I've been looking for although the build system is still a huge mystery to me
both are cool
odin seems to be lacking on the platforms front for now and it packs a package manager/build system (due to project philosophy)
but from my usage it seems quite stable and rarely breaks across versions and if it does it's not much
zig is cross platform, has a package manager/build system but it breaks very often, it's less mature and the LSP is not as good as Odin's because it relies too much on comptime (supposedly a better LSP will be shipped with the compiler once the language is more mature)
@@FlanPoirot Don't get me wrong, I absolutely love Odin it's just that for some of my projects it probably wasn't a good fit (yet?)
Do learn from existing build dot zig files in existing repos. The zig build documentation is as lacking as you would expect for an unreleased language that is still in flux. I only use zig build nowadays, it's so powerful.
I am still an amateur when it comes to the build-system, but still manage to stumble through what I need without much struggle. I am sure it gets more complicated with cross-compiling C libraries for exotic architectures, but the typical use-cases of of building/linking some libraries and importing some Zig modules is painless. For a reference point, it is far less complicated than using CMake if you are familiar with it, but very different.
Zig is the king of building prod clang projects but if you need something else it can be tricky.
this is the way
Can you host the cosmopolitan/cosmocc team?
I use MSVC most of the time, and I love it. The problem is, there's nothing like it on Linux, and this is a deal breaker for me. My experience with open source IDEs is painful. What will be available for zig?
I'm experiencing those compiling issues right now! I wanted to cross compile an SDL2 program using SDL_gfx to Windows and I can't get the SDL_gfx to compile.
I'm thinking of replacing that functionality with my own implementation, love C but getting to compile things is definitely a challenge.
In summary, it seems that the 'magic' of Zig as a Multi-OS Build System is that it is creating *another* build environment, which from the viewpoint of a library developer is *just another* build environment that the developer has to support in addition to already supporting build environments which are direct competitors to the Zig's build environment. No?
About make, always look up what commands are used in the makefile: I have worked on a open-source java project with maven used for the build, and make used on top of it for build steps orchestration.
Problems were that
1) I work on Windows so need to find and install a version (but that can be done, there are projects that builds make for windows, its just not very common, and I could just drop a linux VM or use WSL2 for building the java project),
But the worst was 2) the lead dev that made the makefile is on macOS and made it full of macos specific commands everywhere.
The thing would not even build on linux ... first time I had seen a cross platform project made non-cross platform on the dev side.
Ultimately, I unlocked the situation for the other devs and myself by finding and provinding the system specific maven commands that were simply reconstructed and called by the orchestration makefile.
more Zig!!!!
lets see where this is going
if its ziggin i`m zagging a like 🤣
I'm not making the argument that we go back in time, but './configure && make install' is pretty easy.
What Zig provides is cross-platform builds for all major architectures out of the box. No CI build step to spin up a MacOS container
Brew also works on Linux.
round 2 👏
I don't get how can you run Windows or MacOS linker on Linux though even if you have it packaged since the linker itself is a windows/macos app not a linux app?
Zig has a portable macos linker written in zig
5:18 C programmers will instantly disagree with you
No. i think using C libraries from python with pip is easier than trying to configure and build C libraries yourself. Especially if you write C on windows, where there is no system package manager, when you do not use Visual Studio, where the configure shell scripts don't run, where there is no standard location where C libraries should be installed to, where the MSVC compiler and linker live in weird directories and are not on path.
Basically the only C libraries that are easy to integrate into your C project are header-only. Especially when you want to also build for weird targets e. g. WebAssembly and so on.
Developing in C on Windows sounds like a nightmare.
@@iatheman Well, that is only if you use 3rdparty non-header-only libraries, if you write everything yourself (like most good C programmers) it is a joyful experience.
I see zig everywhere, so I'm curious now. I code in JS and some Python for a living. Do I need to learn C before learning Zig?
By learning Zig you will learn C as well...both are 1:1 in terms of structure.
I'm doing both actually at the moment it has been an amazing learning experience so far.
Previously I wrote Python webapps and used a bit of Javascript for dataviz.
@@pietraderdetective8953 thanks for taking the time. I'm already at it
You really don't need it. But C is syntactically very simple. So you can learn the basics of C in a day. Afterwards it's business as usual: You google less and less over time and get faster, cleaner and more comfortable over time.
@@albertoarmando6711 Yes, learn C and assembly before anything else if you want to be a systems programmer.
It depends on your own personal goals. If you want to learn Zig, no, you don’t need to learn C. But, if you want to be a systems/low level programmer you should. It will also improve your skills. C is not difficult to learn, there is a lot of misinformation and some gatekeeping about C’s learning curve. Like any language becoming an expert takes time, but the language is very small and can be learned in a few days.
Honestly the main reason I can’t get into Zig is its poorly-documented build system. Where are the definitions for the structs being used? How does the build system find dynamic libraries? Why does it seem to change every single time a new Zig release drops?
the build system is entirely part of the zig standard library, see lib/src/Build.zig, everything is defined in there, also the Learn section on the official Zig website has a build system guide
Sibilance
what are the latest projects that are being written in Zig? can anyone point me towards them?
tigerbeetle, ghostty, bunjs are the major ones
Parts of the Roc compiler
@30'xx: one thing that always made me hate python was, exactly, the need to have c compilers installed to build some dependency of a package. Folks, I hated it so much to the extent that I started carrying the whole pip cache on a USB disk so I could copy things over to some other system I needed to work on.@40:xx I'm still not satisfied that one must expect a system to compile a dependency. If a package has a wheel, it should be "binary self contained", otherwise, it feels like the wheel system's whole purpose is defeated.
I gave a talk titled "Deinventing The Wheel" (it's available on youtube) about the limits of wheels. If you can be confident it will work reliably, there's a lot to like about building software precisely for the exact set of instructions that your machine support.
Why a language designer want to be strict with line endings ? What's so special on it ? Is there any benefit in doing that ?
They have couple of benefits, initial parsing in the compiler is easier to implement as well as formatters, linters and syntax highlighting, it’s more explicit making it easier to reason about the code as well making greping through code bases with regexes slightly easier.
@@UnidimensionalPropheticCatgirl That's the only reason I don't want to try Zig on Windows. All other new languages are in my bucket list. I am doing hobby projects in D, Nim, Odin, C3, Nelua. I stopped Zig after the first hello world program.
@@kcvinu why is it an issue? all text editors except windows notepad use
these days.
is a relic of the past
@@notuxnobux Seems like you are using Linux. In Windows, vs code is using CRLF. That's the Windows default.
@@kcvinuzig's guide says /n is the line terminator, but /r/n is also valid?
i spent 3/4 of the video thinking they were talking about a text editor, wondering why they were talking about programming languages so much..
When you move the config file into the compiler, you’re surrendering yourself to the opinions of the person who wrote the compiler.
True, but I currently have myself surrendered to the person who spec’d YAML, and I’m not certain I’m happier. 🤷🏻♂️
@@DeveloperVoices At least then you can write your config in JSON or whatever, then write a script to convert to yaml.
The extra steps is the price of freedom.
Ah, I think I’d missed your point the first time around. You’re saying that the advantage of config file is you’ve got many reader implementations to choose from?
That I’d have to agree with. You’re tied to one way of expressing the answer, but free to choose how that’s interpretted. 👍
no ty