zig is the future of programming. here's why. 

come learn about C and other languages at lowlevel.academy

You didn't even talk about one of the best features of Zig - seamless integration with C! It's really cool, you can straight import and start using C libs without writing any FFI.

After reading some of the comments my thought is "since when did programming languages become religions?"

One aspect of Zig I find so refreshing is how minimal it feels - you can comfortably go through the language documentation in a couple hours because there just isn't that much to learn. Zig comfortably gets so much done with comparably so few features.

If I didn't have Rust, I'd definitely be using Zig. For me, the philosophy behind Rust and Zig is what matters: we can make the compiler do more work for you, so why don't we? While I appreciate certain problems are so much easier to solve in Zig than in Rust, the stuff I write works really well in Rust, and it just clicks for me mentally.

Pros and cons of C: you can do what the hell you want

My takeaway: Learn everything!

Zig is the best C toolchain ever

Let's all agree on the fact that Zig has by far the best build system. It is literally built into the language itself. No more bullshit Makefiles, pkgconf or Ninja. Don't even get me started with CMake.

Zig makes low level development fun, accessible and productive

Finally you got zig-pilled :D One nitpick though: in zig defer operates on block scope, not function scope! Go's defer is function scope. Little, but important difference

what alternate universe is this where C++ don't exist?

