Interview with Zig language creator Andrew Kelley

Code: github.com/contextfreecode/zi...
Zig documentation: ziglang.org/documentation/mas...
0:00 Topic
0:13 Demo
2:10 Introduce
2:20 History
3:05 Competing with C
3:52 Standards
4:59 Zig Software Foundation
5:56 Keeping up with LLVM
6:46 Idealism
7:20 Stack overflow
10:08 Async vs hidden control flow
11:26 Memory safety
12:49 De-init
13:55 Compile-time execution vs static analysis
16:00 When is 1.0?
16:16 Interesting software in Zig
16:55 Future plans
17:14 Closing words

[@contextfree]

Thanks much to Andrew for the interview! Also for his kind words at the end. I wasn't expecting that at all. And if you like the video be sure to subscribe. Bye y'all!

[@gideonunger7284]

Well it is really good content. The focus on concepts and how they manifest in the languages rather than just looking at the languages in isolation is super valuable. I think its a great learning resource for medium to more advanced programmers that want to learn and venture out of the one programming language they already mastered.

[@edwarddejong8025]

How about an interview on the Beads language?, which is a general purpose language that is designed to built web apps, mobile apps, and desktop apps with a single language. It is a higher level language than Zig, intended for making graphical interactive software. Certainly a very fresh break from OOP paradigm. Beadslang.com (don't have that 501c3 yet!)

[@gautamgoel4851]

He seems like a really cool, down to earth dude.

[@CristianMolina]

Thanks a lot for this video! Do you have in your agenda an interview with V language creator?

[@contextfree]

@@CristianMolina I haven't talked with him yet, but I'd like to coordinate something during this year with him. Also with Ginger Bill on Odin.

[@ConciseCabbage]

As someone with near zero low-level programming experience, I'd LOVE a book or course that taught these concepts using Zig instead of C.

[@aleksei5172]

But why? C is a very simple language and comes without any sort of syntax sugar. That makes it ideal for learning low-level stuff because syntax sugar usually hide some "boring" details that could be important for understanding a topic.

[@ConciseCabbage]

Алексей - what syntax sugar does Zig have? Semantics is not “sugar”. As to why I’d like to learn with zig: because I’d actually make things with Zig. C might be good for learning, but I wouldn’t trust myself to make production software with it. There are too many “gotchas” with C.

[@_slier]

@@aleksei5172 header file? no way jose!

[@jawad9757]

C is probably a better way to start off, the things wrong with it can teach you a lot

[@Cons-Cat]

@@jawad9757 Yeah man writing #define min(x, y) y > x ? x : y; is basically equivalent to getting a Ph.D!

[@AbhinavKulshreshtha]

Thank you Context free for providing us with "context" on their work.

[@thedracle]

A very clear, reasonable, discussion about the relative strengths and weaknesses of Zig. I still make use of C often because it is more ergonomic and clear than unsafe Rust. Zig could fit that niche very nicely.

[@Iridescence]

I definitely threw myself head first into Zig, but after almost a month and 5-10k lines later, I really love this language!

[@stuffedk]

Interesting interview. I wish that besides your prepared questions, you would have taken the opportunity to ask follow up questions, given that this was done live. I would have watched an hour of this

[@jeremy21212121]

Great interview! I like the way you used visual aids, it really adds depth. This channel deserves to be immensely popular, if that is what you are going for. I never browse youtube while signed in, but I felt compelled to subscribe. I don't watch much programming content on youtube, as so much of it is targeted at beginners, but your videos are pure gold.

[@sanderbos4243]

Your questions and browser tabs in the background were top-notch, thank you so much!

[@Nathankthanks]

Love the accompanying visuals! Makes for a really enjoyable and accessible interview

[@ManuelBTC21]

Congrats. I think you have created the best video to introduce intermediate/experienced programmers to Zig.

[@taylorallred6208]

I've watched Andrew give talks about Zig and I've been impressed how he comes up with unique solutions to problems in the C space. I got the same impression when he was explaining his solution to the stack overflow problem. Just heap allocate the stack! Genius! It did make me wonder, though, if he had considered adding an option for tail-call recursion 🤔😄

[@progrockkeyboardist]

Allocating stack frames in the heap is “business as usual” in some functional language implementations, e.g., I think SML/NJ. But of course there it is done magically by the runtime system, rather than in a programmer-controlled way as in Zig.

[@Elite7555]

Well, that isn't so new a solution. Also, any recursive algorithm can be translated in a non-recursive algorithm, which is preferable.

[@maxwellclarke1862]

Thanks for another great interview. I really enjoyed the discussion about compile time code execution interfering with static analysis. Great to hear the creator of a language talking about it's tradeoffs.

[@mouduge]

Excellent interview, and nice to see all the pointers in the background, thanks!

[@uncoherentramblings2826]

YEEEEEEEEEEEEEEEEEES!!!!!!!!! Waited so long for the episode with Andy.

[@themagpie9able]

Can we have a shout out to your browser for handling so many tabs! Haha another great interview, please keep doing them!

[@itellyouforfree7238]

you have never seen my browser... 3 windows, with over 100 tabs each... i want to die :/

[@ekremdincel1505]

@@itellyouforfree7238 same

[@nickschmitt8594]

this is sooo cool. Incredible video and incredible interview.

[@artanik94]

I want to say thank you! I really appreciate your work. This is, by far, my favorite channel about programming languages. I've seen probably most of the videos on this channel and notice that almost every topic here is about statically typed compiled languages with a few exceptions, and about types in general. Which is good, they are more practical and the range of topics is still incredible. I guess someone has already asked about this before, but I want more diversity and videos about functional programming. About LISP (CL, Racket, Scheme, Clojure). About Scala, Haskell, SML, and OCaml. About type inference and Hindley-Milner (or Damas-Milner). Or about "exotic" like APL. Btw, I was confused when I saw a capital J in some thumbnails because one of APL's dialects called "J" is using a similar logo but with a different color. But it was Java, not APL's dialect J. IMO it's better to use the classic "cup of coffee" for Java :) And it would be nice to have a list of links in the description, like in the previous video, that was mentioned here :) (I guess this is not a case in today's video because there is so many links) Thank you!

[@contextfree]

Thanks for the feedback! I hope some recent inclusion of Haskell and F# has been interesting at least. I also want to spend some time learning Idris and Agda, but time is limited. Finding good balance isn't always easy. But I still appreciate the feedback. And I mostly avoid the coffee cup as a protest against Oracle.

[@marceloccnv]

3 years now, Where is my 1.0 Andrew? (Joking, I love zig and I think it should take it’s time to become the greatest)

[@oof-software]

Awesome video, thank you!

[@slmjkdbtl]

good interview genuine guy love it

[@Narblo]

Awesome interview and really nice fellow

[@shayneoneill1506]

I hope these guys succeed. My favorite language of the past decade, Crystal, appears to have fallen on deaf ears and thats a damn shame as it solves SO many problems with its type system. Alas, as the parable of VHS vs Betamax teaches, the best answer isnt always the one that succeeds. best of luck!

[@codenamelambda]

I honestly really like Zig. The only two things that I wish would be added are some memory safety proving facilities (esp. considering that it can be somewhat conservative, I personally don't view unsafe in Rust as something bad, it's just what you use when you cannot prove memory safety to the compiler; and I don't think that having to mark such places is a good reason against implementing such features) and pattern matching like in functional code, including pointer dereferences. The first one especially is a huge reason I cannot in good conscience invest too much in Zig, given that Rust provides that (and the second one, too) already, though it should be mentioned that as much as I like type classes, Zigs compile time capabilities and honestly just elegance are something that I absolutely love. I wish there was some weird hybrid of the two that addressed my issues, honestly.

[@AndrewKelley]

Heap allocations just became safety-checked if you use the std lib GeneralPurposeAllocator. There is a plan to make stack allocations safety checked as well. You can follow this issue if you want updates: github.com/ziglang/zig/issues/3180 Once that's done, Zig will be roughly as safe as Go, with some caveats.

[@imzoltan]

Static verification... say no more: Ada/SPARK.

[@olehdevua]

the lack of two features described by you is probably main reason why I considered Zig and not Rust. So, please, don't make Zig to be Rust. If someone like Rust features, just use Rust.

[@codenamelambda]

So, for one, I don't mind having static analysis even outside of the language, or using existing features to implement it (in fact, the second one would be pretty great). And dereferences in pattern matching could be marked, to show that they are exactly that - though that seems hard given how the syntax works currently. Though, with better anonymous functions, this one could very easily be implemented in Zig code as opposed to the compiler. That said, having such features (that each don't really have any harm, if you differ I'd like to hear the reasons for it), especially optionally, is not a bad thing, I think. My comparison here is Rust only because it's the language I know that does have those features - so just arguing that you wouldn't want it to be closer to Rust doesn't really address the issues I personally have. That said, the best case scenario would be if both could be somewhat painlessly done without special features in the compiler for them, but with the necessary compile time machinery to achieve them to a satisfactory level. And I don't think that extending what makes Zig stand out so much (among very coherent design & general simplicity that is honestly surprising given the power Zig gives you - and I don't mean the power to do anything, but the power to be expressive here) is a bad idea at all.

[@olehdevua]

@@codenamelambda > And I don't think that extending what makes Zig stand out so much is a bad idea at all. I have no enough motivation to elaborate. But I would like to say the gist. Every language feature impact the way you write code, enforces different patterns, trade off and style. And even if some feature is like "it useful, Rust have it, it's easy to add, you not obligated to use it". And it seams like okay, eventually it impacts how developers write code. And it impacts you, even if you not obligated use this feature. For example I'm not obligated to use Rust macros, but eventually I enforced to deal with its complexity because other developers write it! And also it impacts compilation speed, IDE responsiveness, etc ... so, I't impacts my language user experience. So, as you can see, even If I don't personally write any single macro in Rust , it impacts me as Rust developer. And so happen with every "cool feature".

[@ShakirovRuslan]

Additional option to deal with recursions is Tail call optimization.

[@TravisTennies]

Excellent

[@Chillingworth]

This is a dumb question, but what mouse are you using? Its click sounds extremely familiar and it's killing me.

[@contextfree]

It's just a cheap Amazon Basics mouse. And I've often used cheap Logitech or Microsoft keyboards. Nothing fancy.

[@arjunkandaswamy1532]

when will be zig ready for production?

[@edgeeffect]

Up to this point, I've been thinking "who needs Zig if we've got Rust"... but it still sounds interesting enough to watch... and anyone who wears a VNV Nation T-shirt has got to be alright with me.

[@OMGclueless]

Hi Context Free. Could you do a video some time on aliasing and how various languages handle references that alias? I often hear people say that Rust is just as powerful as C or C++ if you allow the use of the "unsafe" keyword but there are some things that are impossible to express even in unsafe code because in Rust it's undefined behavior to create mutable references that alias.

[@itellyouforfree7238]

but you can use mutable pointers. creating those is not undefined behavior. it's UB only if you use them wrongly, just like in C

[@OMGclueless]

​@@itellyouforfree7238 Yes, that's true. What's different is that there are some things that are UB in Rust but not in C. For example, creating two pointers to the same memory location is fine in C and you can write to either (unless you write to them concurrently). But creating two mutable pointers to the same memory location in Rust is UB even if you use the 'unsafe' keyword and only access them in sequence.

[@itellyouforfree7238]

@@OMGclueless That's incorrect. It's UB to create two aliasing mutable references (&mut). It's not UB to create two aliasing raw pointers (*mut), just like in C. Using them incorrectly (like dereferencing when you can't) can cause UB.

