hey, if you could price your course better it would be great for us students. Im struggling to pay accomodation and my car payment (i need it to get to campus) but a student plan would greatly help but currently i am unable to afford your courses so im stuck with your generously provided free youtube content. I want to support you, but i need to support myself first :(
Hey LowLevelLearning, you should probably include zig in the title of the first video about zig, I had the use youtube's channel search function to find it.
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.
This is what I was excited about, but when I started looking at using it for a pet project I started noticed that most folks still ended up writing bindings for common libraries anyway to get around issues with C APIs not being descriptive enough in some cases. Kind of ruins the magic. :(
"You didn't even talk about one of the best features of (C++) - seamless integration with C! It's really cool, you can straight import and start using C libs without writing any FFI." - lol
@nikkehtine nah, not so much. Lots of legacy stuff/knowledge issue with the language where you just have to know what it does by reading the specification exactly. Rust and zig are a bit nicer where I don't think there is not nearly as much oddities you have to remember and are more explicit on what they do.
Zig is the same except it asks you to explicitly tell it what the hell you want it to do while C can do things you didn't mean behind your back if you don't know any better.
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.
Agreed. I just wrote a microservice yesterday in Rust that takes a netcdf file and cuts out a subregion based on a geojson "selection". I've been writing rust for 4 years so I kind of knew what to expect, but I was still shocked when all the tests passed on the first try. I was so happy that I went bragging to my colleagues for the rest of the day 😅. And because it's rust, all possible errors have been handled gracefully and I don't have to worry about race conditions at all. Granted I used quite a bit of well-tested third-party libraries, but still there were about 1000 lines of my own code. I'm pretty confident when I say that had I written it in any other language (Go, Java, Cpp, or god forbid JS), debugging alone would have taken me at least 2 days.
@@catto-from-heaven True, if you can fight the compiler. I played around with Rust for a few months then gave up. If more devs adopt it, and it's taught in uni, it might have a future; same with Zig. Otherwise not and with AI on the horizon it might be moot.
@@raylopez99Except it's not moot. If AI becomes as good a programmer as everyone thinks it will be then we can just abandon all languages because the godly AI will program everything directly in fully-optimized machine code. At that point, maybe everything is moot. We can just abandon our jobs because the AI will do everything and give us UBI
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.
If you've read "PHP: a fractal of bad design", you'll notice some obvious parallelisms between the PHP community and any cult/sect/religion. This also reminds me of the joke "Cult of Vim VS Church of Emacs"
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.
I've been re-making a C project in Zig, started with a dumb 1:1 port and have slowly been implementing safety features and metaprogramming. It's pretty amazing how much more readable code becomes when you don't have to rely on 30 helper functions to extract data from packed structs like you do in C or Go
@@mgord9518 Yes that's for me one of my favorite features of the language, is just how much readable it is, at doing what you would do in C. One example that I love is logging. I'm a sucker for logging things to a file as a mean to debug, in C it's cumbersome, and you can't really use printf unless you also use fflush and all that jazz, you have to change the %_ to do anything, or you have to write your own implementation of printf, and even that is tricky and annoying, in Zig, you just implement a format functions, and you can call that type format function it's very easy and, with comptime you can automate that process, and basically recursively check the type of the field at comptime, to see whether it has a member called idk print, or if it's a simple type just use {any} with it it's really amazing..
hello thanks for this review of zig and how it helps you. I'm curious to know how much does the zig compiler help prevent data race related bugs due to concurrency & also identifying or prevention of memory leaks. If possible please help it by comparison with rust/golang thanks.
also defer is so good, the video doesn´t go into detail but also it is made to substitute the goto: error pattern you would sue in C when you need deinit/deallocs. It is just C but improved for me
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.
Honestly, that sounds like Go 8 years ago. Or every sane language during their early years. It’s a fundamental law that the older a language gets, the more docs and features it will have.
@@fr3ddyfr3sh Sure, in practice some amount of that is inevitable - but to offer a reply to your example: Generics in Go needed to be a new feature added to the language. In Zig, the feature that was already there, comptime, is so powerful that it produces generics for free. Same for interfaces (as awkward as they currently can be). I don't want to get too hung up on this as a be-all end-all of how programming should be done, but it is my takeaway from the language in a comparable way to how I believe Rust popularized to many people what a modern typesystem could feel like.
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
@@immige9216 I confess that my real fantasy for Zag is to be a subset language of Zig that can be a Turbo Pascal like programming IDE that can run directly on 8bit and 16bit retro computers - or modern retro themed computers like the Agon Lite or the Commander X16. To do retro games development, of course. But where would be the fun in that if it didn't run directly on the target computer. 🙂
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.
Rule 1 of low level programming, we don't talk about C++, Rule 2 of low level programming, if we're trying to find example, pretend everything was written in C
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
Yes, for that you need something with real control, instead of giving you bits and pieces always wrapped in some insanely complicated proprietary memory management system like Rust.
@@andrewdunbar828 Yeah, the builtin Quat, Vector and Matrix types in Odin definitely helps with ergonomics. Also the context object to pack allocators and debugging tools into. I'm sticking with zig for now, and having a good time with the killer zig features so far, though the ergonomics aren't as good as Odin
@@heavymetalmixer91 You can pack data into structs and give them methods --- the best parts of OOP :) If you want interfaces and inheritance, it's not a first-class feature, you'd have to use anytypes and make some (arguably cool) comptime code to build up those concepts again, you'd get worse tooling and the community isn't generally impressed with it
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.
Which is pretty amazing considering that C is 50 years old and hasn't figured this shit out No reason I should have to install gigabytes of libraries for other architectures when I just want to link to them
@@matteo.veraldi You can use Zig as a replacement for make/cmake, etc, configured in Zig. Last I was aware, it was also getting a built-in package manager, so you basically get another dub/cargo/alire, but this one works not only for Zig, the language it's associated with, but also C. That's the idea at least.
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
I enjoy Zig, Rust and Odin. they're give u different opinions and perspectives on the low level coding niche :) I like them for different reasons and I personally wish all 3 get popular and embraced by the broader community
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" :)
Yeah, let’s not talk about c++ when it’s BEEN the “higher level C replacement” for about 40 years now & is the only language anywhere close to C in terms of widespread usage for systems (or even just compiled) code. Zig seems to be an attempt to merely replace C rather than Rust, which is clearly going after C++ too. Being a new, de facto rewrite of C rather than trying to replace both wholesale probably is the better design & strategy. Especially because linker ABI compatibility with C lets you become a transparent drop in replacement, ironically the SAME THING K&R C did to FORTRAN by making it trivially simple to link Fortran libs into C programs.
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.
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.
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)
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"
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.
LLL despises C++ for some reason i can't quite figure out. (yes, i understand there's a lot of reasons not to like it but i can't tell which reason he has that lets him also like both C and Rust at the same time)
@@somenameidk5278 My guess is because C++ combines the worst bits of C (no safety) with the worst bits of Rust (complexity). C has simplicity and Rust has safety. C++ has neither.
If you're going to "try Zig, C and Rust", I think there's a good chance you'll stick with Zig, because C will constantly crash and Rust will be a constant fight with the borrow checker. Having said that, Rust is still compelling because of it's memory safety.
3:01 I believe C++ fits in the middleground too. Many people just have a religious attitude towards it because it is very full and complex. (I guarantee that most avid C++ haters have never even touched it’s surface.) If you write modern C++ with reasonably good practises, memory safety is not that difficult. Most of the time you don’t even need to allocate and free memory because things like smart pointers and std::string hide that away.
Very true, people shouldn't be writing C++ like it's still 1985. Most of its "problems" are from people who aren't up to date on best practices which isn't C++'s fault.
@@coolbrotherf127 Most of its problems are from its horrible design. Implicit type coercion? Nice, the std::string got stored as a std::string_view (a modern C++ feature). You passed a variable to a function and you didn't know you passed a reference? Well now it's modified. The std::unique_ptr is a nullptr? Yes, because std::unique_ptr can be empty. I'll give you another example - std::optional Its default constructor is either std::optionaloptional(std::nullopt_t) or std::optionaloptional(). The latter constructs a T, anytime T has a default constructor (most types do). You do know that returning {} is common with optionals in real code, right? That's a bad design. Another example is std::vector::operator[](size_t) not doing bound checks, which results in a lot of bugs. Or how the iterator model makes it easy to have errors like std::copy() and you forgot to use std::back_inserter. Now C++20 and after has ranges and views, which use operator overloading again... Didn't we learn from the infamously slow std::iostream that uses a lot of inheritance? I can keep on going, and you can keep saying it's a skill issue. But in reality most developers are average and it's why professional places have half-a-dozen different sanitizers.
C++ is my second language, the one I actually tried in because Python made (and still makes) significantly less sense to me. C++ is honestly a well made language in my eyes. Definitely some issues,but so does every language.
@thetukars I mean that's what you get when you try to maintain backwards compatibility to keep the code running in a hardware from stone age time. The modern stuff is pretty clean tho. (IMO build system still sucks ass tho)
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
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.
Zig makes "memory soundness" another problem to solve eventually instead of a requirement for getting your code to run initially. Which is good if you are trying things out, and don't know exactly what you have set out to build. I can build a giant system that leaks like crazy and then solve the leak once I'm happy with the behaviour and design later.
@@nathanfranck5822 Maybe you can make that argument for C, but Zig handles a lot of that with the "defer" statements, custom allocators and error handling. And even with that argument, hardcore engineers with still pick C over everything, because they like power and control, and are not afraid of using memory. But they may be somehow inclined towards Zig since it allows doing all of that.
"Rust ... inherently doesn't trust the developer to write good code." Considering I don't trust myself to write good code, and barely trust others to write good code, Rust seems pretty perfect for me.
@@arson5304 Yeah Rust isn't bad if you just clone() everywhere, but then it runs significantly slower than JavaScript or Go for the same algorithm. Doing the easiest thing in Zig generally results in really fast single threaded code (talking small CLI apps with some hash maps, lists, iterations, from experience)
Embedded zig? I mean, have you been doing any embedded stuff? After years, Rust has finally reached the point where it's usable for embedded (well, for MCUs whose vendor supports it officially, ot there is good community support). I simply cannot see Zig being a productive language for embedded for years to come; that is, if vendors/community pick it up. Which is doubtful at best.
@@RiwenX My understanding is that because zig is designed to be completely interchangeable with c without any ffi, it should generally just work? I could be missing something though.
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.
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
Actually there are some great podcast episodes between Andrew Kelley and G gingerBill where they both explain their rationales for doing things the way they do them. I like zig way more for comptime stuff, more explicitness in both the stdlib and the lang itself and most importantly @cImport
Can you elaborate on the simpler syntax? I found it difficult because I am a beginner who never had to consider things like memory and static types before (lol), but I personally didn't find the syntax difficult.
@@stretch8390 I wouldn't call it "difficult" but more just... odd (i.e. the "for" loop syntax). There wasn't a single thing that really killed it for me, it was more just death by a thousand paper cuts that made it kind of unpleasant to write (having to do error handling for writing to stdout without using the debug print for example). I'm sure things will change as the language evolves but having to do stuff like: ` try std.io.getStdErr().writer().print("Hello {s}! ", .{"foo"});` (which also requires the function to be marked with "!" which is quite a leaky abstraction) vs `fmt.eprintfln("Hello {}!", "foo")` to log to stderr without using the debug functions is just unpleasant to me. At that point, I think we cross the "simple language" barrier and I would rather just use Rust at that point
I started learning zig when I saw this video two months ago. I really can't look back now that I feel productive with it. It just makes me happy, I can't quite grasp why or explain succinctly why. The only thing missing I think is something as good as the Rust book, but for Zig.
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
Except C++ is a much more messy impossibly complex language with many more ways to mess all that up. Also sure containers have bounds checking, but raw pointers do not whereas Zig slices despite being primitives are bounds checked in all cases. Not to mention other debug checks done for primitive types like overflow checks which C/C++ do not do unless you run with something like UBSan which is more just tacked on to make up for the lack of these things in these languages. People have solutions to this stuff in C/C++ though, but tldr is it's just inelegant and often errorprone. Zig is a lesson in hindsight, taking inspiration from things C/C++ have struggled with and building it all into the language itself.
@@presentfactory Also, what if I don't want bounds checking? It's slower. In C++, you only pay for what you use. UB allows compiler to optimize the program in a much better way.
@@yihan4835 It's used because it's old. C++ is like 30 years old and C is like 50, this has given them a lot of code built up in them over the years and tooling, libraries etc. This means they continue to be needed to maintain such codebases and work with such libraries. Newer projects though are slowing moving away from them. I still use C++ at my job because it's a C++ codebase and has been for the past 20 years, that is not changing anytime soon but all my personal projects are in Zig. Also you are confusing what Zig bounds checks are. Zig bounds checks are not always emitted, they are a debug check only present in "safe" builds like Debug or ReleaseSafe in other modes reading/writing out of bounds is UB. Zig is as fast if not faster than C/C++ because it has all the same philosophies in this regard around performance. If you actually needed to check if an element is in bounds at runtime you'd check the index against the slice's length or container's size manually, same as C++.
Any language that claims to be the next big thing has to drop any intentions of not allowing the programmer to shoot himself on the foot. Otherwise it is wasting time handholding the user that could be used elsewhere. And produce binaries, not bytecode
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.
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.... ;-) )
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.
Well, there is also D language, it has a great interop with c and c++. Like Go, it's compiled. It also has an optional GC. The syntax is C like, has very good performance. Honestly I would say it's an extremely underrated language.
2:55 ZIG is unsafe too. ZIG is basically C without a Preprocessor and better to debug when errors occur. To solve the things, the preprocessor gives to C, ZIG has the comptime keyword. Which is required if you have to evaluate for example a function at compile time.
defer doesn't only put the deferred expression at the bottom of the scope. It puts it at EVERY exit point of the scope. Every return, break, continue, failed try, etc. That's extremely powerful.
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.
Awesome breakdown! As a web dev who’s wanted to learn zig (and low level programming) for a while now for fun, low level academy is VERY interesting and exciting for me but I don’t want to learn C just to then learn zig after. Would love to see a course dedicated to learning low level and zig 🙂
The thing is he’s a TH-camr mainly and not a developer. Thus to gain views and attention he has to praise the new and for engament hate the old. Irl Rust and Zig are not even close to C++ in terms of usage and actual things build with it.
Have been testing Zig for a few week in the context malware dev, I think I might share my thought on the language so far: What I like: 1) Very good interoperability with C (don't need to write binding, the compiler will parse your C code and generate the binding automatically, it's almost seamless) 2) No JIT compilation GC, hidden control flow 3) explicit allocator argument convention for function that return dynamically allocated memory: it makes these functions stand out like sore thumbs immediately. 4) defer: pretty cool to be able to be able to associate the memory allocation and release next to each other 5) comptime: well still feel a bit unnatural due to the comptime limitations but it's much better than macro kung-fu 6) error handling: early try return + defer really make your code clean: no more ugly nested "if", goto or do{ ... break; }while(0) to release resources 7) generate fast and small binaries What I disliked: 1) array/slice type syntax is a bit of a mess and pretty confusing between [_]type, [n]type, [n:0]type and [*]type 2) array/slice type coercion is confusing 3) No interface support (yet?): you have to hack union or implement your vtable manually 4) The std is a bit lacking in some areas (the Windows OS API mappings are lacking ) Other concerns are: the lack of documentation, and regular breaking changes but it's probably to expected from a still unstable language. Overall , a very good language that still need a good amount of polish but that has potential to appeal to many systems developers
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
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!
immediately puts bias on display to bash C++ yet the entirety of the SerenityOS is written in C++, which is moving along at a rather rapid pace and is already branching out to include support for ARM and RISC-V, IOW C++ by explicit illustration is a perfectly capable systems programming language
Nobody criticises the capabilities of C++, it's the design people have issues with. I'm not an expert, but... :) The design feels like "We have features A, B and C aimed at this problem. Which one goes into the standard ? .... To hell, let's add all of them, the devs will choose." C++ is a big and complex language with no clear design vision, so everyone picks the subset they like. That makes it hard to understand code of others. It's the main reason C++ was not allowed into Linux kernel. ...at least that's the opinion I formed after reading many critiques of C++ by expert programers.
For me, one of the biggest strengths of Zig is that it doesn't force switches to be fall-thru and it supports number ranges, which is where most other languages fall short. Huge switch statements with lots of break statements is not only making the code look cluttered if there are many but it's easy to forget to add a break statement and get weird behavior. If you need number ranges and your not hunting for high performance, switches are actually less useful than if statements simply because switches typically do not allow number ranges.
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.
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.
Modern C++ is good...if you can close your eyes to the ugly ugly BS and drama and bikeshedding over implementations. FFS unordered_map and regex are still broken and will never be fixed. Runtime exceptions are the cause of a holy war that Google wages against the standards committee. 3rd party packaging and the CMake build system being a complete mess (second only to Python's mess). Tons of legacy footguns that the standards committee refuses to deprecate or atleast warn against using like vector. Networking...LOL. Despite all of that...modern C++ niceties like ranges and constexpr/consteval are genuinely cool to have in a programming language.
@@heavymetalmixer91 C++ and Zig both have excellent compile-time computation capabilities : proc macros in Rust are a language of their own whereas in C++ you write almost the same code as you would for "runtime". C++ templates combined with constexpr make for a powerful metaprogramming system. The only thing that is lacking is a Reflection system (the proposal is on its way for standardization in C++26). Rust's macro system is tedious and an expert-only feature. For anything sophisticated, you have to reach out to them. For example: "println!" in Rust is a macro while in C++ std::print (which is more flexible) is just another function template. Rust also includes many runtime checks which you cannot get rid of in release builds, unlike the "NDEBUG" macro in C/C++. Rust is an awesome language for "application" developers who won't be writing any "low-level" code themselves and instead would use libraries for the same (which are most developers). But it is very tedious for library authors who might find the language limiting at times.
@@heavymetalmixer91 C++ and Zig both have excellent compile-time computation capabilities : proc macros in Rust are a language of their own whereas in C++ you write almost the same code as you would for "runtime". C++ templates combined with constexpr make for a powerful metaprogramming system. The only thing that is lacking is a Reflection system (the proposal is on its way for standardization in C++26). Rust's macro system is tedious and an expert-only feature. For anything sophisticated, you have to reach out to them. For example: "println!" in Rust is a macro while in C++ std::print (which is more flexible) is just another function template. Rust also includes many runtime checks which you cannot get rid of in release builds, unlike the "NDEBUG" macro in C/C++. Rust is an awesome language for "application" developers who won't be writing any "low-level" code themselves and instead would use libraries for the same (which are most developers). But it is very tedious for library authors who might find the language tedious and limiting at times.
5:17 the main thing about this isn't even just that, but also that it runs at every possible end of the scope/function. If you have multiple return statements (because you handle multiple possible errors from different functions) then the defer will return at every possible return so you will only have to write the cleanup in one place and it will always run, you wont miss it in some cases. The way to do this is in C is to write a goto to the end of the function that does the cleanup and checks that the values aren't NULL. This defer is basically that goto but cleaner and directly after the allocation as you say so you can immediately see if its done or not. It's basically like c++ RAII, except you dont have to write a class with a destructor to do it for every case (or write a hacky macro to do it). Zig also has errdefer to do it only when an error has happened for example if you want to cleanup everything that has been done when an error has occured but if it succeeds you want to return that data instead in its complete form.
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.
One thing about Zig that I love is integer handling. It doesn't have any nonsense like with C's integer types. All integer casts are explicit, so you never run into a problem with implicit casts losing specificity like in C. It has multiple types of integer cast to cover different scenarios. Plus all integer math operations are either fail-on-overflow, saturating, or wrapping, so you know when you hit integer size limits. Zig only supports arbitrary width integers of a predetermined bit width, no "int" or "short". It abstracts away operations on integers of arbitrary bit widths, lets you predictably pack structs with bitfields, and even allows you to take bit references!! This is awesome for writing emulators, parsing binary formats, or for packing data for message passing. It has lots of little rules and guarantees, for example if you ever do a bitshift on say, a 32 bit integer, Zig will actually require that the bitshift is using a 5-bit integer for the shift length, so that it can't exceed a length of 32. So it manages to be more high-level than C in terms of describing integers, more explicit than C in integer operations, and eliminates just about every integer footgun in C.
I suppose zig is good if you need no garbage collector , if garbage collector is ok , then I really really like golang. Rust is also good if you don't need any C code , though it might be hard. I am thinking of doing this. Typescript / Python / Lua , Golang , Gleam (seems like rust would try it ) , ZIg , C , Rust. This depends from person to person but I am pretty happy with these language , I don't know but I love the fact that there are sooo many programming languages.
@@LowLevelTV do you know of a name for that concept, like mandatory error handling? Trying to finds some terms to google. Edit: nvm found it, "errors as values"
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 see Zig mostly as a "TypeScript for C" and it's been very nice to work with it with that mindset. I import C libraries like raylib and just use Zig for my code.
Zig allowed me to learn and understand rust. Having explicit heap allocations really lets people that come from garbage collected languages learn how memory is actually allocated and cleaned up without having to dive into C which... for someone unfamiliar is just a whole mess of nope.
You hurted my feelings! 😢 I started with C and it is beautiful, because it is as minimal as you need but you can also do things with pointers, memory allocation and structs if you want to. In C++ or even more in Java you get distracted by object oriented programming first.
Zig it is. I tried to learn Rust 3x so far, and went back to C with intention of going back to Rust after some deep learning, but I like C and I think I am going to transition to Zig. This video helped sooth my curiosity, not knowing anything about Zig yet. I will likely someday get back to Rust if there is some professional reason but Zig seems like the next best logical step for me.
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 👏 👏 👏
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.
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.
Look he is a TH-camr and not a developer. So he praises the new to get views and hates the old to get emgament. Of course IRL C++ is the king. But that won’t get many views…
Note that if you make it a habit to "defer" deallocation of data types in Zig, you are effectively mimicking what rust does for you: deallocating memory if the owner goes out of scope. Unless you are showing some examples where you do not want to do that for a reason, Zig has no benefit. It is also true that in every programming language with manual memory management, you need to think about ownership (i.e. finding the safe place to deallocate memory). Rust enforces you to do so. Zig and C allow the mistakes that cause so much pain on the internet.
Don't forget that rust compilation takes so long that you start wondering if it wasn't better to write in python, then at least your users would be suffering and not you.
Zig is fun and the community is cool. Worst thing as a beginner's language is just the basic difficulty typing .what = .{ .thing = .etc } a bunch Kinda the antithesis to python that way...
It is, but i wouldn't learn it as a first language. Don't get me wrong, Zig is my *favourite* language, but i think as a first language you should learn something stable with a good foundation (I started with C++, and would always not recommend it, but instead i'd recommend C.)
@@not_kode_kun one more thing to consider is the available resources to learn the language. C/C++ being older language seems to have an advantage over zig on this matter. So, maybe learning C/C++ to get familiar with low level stuff and switching would be much easier, no?
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.
so basically c++ raii but with extra steps and some syntactic sugar. c++ without the `new` and `virtual` and `throw` keywords is basically C but better, idk why people hate on it so much as a systems language.
Because C++ sucks, it's not ergonomic, it's not fun, it's very bloated and hard to read. Zig achieves 90% of the power of C++ while remaining very readable, understandable, and that's why it's worth talking about. I love C++, but this language, is just not a good language compared to what exist today, it's hard to collaborate with people, it's hard to use some else's code because you have to audit it all to make sure it works like you want it to work. It's hard to debug with templates, the error messages aren't good, the compiler is quite slow, but the real problem is the amount of features available in the language, and how you can basically do everything with everything. I know people don't like to hear about it, but at the end of the day a programming language is just a tool, not a church to go on a crusade for, everyone with an ounce of objectivity can see that C++ is just not a good language this days, when things like Rust, Zig, Odin, Jai, exist.
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?
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.
Scoped deallocation could have been done more cleanly by just throwing a "local" or "auto" keyword in front of the allocation. In fact, almost all the features of these new languages like Rust could be added cleanly to existing languages, without inventing new languages. Well, cleanly added to any language but C, which is a hot mess.
@@udasai that idea was toyed around syntactically, it provides problems if you don't have destructor as a concept, and zig does not have it. The language have no context around those semantics. At the end defer is the method we got, and there are still posibilities but unlikely we get in zig the autoclean function. Also having a keyword doing it requires knowing which resources are being allocated, while here we talk about heap, defer is used for closing files and a number of other resource management op. And for the adding to other languages, yes, but the fact you cannot add it yourself because you want it, have to go tru a bunch of process to get it in existing language, remember that is hard to implement something in existing languages without support. It's not because it exists that is cool (it's not even a novelty) is the fact that it works nicely for the language objective
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.
Java checked exceptions are indeed not liked by many, and in C# they copied a majority of things from Java, but checked exceptions where never implemented. But having error state represented by in functions in proper ways instead definitely is really powerful. The old try catch exception system is basically a difficult to overcome legacy burden. I believe no new languages are to be expected designed with it anymore. The actual important thing which I believe happened is functional programming becoming more main stream. Rust is obviously one of the best examples, but also more imperative languages like Go and Zig have been inspired by it. Older examples are OCaml and F#, of which the first one was a major influence on Rust. But I expect other functional languages also do it, especially pure functional languages.
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.
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
It's interesting that nobody is talking about Pascal, anymore. It's a mature and very powerful language and with freepascal available on most operating systems and cpu architectures and it's also a lot more safe than C.
the language is just really hard to work with, there are just so many decades of bad design decisions stacked on top of each other that the language has become so bloated. they're trying to fix all of it now, but it's too little too late: c++20 concepts, c++20 views, c++23 expected, and so on.
C++ remains my favorite systems programming language due to how features complete it is (compared to the other options), these upcoming ones are cool but I'm mostly looking forward to the changes it makes in future c++ updates as it learns from the competition
beyond the eloquent and coherent explanations, above all i most liked your comment that we should all be learning everything, becuase learning makes us not only better programmers, but also better people. i whole heartedly agree.
come learn about C and other languages at lowlevel.academy
can u pls give me ur course for free? i am in my pre-final year in uni and I have an intern in TI in a month, I need to get pro in C 🙏 im broke haalp
hey, if you could price your course better it would be great for us students. Im struggling to pay accomodation and my car payment (i need it to get to campus) but a student plan would greatly help but currently i am unable to afford your courses so im stuck with your generously provided free youtube content. I want to support you, but i need to support myself first :(
@@simpleprogrammingcodes i dont know c
Hey LowLevelLearning, you should probably include zig in the title of the first video about zig, I had the use youtube's channel search function to find it.
Wow that's pretty cheap for a lifetime license! I hope you get into MPI someday.
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.
This is what I was excited about, but when I started looking at using it for a pet project I started noticed that most folks still ended up writing bindings for common libraries anyway to get around issues with C APIs not being descriptive enough in some cases. Kind of ruins the magic. :(
"You didn't even talk about one of the best features of (C++) - seamless integration with C! It's really cool, you can straight import and start using C libs without writing any FFI." - lol
@@Sevenhens You can't every library though
@@matrix07012 You can because C++ is a superset of C, meaning any C code is valid C++ code.
@@matrix07012 like you can use every library seamlessly in zig
Pros and cons of C: you can do what the hell you want
Pretty much. Zig is not much different in that regard, but I still prefer to use Zig instead of C.
C:
pros: it does exactly what you tell it to do
cons: it does exactly what you tell it to do
You know what you doing
@nikkehtine nah, not so much. Lots of legacy stuff/knowledge issue with the language where you just have to know what it does by reading the specification exactly. Rust and zig are a bit nicer where I don't think there is not nearly as much oddities you have to remember and are more explicit on what they do.
Zig is the same except it asks you to explicitly tell it what the hell you want it to do while C can do things you didn't mean behind your back if you don't know any better.
Rust philosophy: make it hard to write bad code
Zig philosophy: make it easy to write good code
c++ philosophy: you got this bro
I don't know, every large scale Zig project has a plethora of segfaults, I dont know if I consider that easy to write good code
@@aaronhoush7184 do you have a source? (not being sarcastic, I genuinely want to know about those cases)
python: i love rainbow
@@aaronhoush7184 That is weird. In most cases it seems like segfaults are caused by developers. OOB-ing arrays is something a lot of languages can do.
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.
Agreed. I just wrote a microservice yesterday in Rust that takes a netcdf file and cuts out a subregion based on a geojson "selection". I've been writing rust for 4 years so I kind of knew what to expect, but I was still shocked when all the tests passed on the first try. I was so happy that I went bragging to my colleagues for the rest of the day 😅. And because it's rust, all possible errors have been handled gracefully and I don't have to worry about race conditions at all.
Granted I used quite a bit of well-tested third-party libraries, but still there were about 1000 lines of my own code. I'm pretty confident when I say that had I written it in any other language (Go, Java, Cpp, or god forbid JS), debugging alone would have taken me at least 2 days.
@@scheimong 33% of software bugs cannot be caught by the Rust compiler.
@@raylopez99 33% is way better than 100%
@@catto-from-heaven True, if you can fight the compiler. I played around with Rust for a few months then gave up. If more devs adopt it, and it's taught in uni, it might have a future; same with Zig. Otherwise not and with AI on the horizon it might be moot.
@@raylopez99Except it's not moot. If AI becomes as good a programmer as everyone thinks it will be then we can just abandon all languages because the godly AI will program everything directly in fully-optimized machine code.
At that point, maybe everything is moot. We can just abandon our jobs because the AI will do everything and give us UBI
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.
you dont like having version control for your build systems build system? \s
Rust moment?
C++ dependency management can non-controversially be declared utter fucking dogshit.
We have cargo for rust tho
@@ScibbieGames I disagree, something that doesn't exist can't be dogshit
After reading some of the comments my thought is "since when did programming languages become religions?"
Several decades ago.
Since their inception
Rust is king! Repent and learn Rust to experience heaven on Earth! Zig is for sinners.
If you've read "PHP: a fractal of bad design", you'll notice some obvious parallelisms between the PHP community and any cult/sect/religion. This also reminds me of the joke "Cult of Vim VS Church of Emacs"
Zig community is more logical.
Rust community is more religious
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.
I've been re-making a C project in Zig, started with a dumb 1:1 port and have slowly been implementing safety features and metaprogramming. It's pretty amazing how much more readable code becomes when you don't have to rely on 30 helper functions to extract data from packed structs like you do in C or Go
@@mgord9518 Yes that's for me one of my favorite features of the language, is just how much readable it is, at doing what you would do in C. One example that I love is logging. I'm a sucker for logging things to a file as a mean to debug, in C it's cumbersome, and you can't really use printf unless you also use fflush and all that jazz, you have to change the %_ to do anything, or you have to write your own implementation of printf, and even that is tricky and annoying, in Zig, you just implement a format functions, and you can call that type format function it's very easy and, with comptime you can automate that process, and basically recursively check the type of the field at comptime, to see whether it has a member called idk print, or if it's a simple type just use {any} with it it's really amazing..
@@mgord9518 I even forgot to mention how good and complete and portable the std is compared to C.
hello thanks for this review of zig and how it helps you. I'm curious to know how much does the zig compiler help prevent data race related bugs due to concurrency & also identifying or prevention of memory leaks.
If possible please help it by comparison with rust/golang
thanks.
also defer is so good, the video doesn´t go into detail but also it is made to substitute the goto: error pattern you would sue in C when you need deinit/deallocs. It is just C but improved for me
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.
Honestly, that sounds like Go 8 years ago.
Or every sane language during their early years.
It’s a fundamental law that the older a language gets, the more docs and features it will have.
@@fr3ddyfr3sh Sure, in practice some amount of that is inevitable - but to offer a reply to your example: Generics in Go needed to be a new feature added to the language. In Zig, the feature that was already there, comptime, is so powerful that it produces generics for free. Same for interfaces (as awkward as they currently can be).
I don't want to get too hung up on this as a be-all end-all of how programming should be done, but it is my takeaway from the language in a comparable way to how I believe Rust popularized to many people what a modern typesystem could feel like.
I’m a little hyped for zig too.
I always thought an expression-style try-catch feature would be cool, and zig simply has it out of the box :)
I heard that they want to follow C philosophy and keep the language as slim as possible.
@@fr3ddyfr3sh wym? Go is still like that today.
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
still not ready to embrace Zig myself - going to sit tight and wait for it's successor language Zag
@TheSulross better wait for zog then, it fixes all the stuff zag got wrong
@@immige9216 I confess that my real fantasy for Zag is to be a subset language of Zig that can be a Turbo Pascal like programming IDE that can run directly on 8bit and 16bit retro computers - or modern retro themed computers like the Agon Lite or the Commander X16. To do retro games development, of course. But where would be the fun in that if it didn't run directly on the target computer. 🙂
He said "defer macro". He has C Stockholm Syndrome. lol
I see the kids are here...
goddamn time wasters
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.
My takeaway: Learn everything!
Except C++ apparently, despite being more relevant and more widely used than either Rust or Zig
Rule 1 of low level programming, we don't talk about C++,
Rule 2 of low level programming, if we're trying to find example, pretend everything was written in C
@@CyberDork34Because learning C++ means becoming a C++ programmer
@@CyberDork34learning c++ would take the same time than the other 3 combined 😅
@user-gi3mb3eu1m and some people want jobs
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
Yes, for that you need something with real control, instead of giving you bits and pieces always wrapped in some insanely complicated proprietary memory management system like Rust.
Have a look at Odin. I like Zig and Odin but Odin might be even more game friendly.
@@andrewdunbar828 Yeah, the builtin Quat, Vector and Matrix types in Odin definitely helps with ergonomics. Also the context object to pack allocators and debugging tools into. I'm sticking with zig for now, and having a good time with the killer zig features so far, though the ergonomics aren't as good as Odin
Does Zig have OOP?
@@heavymetalmixer91 You can pack data into structs and give them methods --- the best parts of OOP :)
If you want interfaces and inheritance, it's not a first-class feature, you'd have to use anytypes and make some (arguably cool) comptime code to build up those concepts again, you'd get worse tooling and the community isn't generally impressed with it
that rare thing - a youtuber prepared to admit that they changed their mind
subbed
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.
That true, "unsafe" Zig (which is whole language) is safer than unsafe Rust.
Zig is nice.
Zig is the best C toolchain ever
Which is pretty amazing considering that C is 50 years old and hasn't figured this shit out
No reason I should have to install gigabytes of libraries for other architectures when I just want to link to them
Yea, it's amazing.
Is it? I am genuinely asking
@@matteo.veraldi You can use Zig as a replacement for make/cmake, etc, configured in Zig.
Last I was aware, it was also getting a built-in package manager, so you basically get another dub/cargo/alire, but this one works not only for Zig, the language it's associated with, but also C. That's the idea at least.
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
I enjoy Zig, Rust and Odin. they're give u different opinions and perspectives on the low level coding niche :)
I like them for different reasons and I personally wish all 3 get popular and embraced by the broader community
What did you accomplish that you couldn't do with other languages?
You should try frenti 😉
@@FlanPoirot With you on this!
Endeavour os?
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" :)
Yeah, let’s not talk about c++ when it’s BEEN the “higher level C replacement” for about 40 years now & is the only language anywhere close to C in terms of widespread usage for systems (or even just compiled) code.
Zig seems to be an attempt to merely replace C rather than Rust, which is clearly going after C++ too. Being a new, de facto rewrite of C rather than trying to replace both wholesale probably is the better design & strategy. Especially because linker ABI compatibility with C lets you become a transparent drop in replacement, ironically the SAME THING K&R C did to FORTRAN by making it trivially simple to link Fortran libs into C programs.
yeah, the waves of weird anti C++ bias just tsunami rolled me
@@TheSulross Yes, it is almost like a trendy thing to just hate C++. Very cliche. Yet all their fancy tools are built with C++.
When C++ devs die they don't leave a corpse, it goes on a puff of black smoke straight to hell
@@jvillasante they hate us cause they wanna be us 🤷♂️
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.
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.
As a c/c++ enjoyer, zig is the only one I tried out of the "hot new" languages. so far, I am loving it.
The reason to learn C is not to use it (much), but because it makes you understand the computer better.
In May, there is "the software you can love" in Milan. They'll speak about zig and system programming! I already took the ticket!
I went. It was terrific!
@ChipKeefer Argue please
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)
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"
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.
what alternate universe is this where C++ don't exist?
Word
A pleasant one
LLL despises C++ for some reason i can't quite figure out. (yes, i understand there's a lot of reasons not to like it but i can't tell which reason he has that lets him also like both C and Rust at the same time)
@@somenameidk5278 My guess is because C++ combines the worst bits of C (no safety) with the worst bits of Rust (complexity).
C has simplicity and Rust has safety.
C++ has neither.
Feature creep
Zig is for puppygirls, rust for catboys
weird take but ok
Greatest take of the century
@@ゾカリクゾ arf arf
based take actually
most reasonable take i have heard this month
If you're going to "try Zig, C and Rust", I think there's a good chance you'll stick with Zig, because C will constantly crash and Rust will be a constant fight with the borrow checker.
Having said that, Rust is still compelling because of it's memory safety.
3:01 I believe C++ fits in the middleground too. Many people just have a religious attitude towards it because it is very full and complex. (I guarantee that most avid C++ haters have never even touched it’s surface.)
If you write modern C++ with reasonably good practises, memory safety is not that difficult. Most of the time you don’t even need to allocate and free memory because things like smart pointers and std::string hide that away.
Very true, people shouldn't be writing C++ like it's still 1985. Most of its "problems" are from people who aren't up to date on best practices which isn't C++'s fault.
@@coolbrotherf127 Most of its problems are from its horrible design.
Implicit type coercion? Nice, the std::string got stored as a std::string_view (a modern C++ feature).
You passed a variable to a function and you didn't know you passed a reference? Well now it's modified.
The std::unique_ptr is a nullptr? Yes, because std::unique_ptr can be empty.
I'll give you another example - std::optional
Its default constructor is either std::optionaloptional(std::nullopt_t) or std::optionaloptional().
The latter constructs a T, anytime T has a default constructor (most types do). You do know that returning {} is common with optionals in real code, right?
That's a bad design.
Another example is std::vector::operator[](size_t) not doing bound checks, which results in a lot of bugs.
Or how the iterator model makes it easy to have errors like std::copy() and you forgot to use std::back_inserter. Now C++20 and after has ranges and views, which use operator overloading again...
Didn't we learn from the infamously slow std::iostream that uses a lot of inheritance?
I can keep on going, and you can keep saying it's a skill issue. But in reality most developers are average and it's why professional places have half-a-dozen different sanitizers.
C++ is my second language, the one I actually tried in because Python made (and still makes) significantly less sense to me. C++ is honestly a well made language in my eyes. Definitely some issues,but so does every language.
C++ with modern constructs and strict adherence to RAII is safe enough, especially for quick prototypes and fast-changing stuff.
@thetukars I mean that's what you get when you try to maintain backwards compatibility to keep the code running in a hardware from stone age time. The modern stuff is pretty clean tho. (IMO build system still sucks ass tho)
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
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.
Zig makes "memory soundness" another problem to solve eventually instead of a requirement for getting your code to run initially. Which is good if you are trying things out, and don't know exactly what you have set out to build. I can build a giant system that leaks like crazy and then solve the leak once I'm happy with the behaviour and design later.
@@nathanfranck5822 Maybe you can make that argument for C, but Zig handles a lot of that with the "defer" statements, custom allocators and error handling.
And even with that argument, hardcore engineers with still pick C over everything, because they like power and control, and are not afraid of using memory. But they may be somehow inclined towards Zig since it allows doing all of that.
"Rust ... inherently doesn't trust the developer to write good code."
Considering I don't trust myself to write good code, and barely trust others to write good code, Rust seems pretty perfect for me.
why is it too restrictive, i've yet to be held back by chains from the language
@@arson5304 Yeah Rust isn't bad if you just clone() everywhere, but then it runs significantly slower than JavaScript or Go for the same algorithm. Doing the easiest thing in Zig generally results in really fast single threaded code (talking small CLI apps with some hash maps, lists, iterations, from experience)
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
Also:
Build system: zig
C++ compiler: zig
JS runtime: zig
Just use the right tool for the right job
Embedded zig? I mean, have you been doing any embedded stuff? After years, Rust has finally reached the point where it's usable for embedded (well, for MCUs whose vendor supports it officially, ot there is good community support). I simply cannot see Zig being a productive language for embedded for years to come; that is, if vendors/community pick it up. Which is doubtful at best.
Nice 😂
@@mgord9518 the right zig for the right job 😁
@@RiwenX My understanding is that because zig is designed to be completely interchangeable with c without any ffi, it should generally just work? I could be missing something though.
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.
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
Actually there are some great podcast episodes between Andrew Kelley and G
gingerBill where they both explain their rationales for doing things the way they do them.
I like zig way more for comptime stuff, more explicitness in both the stdlib and the lang itself and most importantly @cImport
Can you elaborate on the simpler syntax? I found it difficult because I am a beginner who never had to consider things like memory and static types before (lol), but I personally didn't find the syntax difficult.
@@stretch8390 I wouldn't call it "difficult" but more just... odd (i.e. the "for" loop syntax). There wasn't a single thing that really killed it for me, it was more just death by a thousand paper cuts that made it kind of unpleasant to write (having to do error handling for writing to stdout without using the debug print for example). I'm sure things will change as the language evolves but having to do stuff like: ` try std.io.getStdErr().writer().print("Hello {s}!
", .{"foo"});` (which also requires the function to be marked with "!" which is quite a leaky abstraction) vs `fmt.eprintfln("Hello {}!", "foo")` to log to stderr without using the debug functions is just unpleasant to me. At that point, I think we cross the "simple language" barrier and I would rather just use Rust at that point
I started learning zig when I saw this video two months ago. I really can't look back now that I feel productive with it. It just makes me happy, I can't quite grasp why or explain succinctly why. The only thing missing I think is something as good as the Rust book, but for Zig.
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
Except C++ is a much more messy impossibly complex language with many more ways to mess all that up. Also sure containers have bounds checking, but raw pointers do not whereas Zig slices despite being primitives are bounds checked in all cases. Not to mention other debug checks done for primitive types like overflow checks which C/C++ do not do unless you run with something like UBSan which is more just tacked on to make up for the lack of these things in these languages.
People have solutions to this stuff in C/C++ though, but tldr is it's just inelegant and often errorprone. Zig is a lesson in hindsight, taking inspiration from things C/C++ have struggled with and building it all into the language itself.
@@presentfactory if C++ is really that impossible, you wouldn't see it being used at all. Yet, it's used in a lot of places.
@@presentfactory Also, what if I don't want bounds checking? It's slower. In C++, you only pay for what you use. UB allows compiler to optimize the program in a much better way.
@@yihan4835 It's used because it's old. C++ is like 30 years old and C is like 50, this has given them a lot of code built up in them over the years and tooling, libraries etc. This means they continue to be needed to maintain such codebases and work with such libraries. Newer projects though are slowing moving away from them. I still use C++ at my job because it's a C++ codebase and has been for the past 20 years, that is not changing anytime soon but all my personal projects are in Zig.
Also you are confusing what Zig bounds checks are. Zig bounds checks are not always emitted, they are a debug check only present in "safe" builds like Debug or ReleaseSafe in other modes reading/writing out of bounds is UB. Zig is as fast if not faster than C/C++ because it has all the same philosophies in this regard around performance. If you actually needed to check if an element is in bounds at runtime you'd check the index against the slice's length or container's size manually, same as C++.
@@yihan4835 Zig's bounds checking is only in Debug and ReleaseSafe modes, as well as other safety features.
Any language that claims to be the next big thing has to drop any intentions of not allowing the programmer to shoot himself on the foot. Otherwise it is wasting time handholding the user that could be used elsewhere. And produce binaries, not bytecode
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.
Nim’s flexibility is great. I enjoy it more than I ever expected.
I did not enjoy Nim.
I'd put Odin somewhere between Zig and Nim. Nim felt like it has less momentum and I didn't look at it as deeply as the others because of that.
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.... ;-) )
Nim is also a system's programming language with optional GC
2:00 even if the OS or kernel doesn't allow it - C can do it. Write your own OS and kernel.
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.
Well, there is also D language, it has a great interop with c and c++. Like Go, it's compiled. It also has an optional GC. The syntax is C like, has very good performance. Honestly I would say it's an extremely underrated language.
2:55 ZIG is unsafe too. ZIG is basically C without a Preprocessor and better to debug when errors occur. To solve the things, the preprocessor gives to C, ZIG has the comptime keyword. Which is required if you have to evaluate for example a function at compile time.
I'm totally in love with Nim, but Zig looks great.
defer doesn't only put the deferred expression at the bottom of the scope. It puts it at EVERY exit point of the scope. Every return, break, continue, failed try, etc. That's extremely powerful.
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.
Awesome breakdown! As a web dev who’s wanted to learn zig (and low level programming) for a while now for fun, low level academy is VERY interesting and exciting for me but I don’t want to learn C just to then learn zig after. Would love to see a course dedicated to learning low level and zig 🙂
I love watching your videos but I feel this hatred for C++ that hurts. C++ is amazing then many of you can comprehend.
The thing is he’s a TH-camr mainly and not a developer. Thus to gain views and attention he has to praise the new and for engament hate the old. Irl Rust and Zig are not even close to C++ in terms of usage and actual things build with it.
@@roiqk not even close in terms of usage? that's obvious given the age of the languages.
@@user-eg6nq7qt8c agreed
Have been testing Zig for a few week in the context malware dev, I think I might share my thought on the language so far:
What I like:
1) Very good interoperability with C (don't need to write binding, the compiler will parse your C code and generate the binding automatically, it's almost seamless)
2) No JIT compilation GC, hidden control flow
3) explicit allocator argument convention for function that return dynamically allocated memory: it makes these functions stand out like sore thumbs immediately.
4) defer: pretty cool to be able to be able to associate the memory allocation and release next to each other
5) comptime: well still feel a bit unnatural due to the comptime limitations but it's much better than macro kung-fu
6) error handling: early try return + defer really make your code clean: no more ugly nested "if", goto or do{ ... break; }while(0) to release resources
7) generate fast and small binaries
What I disliked:
1) array/slice type syntax is a bit of a mess and pretty confusing between [_]type, [n]type, [n:0]type and [*]type
2) array/slice type coercion is confusing
3) No interface support (yet?): you have to hack union or implement your vtable manually
4) The std is a bit lacking in some areas (the Windows OS API mappings are lacking )
Other concerns are: the lack of documentation, and regular breaking changes but it's probably to expected from a still unstable language.
Overall , a very good language that still need a good amount of polish but that has potential to appeal to many systems developers
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
Noob here , can you make computer app with zig ?
@@padmabharali1306 whats a zig?
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!
immediately puts bias on display to bash C++ yet the entirety of the SerenityOS is written in C++, which is moving along at a rather rapid pace and is already branching out to include support for ARM and RISC-V, IOW C++ by explicit illustration is a perfectly capable systems programming language
Nobody criticises the capabilities of C++, it's the design people have issues with. I'm not an expert, but... :)
The design feels like "We have features A, B and C aimed at this problem. Which one goes into the standard ? .... To hell, let's add all of them, the devs will choose." C++ is a big and complex language with no clear design vision, so everyone picks the subset they like. That makes it hard to understand code of others. It's the main reason C++ was not allowed into Linux kernel.
...at least that's the opinion I formed after reading many critiques of C++ by expert programers.
For me, one of the biggest strengths of Zig is that it doesn't force switches to be fall-thru and it supports number ranges, which is where most other languages fall short. Huge switch statements with lots of break statements is not only making the code look cluttered if there are many but it's easy to forget to add a break statement and get weird behavior. If you need number ranges and your not hunting for high performance, switches are actually less useful than if statements simply because switches typically do not allow number ranges.
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.
Odin is a fair bit more C-like than Zig even though it is also fairly Pascal-like.
@@andrewdunbar828 Yes sir, Zig is simple, but Odin is more simple.
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.
As a C++ dev, Rust sucks but Zig comes close to what modern C++ offers you without any bullshit.
In what way?
@@heavymetalmixer91 I would like to know as well.
Modern C++ is good...if you can close your eyes to the ugly ugly BS and drama and bikeshedding over implementations. FFS unordered_map and regex are still broken and will never be fixed. Runtime exceptions are the cause of a holy war that Google wages against the standards committee. 3rd party packaging and the CMake build system being a complete mess (second only to Python's mess). Tons of legacy footguns that the standards committee refuses to deprecate or atleast warn against using like vector. Networking...LOL.
Despite all of that...modern C++ niceties like ranges and constexpr/consteval are genuinely cool to have in a programming language.
@@heavymetalmixer91 C++ and Zig both have excellent compile-time computation capabilities : proc macros in Rust are a language of their own whereas in C++ you write almost the same code as you would for "runtime".
C++ templates combined with constexpr make for a powerful metaprogramming system. The only thing that is lacking is a Reflection system (the proposal is on its way for standardization in C++26). Rust's macro system is tedious and an expert-only feature. For anything sophisticated, you have to reach out to them. For example: "println!" in Rust is a macro while in C++ std::print (which is more flexible) is just another function template.
Rust also includes many runtime checks which you cannot get rid of in release builds, unlike the "NDEBUG" macro in C/C++.
Rust is an awesome language for "application" developers who won't be writing any "low-level" code themselves and instead would use libraries for the same (which are most developers). But it is very tedious for library authors who might find the language limiting at times.
@@heavymetalmixer91 C++ and Zig both have excellent compile-time computation capabilities : proc macros in Rust are a language of their own whereas in C++ you write almost the same code as you would for "runtime".
C++ templates combined with constexpr make for a powerful metaprogramming system. The only thing that is lacking is a Reflection system (the proposal is on its way for standardization in C++26). Rust's macro system is tedious and an expert-only feature. For anything sophisticated, you have to reach out to them. For example: "println!" in Rust is a macro while in C++ std::print (which is more flexible) is just another function template.
Rust also includes many runtime checks which you cannot get rid of in release builds, unlike the "NDEBUG" macro in C/C++.
Rust is an awesome language for "application" developers who won't be writing any "low-level" code themselves and instead would use libraries for the same (which are most developers). But it is very tedious for library authors who might find the language tedious and limiting at times.
5:17 the main thing about this isn't even just that, but also that it runs at every possible end of the scope/function. If you have multiple return statements (because you handle multiple possible errors from different functions) then the defer will return at every possible return so you will only have to write the cleanup in one place and it will always run, you wont miss it in some cases.
The way to do this is in C is to write a goto to the end of the function that does the cleanup and checks that the values aren't NULL. This defer is basically that goto but cleaner and directly after the allocation as you say so you can immediately see if its done or not.
It's basically like c++ RAII, except you dont have to write a class with a destructor to do it for every case (or write a hacky macro to do it). Zig also has errdefer to do it only when an error has happened for example if you want to cleanup everything that has been done when an error has occured but if it succeeds you want to return that data instead in its complete form.
So Zig is Go but for manually managed memory languages. Cool
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.
One thing about Zig that I love is integer handling. It doesn't have any nonsense like with C's integer types.
All integer casts are explicit, so you never run into a problem with implicit casts losing specificity like in C. It has multiple types of integer cast to cover different scenarios. Plus all integer math operations are either fail-on-overflow, saturating, or wrapping, so you know when you hit integer size limits.
Zig only supports arbitrary width integers of a predetermined bit width, no "int" or "short". It abstracts away operations on integers of arbitrary bit widths, lets you predictably pack structs with bitfields, and even allows you to take bit references!! This is awesome for writing emulators, parsing binary formats, or for packing data for message passing.
It has lots of little rules and guarantees, for example if you ever do a bitshift on say, a 32 bit integer, Zig will actually require that the bitshift is using a 5-bit integer for the shift length, so that it can't exceed a length of 32.
So it manages to be more high-level than C in terms of describing integers, more explicit than C in integer operations, and eliminates just about every integer footgun in C.
I suppose zig is good if you need no garbage collector , if garbage collector is ok , then I really really like golang.
Rust is also good if you don't need any C code , though it might be hard.
I am thinking of doing this.
Typescript / Python / Lua , Golang , Gleam (seems like rust would try it ) , ZIg , C , Rust.
This depends from person to person but I am pretty happy with these language , I don't know but I love the fact that there are sooo many programming languages.
He forgot to mention Nim as a language that uses no garbage collection.
Definitely trying this. That error handling looks kinda sick
i LOVE zigs error handling
@@LowLevelTV do you know of a name for that concept, like mandatory error handling? Trying to finds some terms to google.
Edit: nvm found it, "errors as values"
Hold on, why are we not talking about C++? Did I miss something?
@@31redorange08 ok, but why?
Probably because with C++, there is no reason to use C at all.
@@1zuilol
It’s trendy and hip to hate on the language even though it’s the only systems language actually worth using
Thanks for the left!right idea for errors. Really helped me be able to read Zig better!
seeing people say whatever about c++ most of the time makes me think whats wrong with my car cause i like it
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.
Regardless of what language is practical, they probably won't employ as much Zig programmers as C programmers for a long, long time.
I see Zig mostly as a "TypeScript for C" and it's been very nice to work with it with that mindset. I import C libraries like raylib and just use Zig for my code.
Zig allowed me to learn and understand rust. Having explicit heap allocations really lets people that come from garbage collected languages learn how memory is actually allocated and cleaned up without having to dive into C which... for someone unfamiliar is just a whole mess of nope.
You hurted my feelings! 😢
I started with C and it is beautiful, because it is as minimal as you need but you can also do things with pointers, memory allocation and structs if you want to. In C++ or even more in Java you get distracted by object oriented programming first.
C is the simplest set of rules.. the only thing to learn is pointers and how memory gets initialized.
Zig it is. I tried to learn Rust 3x so far, and went back to C with intention of going back to Rust after some deep learning, but I like C and I think I am going to transition to Zig.
This video helped sooth my curiosity, not knowing anything about Zig yet.
I will likely someday get back to Rust if there is some professional reason but Zig seems like the next best logical step for me.
Zig? For great justice, obviously.
Only if you take off every one.
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 👏 👏 👏
I’m waiting for zag.
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.
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.
Look he is a TH-camr and not a developer. So he praises the new to get views and hates the old to get emgament. Of course IRL C++ is the king. But that won’t get many views…
Note that if you make it a habit to "defer" deallocation of data types in Zig, you are effectively mimicking what rust does for you: deallocating memory if the owner goes out of scope. Unless you are showing some examples where you do not want to do that for a reason, Zig has no benefit. It is also true that in every programming language with manual memory management, you need to think about ownership (i.e. finding the safe place to deallocate memory). Rust enforces you to do so. Zig and C allow the mistakes that cause so much pain on the internet.
"you should learn all the things"
You know I'm not gonna do that, Ed.... my brain isn't big enough yet
Don't forget that rust compilation takes so long that you start wondering if it wasn't better to write in python, then at least your users would be suffering and not you.
Is Zig suitable as a first programming language? Is it worth investing your time in it?
if you want to get into low-level systems programming, absolutely. learning zig will also make the transition to learning C much easier.
Zig is fun and the community is cool. Worst thing as a beginner's language is just the basic difficulty typing .what = .{ .thing = .etc } a bunch
Kinda the antithesis to python that way...
It is, but i wouldn't learn it as a first language.
Don't get me wrong, Zig is my *favourite* language, but i think as a first language you should learn something stable with a good foundation (I started with C++, and would always not recommend it, but instead i'd recommend C.)
@@not_kode_kun one more thing to consider is the available resources to learn the language. C/C++ being older language seems to have an advantage over zig on this matter. So, maybe learning C/C++ to get familiar with low level stuff and switching would be much easier, no?
@@s0laret012 Thanks for the recommendation!
I've already tried Rust and I found it comparable to climbing Mt. Everest one way. 😀
”Learning is how you become a better person”. Love it!
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.
so basically c++ raii but with extra steps and some syntactic sugar. c++ without the `new` and `virtual` and `throw` keywords is basically C but better, idk why people hate on it so much as a systems language.
Its just a skill issue, its easy for a bad dev to do lots of bad stuff in C++ when running at system level
C++ is the definition of extra steps and syntactic sugar.
Because C++ sucks, it's not ergonomic, it's not fun, it's very bloated and hard to read. Zig achieves 90% of the power of C++ while remaining very readable, understandable, and that's why it's worth talking about. I love C++, but this language, is just not a good language compared to what exist today, it's hard to collaborate with people, it's hard to use some else's code because you have to audit it all to make sure it works like you want it to work. It's hard to debug with templates, the error messages aren't good, the compiler is quite slow, but the real problem is the amount of features available in the language, and how you can basically do everything with everything. I know people don't like to hear about it, but at the end of the day a programming language is just a tool, not a church to go on a crusade for, everyone with an ounce of objectivity can see that C++ is just not a good language this days, when things like Rust, Zig, Odin, Jai, exist.
I just like that Zig has a central package manager and a modular build system while being a real alternative to C
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?
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.
ZIG ONTOP!
U power bottle 🍼 🤪 om
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.
The defer keyword is a cool idea- easy to use and easy to implement if scoping is already in place.
"stole" that from Go.
Can be a double edged sword tho since it can make control flow hard to follow, similarly to GOTO statements.
@@m0llux "Stole" what? RAII has been around since the 80s with C++ and Ada. Those defer statements are essentially destructors in practice.
@@m0llux in the video is not mentioned, but defer is scoped by a block, not by a function
Scoped deallocation could have been done more cleanly by just throwing a "local" or "auto" keyword in front of the allocation. In fact, almost all the features of these new languages like Rust could be added cleanly to existing languages, without inventing new languages. Well, cleanly added to any language but C, which is a hot mess.
@@udasai that idea was toyed around syntactically, it provides problems if you don't have destructor as a concept, and zig does not have it. The language have no context around those semantics.
At the end defer is the method we got, and there are still posibilities but unlikely we get in zig the autoclean function.
Also having a keyword doing it requires knowing which resources are being allocated, while here we talk about heap, defer is used for closing files and a number of other resource management op.
And for the adding to other languages, yes, but the fact you cannot add it yourself because you want it, have to go tru a bunch of process to get it in existing language, remember that is hard to implement something in existing languages without support.
It's not because it exists that is cool (it's not even a novelty) is the fact that it works nicely for the language objective
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.
Java checked exceptions are indeed not liked by many, and in C# they copied a majority of things from Java, but checked exceptions where never implemented.
But having error state represented by in functions in proper ways instead definitely is really powerful.
The old try catch exception system is basically a difficult to overcome legacy burden. I believe no new languages are to be expected designed with it anymore.
The actual important thing which I believe happened is functional programming becoming more main stream. Rust is obviously one of the best examples, but also more imperative languages like Go and Zig have been inspired by it.
Older examples are OCaml and F#, of which the first one was a major influence on Rust. But I expect other functional languages also do it, especially pure functional languages.
You should take a look at Odin. It's very much in the same space.
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.
How Zig compares to Odin?
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
Zig RULES!!!
Rust sucks
It's interesting that nobody is talking about Pascal, anymore. It's a mature and very powerful language and with freepascal available on most operating systems and cpu architectures and it's also a lot more safe than C.
Why not C++? I'm just curious, is it actually that problematic like the "blow the entire leg off" meme?
the language is just really hard to work with, there are just so many decades of bad design decisions stacked on top of each other that the language has become so bloated. they're trying to fix all of it now, but it's too little too late: c++20 concepts, c++20 views, c++23 expected, and so on.
@@arson5304 this you say in the context of system's programming or in general?
@@m1ch3lr0m3r0 in general, but that also includes systems programming
C++ remains my favorite systems programming language due to how features complete it is (compared to the other options), these upcoming ones are cool but I'm mostly looking forward to the changes it makes in future c++ updates as it learns from the competition
@@cantthinkofaname1029 lol i gave up trying to cope with the decades of bad decisions a long time ago, rust is so much better
beyond the eloquent and coherent explanations, above all i most liked your comment that we should all be learning everything, becuase learning makes us not only better programmers, but also better people. i whole heartedly agree.