At first, I just saw a Targaryen and a Tarley (Game of Thrones) talking but then... anyway, thank you YT algorithm for recommending this talk between Kris of House Targaryen and Loris of House Tarly about: 00:00 The trend to replace C: wise and terrifying 02:58 Why Zig needs to exist? 04:27 On C Metaprogramming, etc. 04:55 C++: It's power and complexity 05:52 Forget Language war 06:54 "Focus on debugging your application rather than debugging your programming language knowledge." 07:17 Why not Rust? 08:53 Why not Go? 10:47 On reusing existing C but leaving its ecosystem 11:24 Zig vs Design Constraints 13:55 Zig LOVES C and C++ 15:04 Zig is LOVED by Go and Rust 15:59 Zig's built-in C compiler SHOCKS Kristoff 16:37 When Apple released M1, Zig was the first... 20:08 Built-in linker and "backends" to get past the LLVM 24:05 Going all the way down to the lower level 24:46 Timeline depends Talent Quality and Quantity 25:21 The Call to Transition from "4 hours" to "20 secs" ecosystem 26:50 New to Zig Programming, what to expect? 27:10 Zig on Comptime and Runtime 27:51 Zig's invitation to JavaScript or Python Developers 34:10 How C interop works? 37:08 Importing C header files, internal auto bridging file 41:49 Zig and Go's Defer, C++ Destructors, Zig's Defer on C 43:31 "Zig is better at using C libraries than C" 44:12 Pointer arithimetic? 46:16: Crucial things on pointers 48:55 Memory Management 51:37 Allocator's leak detection in debug mode 52:33 Zig's correct way of LEAKING MEMORY: Debug vs Release Mode 56:03 CompTime, Runtime,Infinite loops, Undecidable things 1:02:28 Generics, Lisp Macros, Zig's Metaprogramming 1:05:38 Comptime Code checking and emitting comp error 1:09:31 Zig as a 501(c)(3) Non-profit Foundation 1:12:34 Support Contract Zig-cross-compiling C and C++ backend services 1:13:27 "You cannot make a successful language unless you are supported by a big tech company" 1:14:27 Design Consistency vs Kitchen Sink Evolution 1:18:31 Getting Started with Zig: Learning Recommendation 1:21:10 Conclusion 1:22:57 A Fun Easter Egg
@@tomknud So vague, and no link,? Please don't parrot your noise onto our minds. A better use for that time is to learn more until you can offer us some real and valuable insight. I look forward to it. I trust you can.
Love the combination of you asking great questions and letting your guest talk, and Loris answering questions aware that people with incomplete knowledge are listening. Two great communicators yield a very satisfying in-depth talk :)
I don’t know what you did or how I found this video but this popped in my recommended and I gotta say, this is by far the best developer podcast I’ve ever listened to. Please change nothing. You ask excellent questions, you’re very attentive to your guest, and you allow them the freedom for them to go deep in order to open up a world of knowledge to the curious listener (such as myself). Thank you so much for this wonderful content I am so grateful I happened upon and I am definitely subscribed now!
Where has this channel been hiding ? Great content across the board, well presented. Subscribed. I tuned in for the Zig content, and was thrilled to discover a whole new channel full of quality, in-depth content. Kris seems like a great guy, with all the enthusiasm for programming that bought us here in the first place. Thx.
I first learned about Zig when trying to use Rust for AWS Lambda functions. It worked exactly as described in this video - the Zig compiler cross-compiles the Rust code in order to target the specific version of libc used in AWS Lambda runtimes. I was kind of blown away by it to be honest. Rust on Lambda was my first contact with Zig. I really enjoyed learning about the details from Loris in this video.
Wonderful video by both participants. I didn't think I'd watch much of it because 83 minutes. Next thing I knew I was 70 minutes in and just stayed until the end. I appreciated how the host gave so much space while intermittently prodding the discussion in interesting directions with well-prepared questions. I also liked how both participants spoke slowly enough with an attenuated tonal cadence for clear articulation and allowing the audience time to internalize what is being discussed without losing track of the flow of conversation. It was a calming experience that was easy to watch/listen to, which given the nature of the content, having such an easy-to-digest style is quite advantageous. There's already enough complexity in the content for us to parse that my attention was already quite occupied.
Wow, this has been incredibly illuminating. I have a Go project with C dependencies and I did not know I could use zig to cross compile it to a single executable binary! This is huge!
Very good video. I clicked on it on a whim and I'm happy that I did. My current impression of Zig is that its a cool project that I can appreciate, but ultimately it doesn't feel like a competitor to Rust. Rust seems to have different goals and features that I love very much, and Zig doesn't seem to have some of them nor does it aspire to have them. Its on a different path, which is perfectly fine, but its not a path I want to be on personally. But im glad it exists, cus I might find myself using it one day.
So the desire of the language creator of "I want to build a Digital Audio Workstation but I don't want to do it in ANSI C" makes perfect sense in this context. I imagine that working with real-time audio is difficult in Rust because so much of what you want to do with audio requires "unsafe" code. So if much of your code is unsafe Rust, you might as well just use C right? So Zig doesn't really compete with Rust - it has a different goal. Rust has always been about safety first, and Zig has different design goals.
@@7h3d4sH I've never done audio, but why would so much of it require unsafe Rust? How different is it from other real-time domains, such as game engines, databases, hardware controllers, etc? If there's a few things that require unsafe, such as arena allocators, or things like that, it's possible to use a stable crate that has taken care of the unsafe code, and has been tested for years, with many bug fixes, rather than try to reinvent everything and tackle undefined behaviour yourself. Which is what happens if you choose to write C, C++, or Zig. It's almost like writing unsafe Rust, as nothing protects you from write/read contentions or from use-after-free/dangling-pointer issues.
Zig appeals more to C users, and Rust appeals more to C++ users. Not sure why Rust/C are so often compared, they are hardly even comparable aside from both being systems languages. I don't bother spending much time comparing Bash and Ruby just because they are both scripting languages, it really isn't a productive comparison.
Love this interview. The interviewer is humble and and approaches every interaction with a charitable beginner mind. The interviewee is excited and precise in his explanations.
I love the idea of procedural comptime ❤ Just yesterday I found myself talking to a colleague about a TypeScript type, describing what the type “did”. Of course TS types are declarative so they don’t really “do” anything - they just “are” - but in my mind the type represented a series of transformations on an input type. How much easier it would have been to express the transformations procedurally!
I already know zig for over an year and love it and I still learned quite a bit from this discussion and thoroughly enjoyed it. Great stuff. Thank you!
This is a truly amazing interview. I've been interested in programming language design and philosophy for a long time. Made some (very) minor contributions to the R7RS Scheme standardization process in the past, and just generally love Scheme as a language. I've just quit my job with the intention of resting for a while, and part of that resting will involve teaching myself new things. I've been considering dipping into Rust, Zig, Go, Haskell, OCaml, Assembly, and more, if I actually find enough time for each of them. Given that I'm a fan of simplicity (Scheme over Common Lisp, for example) I foresee that I'll probably end up enjoying Zig more than Rust, as far as the very low-level languages go.
I recently did a video series on using Zig on the raspberry pi pico. Where we develop a SIMON game in the course of 4 lessons. And I have to say, that Zig on the RP2040 (Pi Pico) is a blessing. Although the HAL doesn’t yet have all the features it is useful for Most of your simple embedded stuff. So I can’t wait seeing you do this on the Atmel side!
“Taking over” is not really a thing. There are just new projects that seem to be created more often in Rust and Zig, which will be around for awhile. C++ as well, there is also the Carbon project.
@RogueTravel I think I'd like to see a diversification of the coding marketplace. I love C and don't think it will ever go away since it is so embedded, but also maybe inclusion of other languages in builds to take advantage of the strengths that cover the weaknesses of the others.
The awesome thing about Zig is that it has a transition path from C - all other languages require a lot of koolaid and adoption across a team. Zig can sort of just show up and start adding value to a C build and then slowly Zig libraries can start being part of a project.
One thing I love about the podcast format is, I try to aim for roughly a certain length, but if things are too interesting to stop then we're always free to keep going. 🙂
Loris is really smart. The answers he gives and the way he establishes his ideas are very clear. So, I will explore Zig, and I already have a good feeling about it.
For many years, every.. few days? Few weeks? I'd fantasize for a while about working on a computer language project. A language that compiles to native code on multiple platforms and tries really hard to be easier to use than C or C++. It's awesome to hear that Zig is working toward including their own back end / LLVM replacement option. LLVM (Low Level Virtual Machine) creates a virtual machine that your language targets, so that your language can run on any platform that has LLVM support. It's kind of like a JVM (Java Virtual Machine) almost, but a bit more primitive (low level) and it's not a JITer (Just In Time compiler - it doesn't spend cycles compiling and optimizing byte code at run time). So.. it's hard not to see LLVM as kind of a crutch or a cop-out. It seems like you're not really very likely to be able to optimize all that well for any particular architecture if you're language is targeting a virtual machine. On the other hand, any language that isn't machine language or assembler language presents what amounts to a virtual machine to a programmer. Still, are languages all the same? Do they all present more-or-less the same VM to developers? They might, more-or-less - most languages are comprised of the same general elements: Literals, variables, arrays, operators, things like tuples and slices and data structure initializers and "comprehensions", if/then/else, switch/case, for/while, functions, classes with data/function/procedure members and operator overloads and inheritance & polymorphism and construction/destruction, modules, namespaces, threading, forking, events, etc., once you know the syntax for how to do all that stuff, you pretty much know the language, and most languages have some kind of support or another for most of those things. So these days, I'm a bit less energized about the idea of a new language, because I think I'm kind of coming to the conclusion that it isn't actually the language itself that makes all that much difference between one language environment and another. I actually really like the C++ language, quite a lot, for example, especially now that we have things like auto and smart pointers, and the whole super convenient, pretty derned fast (for the most part) STL. The problem is, the build environment and the libraries are just a nightmare compared with something like C# or Java. Take libzip, for example. Worked great and was easy to use in C++.. until I went to encrypt this particular .mp3 file I had. Then I got a very unhelpful error message. I spent.. a week? Two? Trying to solve that problem. Learned way way more about zip files and mp3 files and all the various libraries related to them that are out there than I ever wanted to know. And still couldn't solve my problem. And I mean.. I worked at Intel for a while, on a team that used C++, and I cannot begin to describe the pains our team went through related to exactly this general sort of problem. Libraries crashing or not doing things it seemed like they should and it isn't clear why, and it just takes 4 Freaking Ever to get anywhere. That team worked on a project for a year and half that could've been done in probably a few months in Java or C#. Their full build was taking 25 minutes to run. Crazy! Just getting something like a cross platform music player working, complete with a UI, is a multi-month proposition in C++. You can do that in a single day in C#. I wrote a test program in C# to interact with an encrypted zip file, and the .NET Nuget packaged ZipLib library encrypted my special .mp3 file right out of the box, no problem. Not even a single hour wasted. This is the real difference between one language environment and another! It's not the language itself that makes C++ a pita. Not at all. It's the freaking build environment and the eco system of commonly available libraries. Language developers, these days, often seem to feel compelled to implement compile time meta programming, I guess so that language users can create compiler extensions. It seems to frequently be an early mention for them. I almost never do meta programming, and I rarely come across it. I suppose if it helps produce better error messages, it's worthwhile. It might help people who are working on the library ecosystem. I hope it doesn't end up blowing up build times. That's the most important and relevant challenge, I think, for an up and coming computer language - solving the build environment and library ecosystem problem. We need a language with the performance of C that has a cross platform build environment and library ecosystem that rivals that of C# in the Windows environment.
I've been "planning" a digital audio project for years (yes years, it's a hobby project I can faff around for as long as I like) and haven't been able to find the right language (I want high-level - but not too high and I want interop with assembly-language)... and Zig is my current candidate. The original code I worked on years ago was C++ and I don't want to go back there, I've considered Rust but it IS like C++'s type-safe younger brother like Loris says and we don't like that. But now I've heard that Andrew Kelley was actually working in the same area when he started on Zig, I think even more that it might be the answer I've been looking for.
Very well presented. I'm only 5 minutes in and you've given a few good examples that explain the justifications for some of the prominent language features. Lesser videos often ramble on about trivialities and never hit on this.
43:00 Another problem with C++ ctors & dtors is not only that they only work in C++ & C++-like contexts, but also that they often have (at compile time) difficult to asses run -time & -space requirement on top of what's explicitly in the code, which Zig's "defer" doesn't have because it only adds static branching code on top of what is written in the code explicitly.
Passing allocators seems to be overhead, but I think it is actually an awesome idea. I have used many different allocators in my projects (buffer pools, arenas, buddy systems). In Zig I could use these different allocators easily
I’ve been zig curious for a long time, but I’ve been holding back because of the lack of RAII… This interview finally got the zig philosophy to click for me in a way that nothing else had before. Thank you!
Really enjoyed this one , Loris also a really great speaker on Zig and explained the language choices really well. Don't know if I'll ever get a chance to try it but had not even considered it before.
@12:11 Point of correction. This is outdated knowledge on Rust. Rust does not depend on libc, you can use musl and there are other alternatives. There is also no-std as well, you can go that route. This is more like zig than less like it. That section of the talk should be taken with caution or passed over.
@@kristoff-it true, but musl is static and not glibc which is what the video was making a case about. The real point here is that specific divide is not as big as the video implies. This is not a point you should “choose” or look at Zig over. There is also a rust libc early in dev, don’t recall the name. I have nothing against Zig, just think the argument needs to be stronger than weaknesses of glibc.
I just found your channel and I must say I love your style of interviewing. I'll be watching more of your videos and look forward to new videos in the future.
Man I loved null terminated strings: all you gotta do is double the null bytes for UTF-16/Unicode, and make the new length a few bytes before what the pointer points to and you should be able to make your new langs like zig compatible with the old C libs. As long as you add the nulls and recount the length when crossing that api boundary and have the appropriately pre and post over buffered alloc for those extra bytes! ;-)
16:10 "Okay. Andrew started out trying to build an audio workstation and ended up building a language that also includes a C compiler." This kind of reminds me of RMS trying to fix the situation with closed source printer drivers and ended up building a whole open source operating system (with help of other people such as Linus). And in case of GNU/Linux, many printers still do not work.
@@DeveloperVoices Good point. However, try to output 10 sheets of A4 sized stuff with readable text with the 3D printer and you'll quickly notice that it's really slow, resolution sucks and printing costs are skyhigh. The hard part about 2D printers is getting cost per page really low without sacrificing accuracy of the prints. That said, 3D printer can obviously do magical stuff compared to 2D printers, but we still need both until 3D printers get much better.
@@MikkoRantalainen uhm, per wasn't comparing 3D printer to 2D printer to do the cross-task of 2D printing. Rather it was just a funny and satirical contrast made here just due to their identical market name... No one is comparing them directly (there _is_ no direct comparison in those) or even in cross-functionality; rather just how they perform in their own dedicated tasks. > _"try to output 10 sheets of A4 sized stuff with readable text with the 3D printer ... but we still need both until 3D printers get much better."_
It's rare I'll sub but you had my vote in the first five minutes. Clear from the outset that this would be insightful. Very much looking forward to future content.
Awesome talk, I'm glad to have found this channel! It was very educational, and you were / Kris was a great listener. I hope I can learn Zig in the near future with a personal project.
Go and Rust is not a new C (not intended to replace C) but Zig does (I watched Andrew, the man who invented Zig, on his presentation he clearly declared that "Zig is C but with problems fixed"). Zig is language clearly intended to replaced C so Zig should do his best to make it happend.
This was a fantastic podcast! Particularly for those uninitiated in Zig. I now understand the philosophy of the language and can quickly determine whether I should consider using Zig for any specific project. I don't have to try Rust, learn how the borrow checker works, disagree with the borrow checker and then consider using Zig.
INMHO Zig is new and fresh low programming language for new craftsman generation looking for get out of C classic box. By the way C is my lovely one language. Zig is an excelent choice. This 1:23 are one of the best time investment I've made in youtube! Thanks for sharing!
ok subbed , the algo has not delivered me such quality content in months ~ zig also looks alot less intimidating than I thought ! advent of code time (after I learn go)
32:00 "not yet having a library for everything" is indeed a problem for every (new) programming language - except(!) for those languages which have great interfaces to other languages (FFI), like Zig, which can use all C & C++ ABIs (of LLVM but also GCC's soon) on all platforms that it compiles to, meaning if you use these languages, you have one problem less to worry about.
I have been a JavaScript developer for about two years. And I have been pondering how to grow as a developer. Part of that path is exploring other languages. Thank you for your excellent podcast! It has helped me grow so much! If that is your mission then you are winning. So far, zig has become top of my list! I am going through a bunch of c learning material just to understand the foundation of modern computer programming, but dang, when it comes to wanting to actually develop something Zig is what I want to use. The other one that captures my attention is mojo.
14:01 That's incorrect. Rust can cross-compile not only Rust but also C, using de-facto standard cc crate. Build structure from cc crate has a target feature, that allows to specify the target for the compiled C library used in the project.
I think Zig Vs Odin is a much better comparison. Hope Loris could make a comparison(even as a reply in the comments section) as to why would I choose Zig over Odin besides the crosscompilation functionality.
@@DeveloperVoices Someone who has even tried Haskell for a while said that from all the low level programming languages he has tried, Odin is the most ergonomic of all of them and has the best thought out error handling of any programming languages he has looked at. And that is quite a big thing to proclaim considering he used Haskell for quite a while.
@@encapsulatioOdin was made for games programming more than a general or systems programming language like Zig was. I think they are both tools for different jobs.
@@TJackson736 Simply not true. I have a hunch you have not even once visited Odin's website and are talking simply based on hear say. It clearly states: " Odin is a general-purpose programming language with distinct typing built for high performance, modern systems and data-oriented programming. Odin is the C alternative for the Joy of Programming. "
you should choose Odin any day.. it much2 more polish.. the downside is, it basically have no big community behind it... i coded in both language.. zig has potential but it is ugly as hell
Ive studiee go for some time and become my togo language. Go for web is veeeeeery nice to code! Very pleasant. I in the next 3 months i will star studying rust and decided to go with zig as well. So i will try to do both stydies together and build same things at both languages to compare
I've only really been spending time with rust and I love it, but I really need to have a good go at zig and nim at some point, I really love the spirit of these languages; really taking on c++ in that "zero cost abstractions" sense (and also RAII/unique pointers in rusts case at least but with a nicer syntax). I've left cross compilation until last it seems and I have been struggling with it in rust, but I really like the idea of very general code that runs everywhere. Tooling and nice dependency management is also huge. Also, in terms of going all the way, I really want to see an OS written in a newer language, like RedoxOS.
@@raidensama1511 I believe it compiles to c, but it gives you much higher level syntax. Although I think it might be garbage collected :( still, it does some interesting things
I haven't had any problems with slow VS for a long time. It's my main development IDE. I love it. Nothing comes close in my experience. Please don't even mention Eclipse. LOL Lisp was also my most fun language at university.
I loved this talk, only 2/3 the way through, but it was very good so far. Would you please get Ginger Bill on to talk about Odin? I'd love to hear you talk to him about it, because it's in this low level languages space, and I think it does a really good job as a c alternative. It would be informative for you to compare and contrast the features and developer experience of each,
Use the right tool for the job. Most startups have switched to Go for backend. Very small number of companies actually use rust for that. Anybody can easily dive into go and pick up the idioms in sometime. Zig doesnt replace that and it doesnt compare with Rust's maturity.
Many thanks for the great discussion on so many wonderful topics. It would be helpful to further clarify what is meant by uses of the term 'complex,' 'complicated' etc.
I'm not smart enough to use Rust. I think I am sold on Zig. Rust just is a huge undertaking to master where the language itself isn't part of the proble..
I was listening carefully about the stated shortcomings of Rust: I picked up on it needs to use some aspects of the C libraries for different platforms (is that a big problem though?), and it is a complex language (fair enough, takes a while to master it). I have been learning Rust recently and Zig came onto my radar for another language to keep an eye on. I did actually look at tutorial content for Zig but got a bit lost following it though.
@@skurtz97 Rust _is_ a systems level programming language and does not depend on libc by design. What depends on it is Rust's std library and all bells and whistles it is giving you, but you can choose to write embedded code with nostd modules and is de facto the mode Zig chooses by default, where you need to worry about everything on yourself. There is Redux OS written entirely in Rust and currently it is also an official second Linux Kernel language. It was also disigned to rewite Firefox in it (sort of, some parts were rewritten already), so you are right that it also targets C++ audience.
@@skurtz97 A lot of misinformation in this comment, but it makes sense as people don't have a deep understanding of Rust without using it. Rust the language, does not depend on libc. It can be compiled to target embedded environments and runtimes such as WASM, but it requires you to use rust without `std::` (the standard library). This is usually called `no_std` in the Rust world, and there's a huge ecosystem of crates around no_std for embedded and other such environments. Anything that can be done in Zig, C, C++, or pure assembly, can be done in Rust. There are no limits at all to the language.
Apple should sponsor Zig and perhaps add themselves an alternative (or replacement) for Objective-C. Keep Swift for high level stuff (UIs, apps, simple servers, scripting, etc.) and Zig for high performance code.
Excellent conversation! I don't see any reason for replacing C/C++ - especially in regards to flexibility and speed + Assembler blocks can be put for some important parts. C+++copilot is the winner 4me ;) That is more productive than ugly Rust and questionable Zig. These are my two cents :D I can be wrong. I use Go for command-line tools or web-socks. Docker and Kubernetes are mostly ready to Go products. The biggest disadvantage is that you can't do bare-metal machine-code with Go. There must be Os because of GC.Anyway because of how You're passionate about that I will give a try to Zig.
At first, I just saw a Targaryen and a Tarley (Game of Thrones) talking but then... anyway, thank you YT algorithm for recommending this talk between Kris of House Targaryen and Loris of House Tarly about:
00:00 The trend to replace C: wise and terrifying
02:58 Why Zig needs to exist?
04:27 On C Metaprogramming, etc.
04:55 C++: It's power and complexity
05:52 Forget Language war
06:54 "Focus on debugging your application rather than debugging your programming language knowledge."
07:17 Why not Rust?
08:53 Why not Go?
10:47 On reusing existing C but leaving its ecosystem
11:24 Zig vs Design Constraints
13:55 Zig LOVES C and C++
15:04 Zig is LOVED by Go and Rust
15:59 Zig's built-in C compiler SHOCKS Kristoff
16:37 When Apple released M1, Zig was the first...
20:08 Built-in linker and "backends" to get past the LLVM
24:05 Going all the way down to the lower level
24:46 Timeline depends Talent Quality and Quantity
25:21 The Call to Transition from "4 hours" to "20 secs" ecosystem
26:50 New to Zig Programming, what to expect?
27:10 Zig on Comptime and Runtime
27:51 Zig's invitation to JavaScript or Python Developers
34:10 How C interop works?
37:08 Importing C header files, internal auto bridging file
41:49 Zig and Go's Defer, C++ Destructors, Zig's Defer on C
43:31 "Zig is better at using C libraries than C"
44:12 Pointer arithimetic?
46:16: Crucial things on pointers
48:55 Memory Management
51:37 Allocator's leak detection in debug mode
52:33 Zig's correct way of LEAKING MEMORY: Debug vs Release Mode
56:03 CompTime, Runtime,Infinite loops, Undecidable things
1:02:28 Generics, Lisp Macros, Zig's Metaprogramming
1:05:38 Comptime Code checking and emitting comp error
1:09:31 Zig as a 501(c)(3) Non-profit Foundation
1:12:34 Support Contract Zig-cross-compiling C and C++ backend services
1:13:27 "You cannot make a successful language unless you are supported by a big tech company"
1:14:27 Design Consistency vs Kitchen Sink Evolution
1:18:31 Getting Started with Zig: Learning Recommendation
1:21:10 Conclusion
1:22:57 A Fun Easter Egg
I thought you were going to say house Martell :D
Lmao GOT
@@GreatWalker exactly my thoughts, hes a Martell for sure, not a Tarley!
Game of Thrones? So you think these engineers are like knights from a fantasy world? Sounds cool!
Finer Timestamps for the "Podcast" part
7:04 Why not Rust?
8:52 Why not Go?
11:25 Zig's answer to requirements' constraints?
15:59 Zig has a C compiler built-in?
20:06 Built-in linker & backends
26:39 User/Programmer space?
34:08 How C interop works?
44:11 Pointer arithimetic?
48:53 Memory Management?
56:03 CompTime & generic types?
1:06:06 Eg. & emit Compile Error
1:09:30 Funding?
1:18:30 Getting Started
1:21:10 Conclusion
Zig is apparently 10 times faster in some testing.
Thanks!!!
@@tomknud So vague, and no link,? Please don't parrot your noise onto our minds. A better use for that time is to learn more until you can offer us some real and valuable insight.
I look forward to it. I trust you can.
Your comment should be pinned, commended and lauded by everyone. Thanks for the time stamps, very helpful!
I’m Ron Burgundy?
Love the combination of you asking great questions and letting your guest talk, and Loris answering questions aware that people with incomplete knowledge are listening. Two great communicators yield a very satisfying in-depth talk :)
+ to this. Very satisfying episode to listern!
I don’t know what you did or how I found this video but this popped in my recommended and I gotta say, this is by far the best developer podcast I’ve ever listened to. Please change nothing. You ask excellent questions, you’re very attentive to your guest, and you allow them the freedom for them to go deep in order to open up a world of knowledge to the curious listener (such as myself).
Thank you so much for this wonderful content I am so grateful I happened upon and I am definitely subscribed now!
same experience for me!
zig is a very ambitious project and I love it. I hope zig gets the technical and financial support from the community.
Where has this channel been hiding ? Great content across the board, well presented. Subscribed.
I tuned in for the Zig content, and was thrilled to discover a whole new channel full of quality, in-depth content.
Kris seems like a great guy, with all the enthusiasm for programming that bought us here in the first place. Thx.
My thoughts exactly!
I first learned about Zig when trying to use Rust for AWS Lambda functions. It worked exactly as described in this video - the Zig compiler cross-compiles the Rust code in order to target the specific version of libc used in AWS Lambda runtimes. I was kind of blown away by it to be honest. Rust on Lambda was my first contact with Zig. I really enjoyed learning about the details from Loris in this video.
This video is a gem of an example of well-paced technical communication. Loris' care to clarify and explain up-front topics is appreciated.
awestruck. this guy's ability to translate such complex ideas into info digestible to the avg programmer is unmatched.
Wonderful video by both participants. I didn't think I'd watch much of it because 83 minutes. Next thing I knew I was 70 minutes in and just stayed until the end.
I appreciated how the host gave so much space while intermittently prodding the discussion in interesting directions with well-prepared questions. I also liked how both participants spoke slowly enough with an attenuated tonal cadence for clear articulation and allowing the audience time to internalize what is being discussed without losing track of the flow of conversation. It was a calming experience that was easy to watch/listen to, which given the nature of the content, having such an easy-to-digest style is quite advantageous. There's already enough complexity in the content for us to parse that my attention was already quite occupied.
What a great host. Intelligent questions and Letting your guest talk? Sadly insanely rare
I already loved working with Zig, this talk makes me feel inspired and have even more respect for the team.
Any ideas of project that would be a good fit to get started with zig?
A simple CLI can be a good first project
@@jasperdunn cli of what? :P
@danvilela sounds like you should make a CLI that comes up with ideas 👍
@@danvilela automate something you often do
even if you end up not using it, it's still great for learning
Wow, this has been incredibly illuminating. I have a Go project with C dependencies and I did not know I could use zig to cross compile it to a single executable binary! This is huge!
As a programmer (not in low level systems), I can’t express how grateful I am for gifted people like Loris doing what they do for the world.
Very good video. I clicked on it on a whim and I'm happy that I did.
My current impression of Zig is that its a cool project that I can appreciate, but ultimately it doesn't feel like a competitor to Rust. Rust seems to have different goals and features that I love very much, and Zig doesn't seem to have some of them nor does it aspire to have them. Its on a different path, which is perfectly fine, but its not a path I want to be on personally. But im glad it exists, cus I might find myself using it one day.
So the desire of the language creator of "I want to build a Digital Audio Workstation but I don't want to do it in ANSI C" makes perfect sense in this context. I imagine that working with real-time audio is difficult in Rust because so much of what you want to do with audio requires "unsafe" code. So if much of your code is unsafe Rust, you might as well just use C right? So Zig doesn't really compete with Rust - it has a different goal. Rust has always been about safety first, and Zig has different design goals.
@@7h3d4sH I've never done audio, but why would so much of it require unsafe Rust?
How different is it from other real-time domains, such as game engines, databases, hardware controllers, etc?
If there's a few things that require unsafe, such as arena allocators, or things like that, it's possible to use a stable crate that has taken care of the unsafe code, and has been tested for years, with many bug fixes, rather than try to reinvent everything and tackle undefined behaviour yourself. Which is what happens if you choose to write C, C++, or Zig. It's almost like writing unsafe Rust, as nothing protects you from write/read contentions or from use-after-free/dangling-pointer issues.
Zig appeals more to C users, and Rust appeals more to C++ users. Not sure why Rust/C are so often compared, they are hardly even comparable aside from both being systems languages. I don't bother spending much time comparing Bash and Ruby just because they are both scripting languages, it really isn't a productive comparison.
Love this interview. The interviewer is humble and and approaches every interaction with a charitable beginner mind. The interviewee is excited and precise in his explanations.
I love the idea of procedural comptime ❤ Just yesterday I found myself talking to a colleague about a TypeScript type, describing what the type “did”. Of course TS types are declarative so they don’t really “do” anything - they just “are” - but in my mind the type represented a series of transformations on an input type. How much easier it would have been to express the transformations procedurally!
I already know zig for over an year and love it and I still learned quite a bit from this discussion and thoroughly enjoyed it. Great stuff. Thank you!
You are such a competent interviewer, thank you so much for all your podcasts !
This is a truly amazing interview. I've been interested in programming language design and philosophy for a long time. Made some (very) minor contributions to the R7RS Scheme standardization process in the past, and just generally love Scheme as a language. I've just quit my job with the intention of resting for a while, and part of that resting will involve teaching myself new things. I've been considering dipping into Rust, Zig, Go, Haskell, OCaml, Assembly, and more, if I actually find enough time for each of them. Given that I'm a fan of simplicity (Scheme over Common Lisp, for example) I foresee that I'll probably end up enjoying Zig more than Rust, as far as the very low-level languages go.
The best Zig interview i've seen so far. So well presented and really interesting questions! Great job!
Thank you for sharing with us this wonderful conversation, I had a great time listening to you both! Zig
Excellent presentation. Thank you to both host and guest (people that is).
I recently did a video series on using Zig on the raspberry pi pico. Where we develop a SIMON game in the course of 4 lessons. And I have to say, that Zig on the RP2040 (Pi Pico) is a blessing. Although the HAL doesn’t yet have all the features it is useful for
Most of your simple embedded stuff.
So I can’t wait seeing you do this on the Atmel side!
the HAL magnetic sensor?
> _"Although the HAL doesn’t yet have all the features it is useful for"_
@@yash1152 Hardware Abstraction Layer
It's an exciting era for programming. We have new languages with the potential to rival C, but which will take over?
None.
@@joseoncracksomething will eventually
“Taking over” is not really a thing. There are just new projects that seem to be created more often in Rust and Zig, which will be around for awhile. C++ as well, there is also the Carbon project.
@RogueTravel I think I'd like to see a diversification of the coding marketplace. I love C and don't think it will ever go away since it is so embedded, but also maybe inclusion of other languages in builds to take advantage of the strengths that cover the weaknesses of the others.
The awesome thing about Zig is that it has a transition path from C - all other languages require a lot of koolaid and adoption across a team. Zig can sort of just show up and start adding value to a C build and then slowly Zig libraries can start being part of a project.
this is the most educative interview i have seen on internet. i would really want to learn more about systems programming from lori.
This was great! Thank you for doing this great interview both of you.
Thank you for this easy going yet precise technical conversation and for an enticing introduction to the Zig language! 🎉 Great job both of you.
Great talk. Special thanks to Loris Cro, who made this a particularly pleasant and informative episode.
While watching this I ended up building zig on my system. Can't wait to try it out!
Absolutely terrific wide-ranging conversation.
Thanks for asking about the compile time code at the end. Understanding macros has evaded me so far.
One thing I love about the podcast format is, I try to aim for roughly a certain length, but if things are too interesting to stop then we're always free to keep going. 🙂
Loris is really smart. The answers he gives and the way he establishes his ideas are very clear. So, I will explore Zig, and I already have a good feeling about it.
Fantastic interview and zig is a fantastic project. APPROVED!
Facinating, the language of course, but also this format of interview
For many years, every.. few days? Few weeks? I'd fantasize for a while about working on a computer language project. A language that compiles to native code on multiple platforms and tries really hard to be easier to use than C or C++.
It's awesome to hear that Zig is working toward including their own back end / LLVM replacement option. LLVM (Low Level Virtual Machine) creates a virtual machine that your language targets, so that your language can run on any platform that has LLVM support. It's kind of like a JVM (Java Virtual Machine) almost, but a bit more primitive (low level) and it's not a JITer (Just In Time compiler - it doesn't spend cycles compiling and optimizing byte code at run time). So.. it's hard not to see LLVM as kind of a crutch or a cop-out. It seems like you're not really very likely to be able to optimize all that well for any particular architecture if you're language is targeting a virtual machine. On the other hand, any language that isn't machine language or assembler language presents what amounts to a virtual machine to a programmer. Still, are languages all the same? Do they all present more-or-less the same VM to developers?
They might, more-or-less - most languages are comprised of the same general elements: Literals, variables, arrays, operators, things like tuples and slices and data structure initializers and "comprehensions", if/then/else, switch/case, for/while, functions, classes with data/function/procedure members and operator overloads and inheritance & polymorphism and construction/destruction, modules, namespaces, threading, forking, events, etc., once you know the syntax for how to do all that stuff, you pretty much know the language, and most languages have some kind of support or another for most of those things.
So these days, I'm a bit less energized about the idea of a new language, because I think I'm kind of coming to the conclusion that it isn't actually the language itself that makes all that much difference between one language environment and another. I actually really like the C++ language, quite a lot, for example, especially now that we have things like auto and smart pointers, and the whole super convenient, pretty derned fast (for the most part) STL. The problem is, the build environment and the libraries are just a nightmare compared with something like C# or Java.
Take libzip, for example. Worked great and was easy to use in C++.. until I went to encrypt this particular .mp3 file I had. Then I got a very unhelpful error message. I spent.. a week? Two? Trying to solve that problem. Learned way way more about zip files and mp3 files and all the various libraries related to them that are out there than I ever wanted to know. And still couldn't solve my problem. And I mean.. I worked at Intel for a while, on a team that used C++, and I cannot begin to describe the pains our team went through related to exactly this general sort of problem. Libraries crashing or not doing things it seemed like they should and it isn't clear why, and it just takes 4 Freaking Ever to get anywhere. That team worked on a project for a year and half that could've been done in probably a few months in Java or C#. Their full build was taking 25 minutes to run. Crazy!
Just getting something like a cross platform music player working, complete with a UI, is a multi-month proposition in C++. You can do that in a single day in C#. I wrote a test program in C# to interact with an encrypted zip file, and the .NET Nuget packaged ZipLib library encrypted my special .mp3 file right out of the box, no problem. Not even a single hour wasted. This is the real difference between one language environment and another! It's not the language itself that makes C++ a pita. Not at all. It's the freaking build environment and the eco system of commonly available libraries.
Language developers, these days, often seem to feel compelled to implement compile time meta programming, I guess so that language users can create compiler extensions. It seems to frequently be an early mention for them. I almost never do meta programming, and I rarely come across it. I suppose if it helps produce better error messages, it's worthwhile. It might help people who are working on the library ecosystem. I hope it doesn't end up blowing up build times.
That's the most important and relevant challenge, I think, for an up and coming computer language - solving the build environment and library ecosystem problem. We need a language with the performance of C that has a cross platform build environment and library ecosystem that rivals that of C# in the Windows environment.
I've been "planning" a digital audio project for years (yes years, it's a hobby project I can faff around for as long as I like) and haven't been able to find the right language (I want high-level - but not too high and I want interop with assembly-language)... and Zig is my current candidate. The original code I worked on years ago was C++ and I don't want to go back there, I've considered Rust but it IS like C++'s type-safe younger brother like Loris says and we don't like that. But now I've heard that Andrew Kelley was actually working in the same area when he started on Zig, I think even more that it might be the answer I've been looking for.
Very well presented. I'm only 5 minutes in and you've given a few good examples that explain the justifications for some of the prominent language features. Lesser videos often ramble on about trivialities and never hit on this.
43:00 Another problem with C++ ctors & dtors is not only that they only work in C++ & C++-like contexts, but also that they often have (at compile time) difficult to asses run -time & -space requirement on top of what's explicitly in the code, which Zig's "defer" doesn't have because it only adds static branching code on top of what is written in the code explicitly.
Passing allocators seems to be overhead, but I think it is actually an awesome idea. I have used many different allocators in my projects (buffer pools, arenas, buddy systems). In Zig I could use these different allocators easily
If you're not writing a library, just make your own global allocator and use it wherever you want. Nobody will get mad at you :)
This man is able to present the madness going on down there in an easy-to-understand package.
I’ve been zig curious for a long time, but I’ve been holding back because of the lack of RAII…
This interview finally got the zig philosophy to click for me in a way that nothing else had before.
Thank you!
Excellent! Glad it helped!
Really enjoyed this one , Loris also a really great speaker on Zig and explained the language choices really well. Don't know if I'll ever get a chance to try it but had not even considered it before.
I did the Ziglings, and I highly recommend both them and the language.
I didn't start to study Zig, but already loved it and after this talk I love it even more!
@12:11 Point of correction. This is outdated knowledge on Rust. Rust does not depend on libc, you can use musl and there are other alternatives. There is also no-std as well, you can go that route. This is more like zig than less like it. That section of the talk should be taken with caution or passed over.
musl is a libc though :^) no_std is good but that takes away a good chunk of the stdlib, which is significantly different than how things work in Zig
@@kristoff-it true, but musl is static and not glibc which is what the video was making a case about. The real point here is that specific divide is not as big as the video implies. This is not a point you should “choose” or look at Zig over. There is also a rust libc early in dev, don’t recall the name. I have nothing against Zig, just think the argument needs to be stronger than weaknesses of glibc.
I just found your channel and I must say I love your style of interviewing. I'll be watching more of your videos and look forward to new videos in the future.
Thanks! I have plenty more coming. 😁
Man I loved null terminated strings: all you gotta do is double the null bytes for UTF-16/Unicode, and make the new length a few bytes before what the pointer points to and you should be able to make your new langs like zig compatible with the old C libs. As long as you add the nulls and recount the length when crossing that api boundary and have the appropriately pre and post over buffered alloc for those extra bytes! ;-)
16:10 "Okay. Andrew started out trying to build an audio workstation and ended up building a language that also includes a C compiler."
This kind of reminds me of RMS trying to fix the situation with closed source printer drivers and ended up building a whole open source operating system (with help of other people such as Linus). And in case of GNU/Linux, many printers still do not work.
It's 2023, I have a 3D printer, and it's probably more reliable than my 2D one. Welcome to the future. 😅
@@DeveloperVoices Good point. However, try to output 10 sheets of A4 sized stuff with readable text with the 3D printer and you'll quickly notice that it's really slow, resolution sucks and printing costs are skyhigh.
The hard part about 2D printers is getting cost per page really low without sacrificing accuracy of the prints.
That said, 3D printer can obviously do magical stuff compared to 2D printers, but we still need both until 3D printers get much better.
@@MikkoRantalainen uhm, per wasn't comparing 3D printer to 2D printer to do the cross-task of 2D printing. Rather it was just a funny and satirical contrast made here just due to their identical market name... No one is comparing them directly (there _is_ no direct comparison in those) or even in cross-functionality; rather just how they perform in their own dedicated tasks.
> _"try to output 10 sheets of A4 sized stuff with readable text with the 3D printer ... but we still need both until 3D printers get much better."_
Thank you very much for this, it was very interesting. It reminded me about dlang, which (I think) is on a very similar mission.
14:35 D also has this feature. D is now also a C compiler.
It's rare I'll sub but you had my vote in the first five minutes. Clear from the outset that this would be insightful. Very much looking forward to future content.
this is the first time ive heard the value prop for zig explained clearly
Enjoyed every bit of the talk! Hope this channel grows and keeps you motivated to put out content :)
I just found this channel today, this is my 4th episode already, great channel!!
Thanks! I'm glad you're enjoying it!
Excellent video, informative and honest (with zero language zealotism, which is rare). I look forward to try Zig if the right project shows up.
Awesome talk, I'm glad to have found this channel! It was very educational, and you were / Kris was a great listener. I hope I can learn Zig in the near future with a personal project.
Go and Rust is not a new C (not intended to replace C) but Zig does (I watched Andrew, the man who invented Zig, on his presentation he clearly declared that "Zig is C but with problems fixed"). Zig is language clearly intended to replaced C so Zig should do his best to make it happend.
This was a fantastic podcast! Particularly for those uninitiated in Zig. I now understand the philosophy of the language and can quickly determine whether I should consider using Zig for any specific project. I don't have to try Rust, learn how the borrow checker works, disagree with the borrow checker and then consider using Zig.
Great questions! Maybe a little intro about the speaker and who he is? just throwing some positive feedback out there 🙏
INMHO Zig is new and fresh low programming language for new craftsman generation looking for get out of C classic box. By the way C is my lovely one language.
Zig is an excelent choice.
This 1:23 are one of the best time investment I've made in youtube! Thanks for sharing!
ok subbed , the algo has not delivered me such quality content in months ~ zig also looks alot less intimidating than I thought ! advent of code time (after I learn go)
first i have learned about zig. great presentation. i am feeling positive about this project's future! he is a smart dude.
32:00 "not yet having a library for everything" is indeed a problem for every (new) programming language - except(!) for those languages which have great interfaces to other languages (FFI), like Zig, which can use all C & C++ ABIs (of LLVM but also GCC's soon) on all platforms that it compiles to, meaning if you use these languages, you have one problem less to worry about.
That was a great podcast with a great guest and a great host. I can see this channel growing a lot with this kind of content!
I have been a JavaScript developer for about two years. And I have been pondering how to grow as a developer. Part of that path is exploring other languages. Thank you for your excellent podcast! It has helped me grow so much! If that is your mission then you are winning.
So far, zig has become top of my list! I am going through a bunch of c learning material just to understand the foundation of modern computer programming, but dang, when it comes to wanting to actually develop something Zig is what I want to use. The other one that captures my attention is mojo.
14:01 That's incorrect. Rust can cross-compile not only Rust but also C, using de-facto standard cc crate. Build structure from cc crate has a target feature, that allows to specify the target for the compiled C library used in the project.
The cc crate invokes the system C compiler.
@@kristoff-it and Zig invokes LLVM infrastructure. Can you tell me how invoking the system library is bad?
@@dmitriidemenev5258 it's not bad, it just doesn't work if you try to cross-compile. With Zig it works, easy as that.
A very good podcast. I like the host, the guest and the subject.
I think Zig Vs Odin is a much better comparison. Hope Loris could make a comparison(even as a reply in the comments section) as to why would I choose Zig over Odin besides the crosscompilation functionality.
Ah, I'd not heard of Odin. I shall add that to my research list. Thanks!
@@DeveloperVoices Someone who has even tried Haskell for a while said that from all the low level programming languages he has tried, Odin is the most ergonomic of all of them and has the best thought out error handling of any programming languages he has looked at. And that is quite a big thing to proclaim considering he used Haskell for quite a while.
@@encapsulatioOdin was made for games programming more than a general or systems programming language like Zig was. I think they are both tools for different jobs.
@@TJackson736 Simply not true. I have a hunch you have not even once visited Odin's website and are talking simply based on hear say.
It clearly states:
" Odin is a general-purpose programming language with distinct typing built for high performance, modern systems and data-oriented programming.
Odin is the C alternative for the Joy of Programming. "
you should choose Odin any day.. it much2 more polish.. the downside is, it basically have no big community behind it... i coded in both language.. zig has potential but it is ugly as hell
This was an amazing talk. I've never seen this channel before, I'll have to start binging now 😅
great interview, got a sub from me. love your format and questions, probably gonna binge your stuff with the free time from thanksgiving break.
Thank you. This was very educational
Thanks!
Ive studiee go for some time and become my togo language. Go for web is veeeeeery nice to code! Very pleasant.
I in the next 3 months i will star studying rust and decided to go with zig as well. So i will try to do both stydies together and build same things at both languages to compare
I've only really been spending time with rust and I love it, but I really need to have a good go at zig and nim at some point, I really love the spirit of these languages; really taking on c++ in that "zero cost abstractions" sense (and also RAII/unique pointers in rusts case at least but with a nicer syntax). I've left cross compilation until last it seems and I have been struggling with it in rust, but I really like the idea of very general code that runs everywhere. Tooling and nice dependency management is also huge.
Also, in terms of going all the way, I really want to see an OS written in a newer language, like RedoxOS.
Isn’t nim C?
@@raidensama1511 I believe it compiles to c, but it gives you much higher level syntax. Although I think it might be garbage collected :( still, it does some interesting things
I haven't had any problems with slow VS for a long time. It's my main development IDE. I love it. Nothing comes close in my experience. Please don't even mention Eclipse. LOL
Lisp was also my most fun language at university.
Beautifully explained. Thanks to both of you.
As a rust dev, am excited about Zig
Thanks for both of you, great conversation. Zig is a thing for me now.
I loved this talk, only 2/3 the way through, but it was very good so far. Would you please get Ginger Bill on to talk about Odin? I'd love to hear you talk to him about it, because it's in this low level languages space, and I think it does a really good job as a c alternative. It would be informative for you to compare and contrast the features and developer experience of each,
Bill and I recorded a discussion earlier in the month. Expect it out mid-January. 😊
@@DeveloperVoices oh, sweet! That's so cool. Looking forward to it!
Thank you!
it was interesting to me (I"m not even close to the topic).
Well, that was epic. It’s a bold new world. Downloading Zig now and going hard on the tutorials…
I wish Andrew Kelly could come talk! His livestreams were always very interesting
Use the right tool for the job. Most startups have switched to Go for backend. Very small number of companies actually use rust for that.
Anybody can easily dive into go and pick up the idioms in sometime.
Zig doesnt replace that and it doesnt compare with Rust's maturity.
This is a fantastic talk.
instantly liked and subscribed. intriguing to learn Zig, although I have almost no knowledge of C yet.
Never knew Dave Murray could also talk about programming languages 🤣 Jokes aside, huge fan of the channel and this episode was great!
Excellent conversation. Would love to see more of these.
Wow, what a nice podcast to hear, thanks for this masterpiece, I'm on my way to get hands dirty with Zig! :D
Many thanks for the great discussion on so many wonderful topics. It would be helpful to further clarify what is meant by uses of the term 'complex,' 'complicated' etc.
great video. Currently deciding between golang and zig
Really great overview of systems programming and programming language design trade offs.
I'm not smart enough to use Rust. I think I am sold on Zig. Rust just is a huge undertaking to master where the language itself isn't part of the proble..
I was listening carefully about the stated shortcomings of Rust: I picked up on it needs to use some aspects of the C libraries for different platforms (is that a big problem though?), and it is a complex language (fair enough, takes a while to master it). I have been learning Rust recently and Zig came onto my radar for another language to keep an eye on. I did actually look at tutorial content for Zig but got a bit lost following it though.
So basically Rust is a safer C++ and Zig us a C competitor. Nice
@@skurtz97 Rust _is_ a systems level programming language and does not depend on libc by design. What depends on it is Rust's std library and all bells and whistles it is giving you, but you can choose to write embedded code with nostd modules and is de facto the mode Zig chooses by default, where you need to worry about everything on yourself. There is Redux OS written entirely in Rust and currently it is also an official second Linux Kernel language. It was also disigned to rewite Firefox in it (sort of, some parts were rewritten already), so you are right that it also targets C++ audience.
@@skurtz97 A lot of misinformation in this comment, but it makes sense as people don't have a deep understanding of Rust without using it. Rust the language, does not depend on libc. It can be compiled to target embedded environments and runtimes such as WASM, but it requires you to use rust without `std::` (the standard library). This is usually called `no_std` in the Rust world, and there's a huge ecosystem of crates around no_std for embedded and other such environments.
Anything that can be done in Zig, C, C++, or pure assembly, can be done in Rust. There are no limits at all to the language.
On Linux go doesn't have to use libc. It only uses it when you have to bind to it. Also go has a LLVM optional implementation
Apple should sponsor Zig and perhaps add themselves an alternative (or replacement) for Objective-C. Keep Swift for high level stuff (UIs, apps, simple servers, scripting, etc.) and Zig for high performance code.
❤ great interview! You have a really enjoyable and relaxing interview-style
Thank you so much!
Dang, I wish I knew as much as you guys. Fantastic video/interview/explanation.
Excellent conversation! I don't see any reason for replacing C/C++ - especially in regards to flexibility and speed + Assembler blocks can be put for some important parts. C+++copilot is the winner 4me ;) That is more productive than ugly Rust and questionable Zig. These are my two cents :D I can be wrong.
I use Go for command-line tools or web-socks. Docker and Kubernetes are mostly ready to Go products. The biggest disadvantage is that you can't do bare-metal machine-code with Go. There must be Os because of GC.Anyway because of how You're passionate about that I will give a try to Zig.
You don't see any reason to replace c/c++? You have never used c++
You should try to get Jonathan Blow to come and talk about Jai, the language he has been working on. I feel Zig and Jai have quite a lot of parallels.