[@ekremdincel1505]

@@OMGclueless You have a misunderstanding. Think it this way, a reference in Rust is a restricted raw pointer in C. A raw pointer in Rust is just a raw pointer in C. And there is also UnsafeCell that allows you to bypass some aliasing requirements by disabling some optimizations (note that using UnsafeCell in Rust is equilivant to using raw pointers in C, so even if you lose some optimizations it is equilivant to the "idiomatic C")

[@thingsiplay]

2 years later, the v1.0 is probably 1 year away.

[@Little-bird-told-me]

For some reason i want to subscribe

[@zungaloca]

rela nice

[@hassan.canada]

I didn't know that Zig project is a hubby project. This guy worked very hard to create Zig.

[@contextfree]

He gets an income these days, but not a huge one.

[@keiouji1629]

I am thinking of switching to zig...if.... To help move Zig, can we call the Jr Devs "Zig Pilots" and the Sr Devs "Zig Commanders"? It would be for great justice.

[@ahmaddynugroho]

16:06 what? could this year be?!

[@TheMrKeksLp]

No automatic deinit/destructor/drop calls is a real bummer. I understand that with Zigs very loose control over memory allocation, object initialization and so on it's hard to implement since the compiler itself doesn't really know when something has actually been initialized and needs deinitialization, but still. I wouldn't want to miss RAII in a programming language, it's just too powerful not to have