Zig is definitely an amazing language, but there is so much you should have mentioned, maybe in another video, because as a C developer, Zig is really everything I wish C was. 1 - It's simple and easy to use. 2 - I'ts the most refactorable language (meaning you don't have to jump in 30 files fixing headers and function prototypes. 3 - Comptime is capturing 90% of the power of C++ templates/Macros, while still being very readable and type safe. 4 - The build system is insanely good, I replaced make/cmake with Zig, and with Zig itself it's really amazing. 5 - Zig found the right balance of freedom, meaning you can do exactly what you are doing in C (aka crazy casting and weird stuff unlike Rust) but at the same time the language design makes it very inconvenient and verbose to do so. Which makes it actually easier to just to the right thing and not take any shortcuts. So for once the Type system is actually one that doesn't deceive you because of how loose it is like C or how tight it is like Rust. 6 - Allocators are first class citizen. Even the Std is build around that which is amazing. I really don't get how a manual memory managed language like C didn't come with some form of interface for allocators. 7 - The interops with C is the most natural, intuitive, and straightforward that I've ever seen. You literally just add an @cImport("header.h"); and a exe.addCsourceFile("") in your build.zig and you are good to go. 8 - Zig also has integrated unit testing, which makes it so easier and cheaper to test code. In C I would literally spend 30 minutes writing some code and one hour testing it properly. In Zig you write a function write 2/3 tests forget about it and just do a quick zig build test and you are good to go. Which is also why it's so easy to refactor Zig btw. 9 - No hidden memory allocation, no hidden control flow, everything you read is everything you get, you don't have to guess whether this functions aborts, returns -1 or 0, or whether it sets ernno. 10 - The error handling and all the builting safety features makes it so much easier to write fast and correct code. I could go on an on but TLDR if you are a C developer you should definitely try Zig as I'm sure it's going to be the real C replacement. In System level programming.

Zig is nice.

as a beginner to programming, zig is my favourite out of all the languages i tried, i feel like i can read the standard library code and have an understanding of what its doing, unlike other low level languages where i cant comprehend anything others wrote , but the thing is , it feels like zig is dependant on C , you cant really do anything without importing a C library atleast from my prospective, also it feels like the community around it assumes everyone is coming from using C

Zig is for puppygirls, rust for catboys

that rare thing - a youtuber prepared to admit that they changed their mind subbed

When I get asked "What language should I learn?" I think the obvious answer should be C, because like you said the majority of systems is programmed in C and because Zig has still not reached 1.0 From my experience with Rust I can say that Rust FELT like a functional style programming language. It's focus on pattern matching, the immutability by default etc. It also has a lot of niceties of C++ (or some that C++ promised). But that means it also provides _some_ of the same footguns. Operator overloading, meaning that a line like a = b + c can be an unexpected heap allocation. I feel that Rust is the best language for programmers wanting system programming or high performance that come from functional languages or want many high level features. I feel Zig is closer to C than Rust is, like Zig has a "no hidden control flow" rule, it doesn't obfuscate how your data/ structs are on disk. I think it has a careful selection of features that make it nice to use for modern programmers. Especially: 1. An explicit error type, making it possible for a function to either return a value or an error, like you showed in the video. 2. A modern build system that doesn't depend on '#include's 3. Defer and what you didn't show errdefer. Making it easily possible to free resources on exit if an error ocurred. Formalizing the goto err pattern known from C. And being more powerful than Go's defer. 4. Very powerful tools to generate code and data structures at compile time. Even explicit loop unrolling with 'inline for' 5. Bounds checking and for loops over slices with a value and index My favorite feature is that alloc operations explicitly are an operation which can fail. Sure in most cases it's a hassle and I just bubble the error up but being able to properly react in the 5% of cases where I want to react to Out Of Memory situations feels very empowering. I think Zig has the possibility to become a very serious contender for the low latency, high performance and or system programming space, while I don't think it is taking many of Rusts users because of their different abstraction levels. But that depends on it becoming stable.

At first, I was suspicious of Zig, thinking it was just another pointless endeavor. However, after giving it a try, I'm now addicted to it. I've been able to accomplish incredible things that I couldn't achieve with other languages

Zig makes 1000% more sense for game dev IMO ... Dont want to be worrying about Arc when I'm just trying to do stuff. Zig's "reflection" is also amazing for game dev stuff like network\io serialization, GUI etc

technically, defer runs at the end of the current scope, not function scope. so if you have something like this: fn main() { { defer print("b"); print("a"); } print("c"); } you get this: a b c if it was at the end if the function it would be this: a c b if it ran at the end of the function scope rather than watever nested scope it's in, it would try to free a pointer that is out of scope, which doesn't work.

Nice video! Some good pros for Zig, and you didn't even get to its build system, which is arguably even more impressive in concept than the language itself.

Nim is also a system's programming language with optional GC

Zig's purpose is not a thing because "Rust is too hard", since it sounds like you are uplifting Rust to a new high. Rust is too restrictive and inherently doesn't trust the developer to write good code, which sounds more like the reason why Zig is an alternative. Zig's purpose is to be a modern C, that's it. Complete control over memory with more easily usable features like error handling and perfect inter-operability with C. And also, Zig's standard library is insanely clear and accessible. You get it out of the box in plain Zig code and it can be one hell of a tutorial in the advanced Zig features if you study the implementation of everything.

C++ is the best

defer not only "places" the code at the end of the function, but at all exit points (if there is an early return for instance) like a destructor in C++. (and the futur defer statement in C hopefully)

The reason to learn C is not to use it (much), but because it makes you understand the computer better.

I'm glad that you came back after a bit of reanalysis ... Zig is shaping up to be all sorts of nice and I really appreciate your walkthrough, definitely opened my eyes! Thanks!

In May, there is "the software you can love" in Milan. They'll speak about zig and system programming! I already took the ticket!

"you should learn all the things" You know I'm not gonna do that, Ed.... my brain isn't big enough yet

I think Zig also fills another role : it's a better alternative to unsafe Rust. If I have a Rust function I'm about to mark as entirely unsafe, I think twice and rewrite it in Zig. I think unsafe Rust has more footguns than Zig does, and has a much clunkier syntax.

I have to think about the video "Interview with Senior Rust Developer in 2023" from "Programmers are also human", where he said "They don't like 'unsafe' in my code, so just stuff it into macros"

Thanks for the left!right idea for errors. Really helped me be able to read Zig better!

can you change code theme when presenting? that red text is hard to see on the background color. at least for me since i'm a bit colorblind

I would also recommend Odin programming language, it is similar to zig yet feels different, people like using it for GUI applications, Game development,... The creator GingerBill is a friend of Andrew Kelly the zig creator, they influenced each other to make these languages what they are now.

Great video, I was just about to start my zig journey when I came across Odin. It's my first foray into low level/manual memory management and it's been really fun so far. I'd love to hear your thoughts on Odin as well.

quick mention to nim, optional gc, small binaries, and great interop with c code. great to look at, but struggles with a smaller community and worse documentation.

Is it just me or does it seem like Zig's syntax is weird for no reason? At 6:24 he mentions how you can think of running the openFile() function as going left or right. When you go left, the success result is put into f, but when you go right you catch the error value. So then why is the return type std.fs.File.OpenError!std.fs.File. Why is the right on the left and the left on the right?

Again with the fire videos!

Another important thing to remember about Zig is that there are a lot of applications where completely memory-safe code simply isn't as important, and other concerns come first. An example I'm very familiar with is software video encoders; nearly all are written in C because the #1 concern is performance. Zig would make an ecosystem around developing one of these much more accessible, and give devs the tools they need to catch problems earlier & write code more quickly.

I hope you take a look at nim some day. Many of the zig features you've mentioned are also in nim, and it has many more that I would miss in zig. It's more high level than zig, but at the same time very low level when you need it to be.

My favourite feature is comptime. You can run piece of code at compile time, and with this you can generate more complicated arrays of data.

im dipping into zig after 15ish years of c# and java. its definitely a weird switch but im eager to expand my skillset into systems level prog, even if i dont do it professionally

Zig is an interesting option I really need to try out at some point, I've seen some interviews with the creator they make some really good points.

Hello and greetings from a fellow low level programmer. How are you doing? I have spent close to a decade on assembly language programming of proprietary DSPs either directly or by way of analyzing cross-compiled disassembly. I really appreciate your efforts in educating the general public about low level coding. As we know it, it seems scary and may be it is to some extent, but its amazing with lots of scope for creativity.

I hate to be one of these people, but you should check out Odin if you haven't. It seemingly fits in a similar place as Zig, but with a completely different mindset. I like that in Odin, you have access to allocators and calling conventions, but they aren't forced on you; you can just call new and use the default allocator.

I think the most uniquely-zig thing is payload capture. There are also, of course, comptime/defer/undefined/slices, but the truly innovative payload-capture invention deserves the chef's kiss.

Regardless of what language is practical, they probably won't employ as much Zig programmers as C programmers for a long, long time.

Rust philosophy: make it hard to write bad code Zig philosophy: make it easy to write good code

I mean, when talking about system languages saying that we are not going to talk about C++ in here is like saying "let's talk about GPUs, but not you NVIDIA" :)

