Well, having tried both C and Zig, I would argue that C is the better language. In C you can do things your way. (Unlike in the video, you do not have to use integers for error handling, you can do it the way you prefer (tagged unions, out parameters, a thread local error log, ...). Also saying that Zig solves UB is just plain wrong, in some respects Zig has more UB (although more consistent) like Zig has undefined behaviour for unsigned integer types, whereas C does not. Both languages offer some tooling to deal with that (releasesafe, UBSAN). The advantage of C is, that it is still the language of native system interfaces, it has a stable ABI so it can act as intermediary between languages and it is standardised. It has many problems, for sure, but they are well known and good C programmers know how to work around them. On the other hand, I think Zig's killer features are comptime, builtin slices, async and null safety. BTW: I do not like the Zig developer experience, it has no ways to configure compiler warnings (it just has errors, and even complains about minor details like whitespace), it's error messages are not that good, it is slow to compile (gcc is fast especially for unity builds, but everyone talks about GO's compilation times). The syntax is a little noisy too. Zig's greatest feature is actually the builtin C compiler, it makes it easy to compile your C code cross-platfrom, it is easy to install and takes up little space (I am looking at you Visual Studio C). some people use Zig as their build system, I have not tried that though, and it does not solve the fragmented landscape of C and C++ build systems.
You can manage your errors the C way in Zig if you want, of course. With the extra that you will have tuples to return multiple values instead of using out parameters (which you still can if you want) and the brand-new syntax to "destructure" it, as well as defer, and errdefer, and the killer features you mentioned.
I'm loving it. I think the code is reviewable. No overrides, and I'm not writing exception code to escape Rust's paradigm, the borrow-checker liability boundary. That makes the code idiomatic, and alloc/defer a straightforward positive process. I'm simply not fighting the Zig code. It seems to be code trick detox for me. Async is missing. Don't sweat it; that makes it safe right now. io_uring in the kernel is being security patched. You can try libxev, libuv, or mess with C's s_task.
any plan making a Zig tutorial series? would be awesome since current Zig references are a bit difficult to find...another plus Zig looks to be the hype of 2024. Major devTubers / devTwitchers are covering it.
programming in c, heck even reading c code and compiling it/ reading up on the issues surrounding it/ the surrounding ecosystem of tools and dependencies really makes me not wanna use it in the modern age(maybe im just not smart enough still) . Zig for me solves this by letting me get out of the hell of a zillion make tools to choose from and amazing interoperability with existing C making it it an exceptional addition to your toolbelt without the fear of missing out of the C ecosystem . i believe zig is the future of systems programming due to all the problems it eases and solves. And FYI rust doesn't replace zig /zig doesn't replace rust.. they both have a place in the future of low level programming.
@kodaps what’s crazy is I just commented on another video before this one asking why and what and who, etc. and this video answered it very well. Now I gotta decide if C is worth learning for my goals hence if I should be thinking about learning ZIG. Thank you and well done.
I would love to use Zig for bigger stuff IF it was less annoying about the dev experience and normal debugging techniques. A random unused variable or a var that never mutates being considered breaking compiler errors without any way to turn it off feels extremely tedious, when you have no intention of commenting and removing everything like that with every compile.
@@metaphoricallyalive8109 What safety? So that I can't comment a function call to debug it because 3 vars get unused and I go to comment them which causes another 2 to get unused? Forcing that for dev builds with no way to turn it off is anti user experience. And I think Rust has them as warnings, not sure.
@@Leonhart_93 I totally agree with you. For someone, just starting out it's highly annoying and soul destroying. But in professional code it's pretty much a "must have". It's a shame we can't have a -professional or -amateur switch on the zig build.
@@testing-nj2ne It's perfectly possible. If C allows it and they get optimized by the compiler anyway, then what's the problem? Besides, that's why there are dev builds and release builds. Only that for these new languages there are no dev builds anymore, everything you write has to be no-chill.
@@metaphoricallyalive8109 Rustc issues a warning. Zig does not have the concept of warning it straight up refuses to compile. An unused variable by itself is not safety critical. It is just annoying to get the error while developing, for production code not having them is the right approach imho.
I can see a future with zig especially with embedded programming, tho I wonder if rust will somehow make a really good developer experience tho comptime in rust is... well. Anyway on the other hand Odin seems interesting would recommend checking it out, its competitive in the computer graphics space but I wonder if there is a future with embedded systems programming for Odin.
Rust's good developer experience is purely subjective. I can tell quite clearly, it's not popular with those developers that don't like to be told what to do by some layers of abstraction. From my point of view it's either low level control or not, not much in between. That being said Zig also has some annoying stuff built-in, forcing you to do things in specific ways in your own code. Like unused vars being hard errors, it's incredibly disrupting for debugging.
It has been TEMPORARILY removed because there are some big issues to solve. These problems are not impossible to solve but it takes time. But they're definitely planning to add them back. Check the 0.12 change log it's mentioned there.
@@nothke it is not 100% sure that they are going to add it, there is a github discussion I couldnt find where they discuss if they truly want this or not.
Concurrency is not just about async/await. You can easily spawn a Thread in Zig without knowing the intricate implementation details of it. I.e. windows,posix,linux,wasi implementations. It is a native language in Zig. Just read the documentation you'll easily find it in Zig Standard Library. And that is why he mentioned "multi-threaded applications"
A problem with Odin, is that it is "owned" and funded by a company. A company has to extract money for it's shareholders. It might start with a "Don't be evil" motto. But legally they have a fiduciary responsibility to the bottom line. Zig is owned by a non profit. A non profit has to put it's profits back into the mission.
I think it's because there's few people uses it so any small fluctuation affects the average easily. It is also the reason vatican city has the highest murders per capita. Can't remember the name of the phenomenon.
@@KodapsAcademy I really don't know the answer to that. Perhaps we should hold off on making really ambitious software in it right now, but as a counterexample - bun
i think your notion about zig's error handling is misinformed, it's meant to be a replacement for exception handling in other languages, not to inherently protect you from memory related issues. rust has this same feature so it's not really contrasting in that sense.
Nothing will replace C in low level programming as long as we go with the Von Neumann architecture although Rust fanboys are trying to convince everyone otherwise
You might be surprised. I had only used Go and Python previously, picked up Zig fairly quickly. Once you start understanding manual memory management it gets really easy
Zig's lack of a first-class package manager is a huge red flag. One of the main reasons languages like Rust succeeded is because of tools like cargo, which streamline dependency management and eliminate the linker/configuration headaches that plague C and C++. Zig risks inheriting all the downsides of C without solving the ecosystem problems, making it less appealing for developers who value productivity.
@@KodapsAcademy Sure it does. It has an extensive FFI to interop with C. I've personally written Rust code that calls into C and C code that calls into Rust.
@@guitargyro I get your point. The difference is that FFIs function on a binary to binary level, whereas Zig's interop is at the code level. But I guess your point still holds :)
Zig compiler compiles c/c++ in the hopes to clean up the build system and make os portability much easier. As for your rust argument, I think we already have a robust, proven language like this: it's called c++
Well, having tried both C and Zig, I would argue that C is the better language. In C you can do things your way. (Unlike in the video, you do not have to use integers for error handling, you can do it the way you prefer (tagged unions, out parameters, a thread local error log, ...). Also saying that Zig solves UB is just plain wrong, in some respects Zig has more UB (although more consistent) like Zig has undefined behaviour for unsigned integer types, whereas C does not. Both languages offer some tooling to deal with that (releasesafe, UBSAN). The advantage of C is, that it is still the language of native system interfaces, it has a stable ABI so it can act as intermediary between languages and it is standardised. It has many problems, for sure, but they are well known and good C programmers know how to work around them. On the other hand, I think Zig's killer features are comptime, builtin slices, async and null safety.
BTW: I do not like the Zig developer experience, it has no ways to configure compiler warnings (it just has errors, and even complains about minor details like whitespace), it's error messages are not that good, it is slow to compile (gcc is fast especially for unity builds, but everyone talks about GO's compilation times). The syntax is a little noisy too.
Zig's greatest feature is actually the builtin C compiler, it makes it easy to compile your C code cross-platfrom, it is easy to install and takes up little space (I am looking at you Visual Studio C). some people use Zig as their build system, I have not tried that though, and it does not solve the fragmented landscape of C and C++ build systems.
There are a bunch of examples of people porting their c/c++/make/ninja/etc build into just zig. Its very streamlined.
You can manage your errors the C way in Zig if you want, of course. With the extra that you will have tuples to return multiple values instead of using out parameters (which you still can if you want) and the brand-new syntax to "destructure" it, as well as defer, and errdefer, and the killer features you mentioned.
I'm loving it. I think the code is reviewable. No overrides, and I'm not writing exception code to escape Rust's paradigm, the borrow-checker liability boundary. That makes the code idiomatic, and alloc/defer a straightforward positive process. I'm simply not fighting the Zig code. It seems to be code trick detox for me. Async is missing. Don't sweat it; that makes it safe right now. io_uring in the kernel is being security patched. You can try libxev, libuv, or mess with C's s_task.
any plan making a Zig tutorial series? would be awesome since current Zig references are a bit difficult to find...another plus Zig looks to be the hype of 2024. Major devTubers / devTwitchers are covering it.
read language reference, if you have experience with c, c++, rust or go you thrive, if not you should really learn c first before going to zig
programming in c, heck even reading c code and compiling it/ reading up on the issues surrounding it/ the surrounding ecosystem of tools and dependencies really makes me not wanna use it in the modern age(maybe im just not smart enough still) . Zig for me solves this by letting me get out of the hell of a zillion make tools to choose from and amazing interoperability with existing C making it it an exceptional addition to your toolbelt without the fear of missing out of the C ecosystem . i believe zig is the future of systems programming due to all the problems it eases and solves. And FYI rust doesn't replace zig /zig doesn't replace rust.. they both have a place in the future of low level programming.
@kodaps what’s crazy is I just commented on another video before this one asking why and what and who, etc. and this video answered it very well. Now I gotta decide if C is worth learning for my goals hence if I should be thinking about learning ZIG. Thank you and well done.
I would love to use Zig for bigger stuff IF it was less annoying about the dev experience and normal debugging techniques. A random unused variable or a var that never mutates being considered breaking compiler errors without any way to turn it off feels extremely tedious, when you have no intention of commenting and removing everything like that with every compile.
Isn't that for better safety? I'd guess rustc makes you do the same?
@@metaphoricallyalive8109 What safety? So that I can't comment a function call to debug it because 3 vars get unused and I go to comment them which causes another 2 to get unused?
Forcing that for dev builds with no way to turn it off is anti user experience.
And I think Rust has them as warnings, not sure.
@@Leonhart_93 I totally agree with you. For someone, just starting out it's highly annoying and soul destroying. But in professional code it's pretty much a "must have". It's a shame we can't have a -professional or -amateur switch on the zig build.
@@testing-nj2ne It's perfectly possible. If C allows it and they get optimized by the compiler anyway, then what's the problem?
Besides, that's why there are dev builds and release builds. Only that for these new languages there are no dev builds anymore, everything you write has to be no-chill.
@@metaphoricallyalive8109 Rustc issues a warning. Zig does not have the concept of warning it straight up refuses to compile. An unused variable by itself is not safety critical. It is just annoying to get the error while developing, for production code not having them is the right approach imho.
I can see a future with zig especially with embedded programming, tho I wonder if rust will somehow make a really good developer experience tho comptime in rust is... well. Anyway on the other hand Odin seems interesting would recommend checking it out, its competitive in the computer graphics space but I wonder if there is a future with embedded systems programming for Odin.
Rust's good developer experience is purely subjective. I can tell quite clearly, it's not popular with those developers that don't like to be told what to do by some layers of abstraction. From my point of view it's either low level control or not, not much in between.
That being said Zig also has some annoying stuff built-in, forcing you to do things in specific ways in your own code. Like unused vars being hard errors, it's incredibly disrupting for debugging.
how are you highlighting the screen with boxes and arrows ?
Hi, I'm using a piece of software called "Presentify" setapp.sjv.io/c/4172596/849350/5114 :)
@@KodapsAcademythanks!
its not true to say the concurency is a native language feature in zig, async/await has been dropped since 0.11 if i remember correctly
It has been TEMPORARILY removed because there are some big issues to solve. These problems are not impossible to solve but it takes time. But they're definitely planning to add them back. Check the 0.12 change log it's mentioned there.
@@nothke it is not 100% sure that they are going to add it, there is a github discussion I couldnt find where they discuss if they truly want this or not.
@@nothke where does it says "TEMPORARILY"? changelog itself says async/await future is unclear lol
Concurrency is not just about async/await.
You can easily spawn a Thread in Zig without knowing the intricate implementation details of it. I.e. windows,posix,linux,wasi implementations.
It is a native language in Zig. Just read the documentation you'll easily find it in Zig Standard Library.
And that is why he mentioned "multi-threaded applications"
what's your opinion of Odin if you have checked it?
A problem with Odin, is that it is "owned" and funded by a company. A company has to extract money for it's shareholders. It might start with a "Don't be evil" motto. But legally they have a fiduciary responsibility to the bottom line.
Zig is owned by a non profit. A non profit has to put it's profits back into the mission.
@@testing-nj2ne owned? funded? company? shareholders? what the fuck are you talking about?
@@testing-nj2ne It is not owned by anyone but myself. And Odin is mostly funded by donations too. Please stop saying nonsense.
But, didn't answer the question: Why Zig pays more?
probably because of tiger beetle look it up
It's due to low supply. If you need Zig specifically, you don't have a big pool of candidates.
I think it's because there's few people uses it so any small fluctuation affects the average easily. It is also the reason vatican city has the highest murders per capita. Can't remember the name of the phenomenon.
ok. but breaking changes in every sub-version is not a good idea. But of course I prefer it more than Rust
That was (partly) my point in the conclusion :)
I agree but Zig is a much newer language and only like v0.12. I'm sure rust also had breaking changes at that version
@basit005 sure. But the underlying question is : is it stable enough to warrant investing time in at this stage ?
@@KodapsAcademy I really don't know the answer to that. Perhaps we should hold off on making really ambitious software in it right now, but as a counterexample - bun
Yeah but the goal is to be finished at 1.0. I love the idea of a finished language.
Love your vids! Keep em coming.
i think your notion about zig's error handling is misinformed, it's meant to be a replacement for exception handling in other languages, not to inherently protect you from memory related issues. rust has this same feature so it's not really contrasting in that sense.
Rust is much more complete, Rust doesn't have NULL, and Rust doesn't have exceptions, it is all part of the type system.
Thanks for the vid ❤
Glad to be of service :)
the macro thing in rust is making things impossible for me to learn. so i'm will learn zig once it hits 1.0.
Nothing will replace C in low level programming as long as we go with the Von Neumann architecture although Rust fanboys are trying to convince everyone otherwise
you should have said I'll zig you in this next video instead of I'll C you in this next video
Clearly a missed opportunity :D
it looks quite intimidating to a lowly c# pleb like myself but it peaks my interest
I'm gad the video intrigued you, I hope it ends up being useful in the long term :)
You might be surprised. I had only used Go and Python previously, picked up Zig fairly quickly. Once you start understanding manual memory management it gets really easy
Dude, People rushing to Zig and Rust just like they did with Go and other languages. You cant compare C as if its another language
Why learn Zig if there is C3?
Clickbait title.
Zig's lack of a first-class package manager is a huge red flag. One of the main reasons languages like Rust succeeded is because of tools like cargo, which streamline dependency management and eliminate the linker/configuration headaches that plague C and C++. Zig risks inheriting all the downsides of C without solving the ecosystem problems, making it less appealing for developers who value productivity.
Can Zig pay my bills?
Only the auto-mow bills :D
C is old so use Zig - if that's your main excuse then go ahead...
In short, if you have existing C projects, use Zig to fix it. If not, use Rust for new projects.
Rust is better for it's maturity. Zig is more promising.
The problem with Rust is a lot of people don't like Rust.
Zig is not suitable for beginners to learn, because they emphasize learning C first.
I think we already have a robust, proven language like this: it's called Rust.
@@guitargyro Zig’s main strength here is its interoperability with C, which doesn’t really exist with Rust
@@KodapsAcademy Sure it does. It has an extensive FFI to interop with C. I've personally written Rust code that calls into C and C code that calls into Rust.
@@guitargyro I get your point. The difference is that FFIs function on a binary to binary level, whereas Zig's interop is at the code level. But I guess your point still holds :)
Zig compiler compiles c/c++ in the hopes to clean up the build system and make os portability much easier.
As for your rust argument, I think we already have a robust, proven language like this: it's called c++
Yeah, if you're willing to sacrifice all your productivity, and spend months learning the language, Rust is fine