The current title "How Zig improved C" got me thinking that Zig somehow changed C. After watching the video, this is not the point you make. Its more about what Zig does different (better) than C. Besides good content!
C Is unfixable because of backwards compatibility and standardization (even in the case of using a new standard you can always compile in old C, and it takes ages to get a new feature to be included in a new standard revision). That's why Zig was invented, it does not have to support C weirdness, but rather use the parts that make sense and build upon them.
@@JonitoFischer I think this is quite a common misconception, to my knowledge C standards really don't have to be very backwards compatible. There are also some really promising developments in C23 (with many more to come) due to people like thephdev trying to improve the language and its std lib.
I really don't understand the point of zig, I am genuinely curious to hear what people think of it and why do they like it, since i am a fan of both rust and c/c++, but I just don't see where zig fits in. For example all features shown in this video can be easily implemented in both c and c++ if a developer wished to use these design patterns. I feel like rust really fulfills the role of the memory safe language that forces ground breaning design patterns like Option and Result and the ? operator and many more. While c/c++ are languages that let you do whatever you wish full stop. But i just don't see why i would should use zig iver these two
I think the main selling point is a better ecosystem and better builds. If I had to think of a language level of problem then the defer keyword and error are what comes to mind compared to c (they are in rust but rust comes with a value proposition that not everyone using c wants)
it doesn't compete with C++ or rust, it competes with C sure, 90% of stuff zig does differently than C you can emulate it using features that were added in the last 2 versions of the language, macros, compiler flags, sanitizers and analyzers, but zig comes with all that already. C's standard library is just horrible, there is just one allocator, functions implicitly heap allocate everywhere, IO is implicitly buffered, you are forced to use 0 terminated strings, everything is bad to be 100% backwards compatible with how it was 40 years ago. language fundamentals are flawed, there are so many rules like strict aliasing, usual arithmetic conversions, etc that makes it feel the language is unnecessarily working against you if you list all the undefined behaviour C has, zig only has a small portion of that and most are caught either at compile time or runtime in debug builds.
@@salim444I didn't know how much improvement the build system in zig brought. I genuinely relate to this a lot since a very big reason why i use rust is package management and the build system and the tools around it. If zig brings a more manageable build system and a reliable package manager that is completely backward compatible with c i will actually consider this for my projects. Remains to see how the language evolves and its ease of use, but i'm looking forward to a functional system
@@MatthisDayerI totally see your point but I think that is mostly personal preference. I don't mind making my own alocators or implementing some features. I also don't really have an issue with the standard library, it has it's own twisted logic that i can get around. But I 1000% see how it can be a hassle and why it is anoying to a lot of people. Although as I mentioned in the comment above if zig brings a better build system + package manager I will actually consider the language as a tool to be used in parallel with c or just straight up on it's own since it looks like it carries a bit of the c style
@@iliedemian8461 not a zig expert but that is, I think, its value proposition. In two interviews I saw of Loris Cro (possibly misspelled) he talks about how easy it is to cross compile and interact with c libraries (I used raylib and it is okay on windows and linix) and compared it to using makefiles. Anyway hope I helped, happy zigging or rusting ;)
I'm guessing you're talking about the curly braces being on a different line. This is just my personal preference as I think it's a lot easier to read when it's not on the same line. On the same line: fn function() void { for (0..10) |i| { for (0..10) |j| { if (j < i) { continue; else { //Do something } } } } On the next line: fn function() void { for (0..10) |i| { for (0..10) |j| { if (j < i) { continue; } else { //Do something } } } } People honestly think that the first example is easier to read?
@@CodingWithTom-tn7nl Neither is easier or harder it's really just subjective. It depends more on habit. You're just doing what you're used to. But I think it can make people think you are not doing zig seriously even though your videos are brilliant.
The current title "How Zig improved C" got me thinking that Zig somehow changed C. After watching the video, this is not the point you make. Its more about what Zig does different (better) than C. Besides good content!
It should have been "improved upon C".
C Is unfixable because of backwards compatibility and standardization (even in the case of using a new standard you can always compile in old C, and it takes ages to get a new feature to be included in a new standard revision). That's why Zig was invented, it does not have to support C weirdness, but rather use the parts that make sense and build upon them.
@@JonitoFischer I think this is quite a common misconception, to my knowledge C standards really don't have to be very backwards compatible. There are also some really promising developments in C23 (with many more to come) due to people like thephdev trying to improve the language and its std lib.
I thought this is gonna be about build.zig
Rewrite Rust in Zig!!!
"Even though C is written in Windows" - 11:59
Other than that, I think the video's pretty good!
Didn't you know that C was written in Windows?
Obviously I misspoke and it wasn't worth rerecording and reuploading the video for that.
I think the points you make in this video compared to th previous version are more compelling. Thanks for the video !
this video was great! well done
I really don't understand the point of zig, I am genuinely curious to hear what people think of it and why do they like it, since i am a fan of both rust and c/c++, but I just don't see where zig fits in.
For example all features shown in this video can be easily implemented in both c and c++ if a developer wished to use these design patterns. I feel like rust really fulfills the role of the memory safe language that forces ground breaning design patterns like Option and Result and the ? operator and many more. While c/c++ are languages that let you do whatever you wish full stop. But i just don't see why i would should use zig iver these two
I think the main selling point is a better ecosystem and better builds. If I had to think of a language level of problem then the defer keyword and error are what comes to mind compared to c (they are in rust but rust comes with a value proposition that not everyone using c wants)
it doesn't compete with C++ or rust, it competes with C
sure, 90% of stuff zig does differently than C you can emulate it using features that were added in the last 2 versions of the language, macros, compiler flags, sanitizers and analyzers, but zig comes with all that already.
C's standard library is just horrible, there is just one allocator, functions implicitly heap allocate everywhere, IO is implicitly buffered, you are forced to use 0 terminated strings, everything is bad to be 100% backwards compatible with how it was 40 years ago.
language fundamentals are flawed, there are so many rules like strict aliasing, usual arithmetic conversions, etc that makes it feel the language is unnecessarily working against you
if you list all the undefined behaviour C has, zig only has a small portion of that and most are caught either at compile time or runtime in debug builds.
@@salim444I didn't know how much improvement the build system in zig brought. I genuinely relate to this a lot since a very big reason why i use rust is package management and the build system and the tools around it. If zig brings a more manageable build system and a reliable package manager that is completely backward compatible with c i will actually consider this for my projects. Remains to see how the language evolves and its ease of use, but i'm looking forward to a functional system
@@MatthisDayerI totally see your point but I think that is mostly personal preference. I don't mind making my own alocators or implementing some features. I also don't really have an issue with the standard library, it has it's own twisted logic that i can get around. But I 1000% see how it can be a hassle and why it is anoying to a lot of people. Although as I mentioned in the comment above if zig brings a better build system + package manager I will actually consider the language as a tool to be used in parallel with c or just straight up on it's own since it looks like it carries a bit of the c style
@@iliedemian8461 not a zig expert but that is, I think, its value proposition. In two interviews I saw of Loris Cro (possibly misspelled) he talks about how easy it is to cross compile and interact with c libraries (I used raylib and it is okay on windows and linix) and compared it to using makefiles. Anyway hope I helped, happy zigging or rusting ;)
Thanks for video. Hope you will improve mic sound quality.
Please please please stop formatting Zig like C in your videos.
That's another thing zig's improved over c. Zig fmt puts '{' on the same line 😉
I'm guessing you're talking about the curly braces being on a different line. This is just my personal preference as I think it's a lot easier to read when it's not on the same line.
On the same line:
fn function() void {
for (0..10) |i| {
for (0..10) |j| {
if (j < i) {
continue;
else {
//Do something
}
}
}
}
On the next line:
fn function() void
{
for (0..10) |i|
{
for (0..10) |j|
{
if (j < i)
{
continue;
}
else
{
//Do something
}
}
}
}
People honestly think that the first example is easier to read?
@@CodingWithTom-tn7nl Neither is easier or harder it's really just subjective.
It depends more on habit. You're just doing what you're used to.
But I think it can make people think you are not doing zig seriously even though your videos are brilliant.
@@CodingWithTom-tn7nl Yes its easier for me to read the first example. Also we have this as a code style rule at my job
Zig is a joke!