Hey, I'm thinking about learning C to build my own data structures and algorithms, plus get into some networking (like TCP and chat apps), and maybe touch on graphics with OpenGL or something like that. I want to grasp some fundamental skills that you don't usually see in JavaScript or PHP projects. Also, I’m curious about how rendering works and want to get more into algorithms. Do you think Zig might be a better choice for diving into this stuff instead of C?

As complete beginner in low level programming after high level on java and js it was really nice to program in zig, because its compiler says where I made a misstake, in C I just got error code and that's all. Also modern syntax feels refreshing and enjoyable.

As a Java programmer I'm mot a fan of forced exception handling. I'd rather have the choice to not do it, or not do it right then and there. Java has evolved and the standard api is also moving away from checked exceptions in lots of cases. Having it in the signature of the function like zig has looks quite neat. Will surely look into it.

Not a big comment guy, but I just want to say, your presentation has got so good, some of your early videos sounded fascinating but were a bit jargon heavy. Now, frankly, I watch pretty much every LLL video that comes up in my feed even if I’m never gonna use them or maybe even never gonna understand 👏 👏 👏

Not doing dev anymore but coming from a VHDL, firmware, bootloader, kernel background and after just playing with the zigling "tutorial": this is the language I would have like to have during my low-level dev phase. It seems to make all the dangerous things quite visible and therefor controllable... I hope to see this language used more in the future (besides nim.... ;-) )

Not gonna mention holy C or C+ :p

I really love your cybersecurity stuff, it's the future, dude

As much as I wanted to like Zig and use it as a C replacement I just couldn't. I found that it added "too much" to the language and had overly verbose syntax (I would rather just use Rust at that point). When I compared it to Odin, I found that Odin was just simpler overall while still giving the benefits that Zig has (no hidden allocations/manual allocators, range-based iteration, sized arrays, better error handling, etc). Zig definitely has a lot more momentum behind it now with the release of tools like Bun but I would really like the ecosystem with the better tooling (especially the LSP), MUCH simpler syntax, builtin linear algebra, and a style that feels like what C++ *should* have been to take off

it really depends on what domains you want to work on: embedded systems: zig games: zig webdev: zig os: zig c: zig networking: zig automation: zig