[@mlugg5499]

The more you write Zig, the less you miss RAII. I think there are two main reasons for this: 'defer' and arenas. Zig has a 'defer' statement, which can be used to run code whenever a scope is exited. In practice, this is very useful for resource deallocation, because you can do e.g. 'var f = try std.fs.cwd.openFile("file.txt", .{})', and then immediately after 'defer f.close()'; since you write it immediately after it's pretty much impossible to forget (you quickly get into the habit of deiniting any 'init' or 'open' or 'create' call do), and you don't have to deal with the C issue of making sure every damn return path frees your resource. The second (and imo most important) thing is arenas. Of course, one of the most common RAII use cases is freeing memory: in C++ I can make a massive nested datastructure and know it'll all go away once it goes out of scope. Handling this whole thing with 'defer's and explicit deinit functions would definitely be inconvenient. However, there's a solution! Zig doesn't have a "default" heap allocation function (like C's 'malloc' or C++'s 'operator new'); instead, you explicitly create an allocator (there are a few common options in the standard library) and pass a pointer to it through function calls that need to allocate memory. A consequence of this is that mixing and matching types of allocator becomes very natural. In particular, Zig has really good support for arena allocators. These are allocators which allocate memory in a big block (never freeing individual allocations even when you ask), but which you can then deinit to free all the memory at once. Zig has one in the standard library, called 'std.heap.ArenaAllocator' - it wraps another allocator to acquire the underlying blocks of memory, and provides the standard allocator interface so you can use it as normal. It's very standard in Zig code, when you're working with big datastructures, to allocate everything into an arena, and simply deinit that arena when you're done; for instance, if you're parsing a huge datastructure, you would just allocate each individual struct into one big arena so you can free them all in one go. Not only does this solve the problem, it also has the benefit of being (sometimes significantly) faster! Traversing huge datastructures to free them can take a while - this is particularly unpleasant under RAII, because you can't even see the control flow but it could make exiting some scopes quite expensive. Deinitializing an arena is relatively fast, since all it has to do is free the underlying memory, which just consists of a handful of blocks. So the lack of RAII here actually ends up encouraging a pattern which is easier (you don't even need to think about whether the RAII will work!) and faster.

[@pavelperina7629]

Hmm. I guess recursion can be solved. I've done it myself, not because of stack overflow, but because of profiler. I traversed tree and profiler showed me how much time is spend at each depth. So I decided to use std::vector as stack (std::stack is slow, cause it's basically std::deque with removed pop/push_front), push arguments of first call into it and then there was something like stack.push(node); while(!stack.empty) { Node n = stack.top(); stack.pop(); do_stuff(n); for (child : n.childs) stack.push(child); }. It worked as fast as recursion (childs must be pushed in a reverse order)