I really like the idea of Zig, but coming from a JS and Rust background, I found it really hard to work with. Maybe it's because I'm running on Windows, but it seemed like a lot of the examples I found online required a lot of workarounds (or were simply out of date) and a lot of the docs were missing critical info to get over those roadbumps.

The C++ answer to all of the features mentioned here: Allocator: fully supported by all stl containers Defer: RAII (destructor) Error as value: C++ std::expect + setting compiler flag for checking switch case missing case Out of bounds check: use .at to access containers, or wrap raw buffer into span and then use .at

It's one thing for Zig to improve and modernize C whilst still keeping the language small and lean, that would make it a great lang on its own. But then comptime... honestly its the best approach to generics I've seen, and it happened by accident! Best lang 10/10

You finally played Zerowing, huh? That's why Zig exists.

I'd love to see more zig content, maybe a video comparing zig to cmake or premake for building large c(++) projects

Hold on, why are we not talking about C++? Did I miss something?

Nice overview of zig. I never bothered to look into it before.

Hi! I have to choose an OOP language for my uni class I can choose between C++, C# and Java which one would you guys recommend and why? Thanks!

I'm totally in love with Nim, but Zig looks great.

can you put zig in the title please ? not everyone can see the thumbnail

CompTime is also a pretty sick feature. You could have a function that creates an array with the 1 million first prime numbers and have it be computed at compile time instead of runtime

Ummmm 1:40 no D mention? The better Go? Where you can turn off the garbage collector and with better generics?

Lol I want to know about c++

I wonder if you have an opinion about D(lang). I do not understand why it never took off.

The main strength in Zig is the comptime, it's also it's main weakness - since any code can execute in a comptime function, this any code can take as much time to execute as it needs, for this reason, often times the LSP simply gives up, and essentially renders itself useless. Another is the thing with lazy error reporting, it's really, really annoying during development time. I want to see my errors the moment I make them, not only when I call the function.

Been doing this a while - the only thing I'd automatically start in C is not a project, but a class of actual computer science students - for two reasons: 1) to later appreciate every other language and what they bring to the table; and 2) to have the beginnings of an understanding of how the machine works and a basis to read kernel code.

For Linux enthusiasts, C is often preferred over Rust due to its simplicity and speed. In C, one can directly use functions like dlopen() and dlsym() to dynamically import binary libraries and call existing functions without the need to recompile the code each time. In contrast, Rust requires compiling all libraries from source each time, which is necessary to satisfy its borrow checker requirements. This aspect can be frustrating for some users. Cheers! P.S> I pick Go despite I like Zig and Rust but I decided to learn them one by one.

Would be cool if you checked out Odin as well. Its quite similar to Zig but in my opinion more ergonomic/readable and at least on the language side more mature. Doesnt have as much traction and a smaller community tho.

I really like the concept of comptime in zig. It seems really powerful

5:27 I feel like this wasn't as accurate as it could be, defer guarantees that a line of code or code block will run on exiting the function, whether the function errors or returns. (correction) defer runs at the end of a scope, so if defer was made in an if statement it will run at the end of said code statement, even if an error occurs.

Zig? For great justice, obviously.

At first I really liked Zig, but later came to realize that I much more prefer C. C is so much more simple, which means less bugs in the compiler and easier to understand. You can hate headers, but it generally means less compilation, and you don't need to use a browser to look at the interface and documentation of a module. If only more people used C without libc.

Something I like about 5:35 , is that it's like a mix (a "math product", if you will) of Rust's `unwrap_or_else` and `match`. 7:40 is interesting! It looks like an implementation of an iterator in C, but behaves like a `for` in Go/Rust. The `next` method is called explicitly, instead of being sugared. `while` seems to be capable of using an `Option`/`Maybe` as a condition where `Some`=`true` and `None`=`false`. The (unwrapped) value of the `Option` is concisely bound to the variable `chunk` without the need for an awkward "assignment expression" (see Python "walrus" operator)

As a C++ dev, Rust sucks but Zig comes close to what modern C++ offers you without any bullshit.

One of the few sublime text users that are left, Respect!

Is Zig suitable as a first programming language? Is it worth investing your time in it?

I haven't tried Zig before, but I have tried Rust and wrangling with the borrow checker is SO FRUSTRATING!!! Zig, which doesn't have a borrow checker, seems like it lowers the barrier to entry for a modern C alternative, making it easy to write fast but safe code.

The way you talked about garbage collection vs malloc has the potential to be misunderstood or taken out of context. I think you mean that malloc/free are "deterministic" in the sense that you can point to a specific given line of code where the allocation and de-allocation take place. (Though, with smart pointers, deallocation can easily become non-deterministic, even this sense.) But usually people use "deterministic" in a more restrictive way. Normally, you'd say that malloc/free are non-deterministic in that they can take an unbounded amount of time. In a long-running application, you could end up with fragmented memory, and all kinds of other crazy things could happen when you call those functions. So they aren't real time safe and shouldn't be called from code that needs to make real-time guarantees. As a general rule, if you need deterministic memory usage, you have to allocate everything statically, or at least right at the start when the system turns on and then never again. In such systems, you don't use dynamic memory. With that and a few additional restrictions, you can calculate exactly how much stack space and other resources you need to handle the worst case scenario. However, there are a handful of situations where you do need to manage memory dynamically in a real-time system. As far as I am aware, the only known general purpose techniques for doing this wait-free involve garbage collection algorithms. (The same goes for lock-free approaches.) 5 years ago, I'd have said that these use cases were so obscure that they weren't worth mentioning, but so many consumer devices now have real-time components and mixed criticality workloads that this isn't a specialized topic anymore. We have cost effective multicore embedded SoCs, and even extremely cheap single core processors can get by with the "speed" of interpreted Python. Hardware features like transactional memory support are becoming more broadly available too. So, I think that we are going to start to see real-time garbage collection algorithms out in the wild before too long. Even if people aren't using specialized real-time algorithms that need them. If you need the real-time code on a camera or a drone to interface with a system to communicate with people's phones over bluetooth, that's going to force the issue, especially if devs want to use normal open source software libraries for the non-essential portions of their code even if those libraries weren't written with real-time systems in mind. I haven't found a "good" set of tools that supports this type of development, but maybe Zig will be the language to do it given how explicit it is about passing allocators around.

I like Zig a lot. While trying to understand computers at the low level, it's been more fun exploring it with Zig. Rust has too many abstractions, assembly has too little abstractions, C is close but has a lot of warts. Zig feels just right.

"I love that it makes me check every error type" says no one who ever knew Java and checked exceptions.

The best idea of zig for me is the build system, unlike CMake nor Meson you don't to learn a new 'language' for it, you can apply complex control flows in your 'build.zig'. To me, it feels like Terry David's HolyC, it's next-level design.

I'm genuinely curiously, why won't you even get into C++? As someone who learned C then Rust and is now learning C++ - I don't understand all the hate. Subjectively, I don't think it is that bad. Sure you can shoot yourself in the foot, but that's not easier than in C. As I'm doing scientific computing, I find C++ is often more flexible and adaptable for my use cases. I don't have enough experience with Zig to have any opinion on it except it looks cool, but not ready for use yet.

He forgot to mention Nim as a language that uses no garbage collection.

I really do see the potential for Zig. I'm just learning it now, more for curiosity than professionally. defer is great, but the plumbing exists to defer immediately when reserving your memory, why not have it flow as one expression? get your pointer and have it automatically marked for collection or don't by omitting defer. maybe there's a plan for it somewhere in the language roadmap, but I've written enough boilerplate in my career that even 1 extra line that can be eliminated down to 1 extra keyword on a statement makes me a little irritated. Do something else like have it be implicitly deferred collection and a tail call reference return prevents the defer, or a different return like "refreturn" that marks it as collectible by the calling method. maybe that goes against the explicitness that Andrew Kelley is trying for.

I adore it and I see it as definite language for new “C” projects. And definitely great no awesome for embedded. And C developers will build so much faster in Zig than Rust.

Hey LLL - what kinds of small projects work for someone who wants to get started with specifically systems dev?

I feel like you could just disable the GO garbage collector if you really needed, not sure why you would use zig instead of go

Ok but does zig also make error handling a hell where adding one error check infests every layer of your program and your function values become confusing errors that you spend half a day trying to unwrap for some meaningful result.

The zig compiler is a god-send for generating statically-linked binaries and cross-compilation.

How does Zig compare to Odin in your opinion? (PS: I'm a Rust fan-boy.)

Why not C++? I'm just curious, is it actually that problematic like the "blow the entire leg off" meme?