[@AGeekTragedy]

Isn't knowing how big a stack you will need when you start a recursion something you famously cannot do (in general)? That was the point of the Ackermann function, right?

[@contextfree]

I'm not fresh on the Ackermann function, although I expect determining stack size statically and perfectly in the general sense would likely be equivalent to the halting problem. I already forget the specifics of Andrew's answer here, though.

[@jeremiahglover7562]

Recursion can only be used in special cases where the maximum recursion depth is well defined. Like in merge sort, the max recursion depth is log_2(n) where n is the number of elements.

[@andrewlei2980]

I didn’t know Dolph Lundgren made a programming language as well.

[@germancubesolveryolo4524]

Andrew looks like if that speedrun raging dude was sent by cyberlife

[@codebitcookie8053]

This is so accurate lol!

[@codeitlikemiley]

Whats the Difference of this with Rust or Vlang?

[@codeitlikemiley]

answer: kzbin.info/www/bejne/kKfWnHelhZVsd9E :)

[@TheMrKeksLp]

I'd say Zig is a lot less high level than Rust, it tries more to be a C instead of a C++ like Rust does. Compared to V? Well, V is pretty much a known scam at this point, you should treat it more like a curiosity than a serious programming language

[@classone2010]

Rust didn't give up programs that doesn't pass mem safety checks. It requires programer's promise to do the safety checks by annotating the code with 'unsafe' keyword.

[@stephenkamenar]

5:43 so basically he doesn't have to pay taxes on donations? that's cool, didn't realize you could do that

[@PaulJimenez3]

He does if he gets paid by the Foundation, just like getting paid by anyone.

[@DevonBagley]

Zig software foundation exists because paying taxes on all of that money was painful.😅

[@FPChris]

Not crazy about the syntax. :/

[@user-ov5nd1fb7s]

Interesting language. However, i don't see myself using it. Rust gives me everything that i need to build the software i want. I would rather sacrifice a certain way of implementing things than having memory corruption and concurrency violations.

[@psychotherapeuticprogrammi4619]

It is really immature of people to not study other programming languages before making their own, their heading towards failure. "In C++ or C conditional compilation is done through macros."! No, "if constexpr"!

[@onursahin7970]

C++ has constexpr but also supports macros. Thus any IDE supports c++ must support work with macros. Having an alternative doesn't solve the problem.

[@psychotherapeuticprogrammi4619]

@@onursahin7970 I am not talking about the IDE support but rather the language design. You can use pointers ad integer types but that is not what pointer are designed for. Same goes for macros in modern C++. You can use macros for conditional compilation, but that is not the C++ way of doing things.

[@onursahin7970]

It is not the c++ way but they are allowed in c++. Thus you need to take them it into account when you develop static analyzers. Having alternative doesn't remove the problems of the older solutions if you have to support it too. Therefore they are also problem of c++.

[@homelessrobot]

the existence of constexpr does not mean you can escape macros. Legacy older than 2011 and anything trying to be portable beyond compilers that actually support c++11/constexprs will use macros. Zig is written in C++. He's well aware of what features exist in c++, but 'modern c++' is not most of c++. You do not escape bad legacy by just piling on more features.

[@apestogetherstrong341]

@@psychotherapeuticprogrammi4619 I don't like C++ because it gives you more ways to do something, and has to trust the programmer to do the right thing.

[@stevenhe3462]

Amazing how this powerful language is created by a seemingly somewhat incompetent individual!