In some programming communities, 'names' are referred to as 'identifiers' because they are used to identify not only variables and constants but many other objects like functions, structs etc. Thanks for your video, I find it very informative. Cheers,
Great content, thanks for the knowledge! I'm on zig version 0.12.1 and, apparently, since version 0.12.0 you must declare your `var` a `const` if you never modify it. Not doing so will result in `error: local variable is never mutated`.
Yes that was one of the most noticeable changes in that release. It can be annoying at first, but in the long run it's the compiler helping you write better code. consts can be optimized much more than vars can by the compiler.
I'll see what I can do ti zoom in. I had previously tried a larger font but then the terminal would start wrapping lines and the code got a little harder to follow. But let's see if I can work around that.
I think Zig should warn the programmer of unused variables and functions. Sometimes I want to create a function, make all the parameters, and then add all the code later.
This has been a topic of much debate in the Zig community. I'n not sure there will be a change, but it's possible if enough users demonstrate a real-world need for this with examples and possible solutions.
Warnings create more problems than they solve. I so many times faced the situation that a project started with lax warning settings and people keep producing code that complies cleanly. Then after some time somebody realizes the benefits of some warning and people start cleanup sessions with thousands of warning or errors. Zig's approach of canonical or unambiguous code is much better. It adds a little boilerplate, but that's a small price to pay in a pinch and that small pain tends to create better code. Either because it's visible in the code that something is unused or because you finish the code fragment you're working on early. The git diff of a vanishing `_ = ...` also might have value.
@@michaelutech4786 Why not have a hybrid approach? You could have debug builds compile with warnings, and release builds compile with forced errors! Also, warnings don't affect the final binary. Compilers are smart enough to widdle things down. It is even to the point where anyone who argues that switch is faster than if is just wrong!
@@oglothenerd It's not as if your proposition wouldn't work and even work well when used responsibly. The problem arises when people don't think it through. That should not be a problem, unless you checkout the last version and your formerly clean build now throws 12000 warnings or errors. That happened to me more than once and as far as I can tell it was never my fault. I always work in pedantic mode in languages that have warning level flags ever since that happened the first time. But often in projects I worked in, I was not in charge to setup the project and those who do often don't care for such things. Yet I got hit with this hell over and over again. Zig is designed to be unusually unambiguous. I love that, because there are little to no flame wars about commas, tabs and similar things. Something like unused items are not essential or even really important. But since it's so easy to just `_` unused items, it quickly becomes an inexpensive habit. Often it takes little more time to just finish the implementation instead of adding a TODO. But I see that I am very conservative in this regard. I also don't like to pay with credit cards or cheques and prefer to use cash. Debts are uncomfortable if not worse. Even technical debts.
`0xa.a` has got to be the weirdest way to visualize a number.... I can't think of any scenario in which my brain would actually prefer this over `10.625`
language is great but i am not sure about the undefined thing. What's the point of that, is it optimaztion related, cause in other language linter anyway tells that to users.
You could say that Zig tries its best to avoid using even one single CPU cycle if it's not necessary and you don't tell it to do so. Writing a default value to memory takes CPU cycles, which at a very low level could make a difference, for example in extremely low memory and CPU microcontrollers, where every byte and cycle count. So undefined serves the purpose of saying "I nned space for a variable of this type, but for now, don't do anything with that space."
I think that when staying in a Zig-only project, booleans would pretty much rule out the need for u1 as an "on", "off", "yes", or "no" flag mechanism. But when integrating with existing C code, maybe then u1 being a true integer would ease compatibility with that type of usage which is common on the C side. Even so, the builtin @intFromBool allows you to use booleans all the time and only switch to the u1 when absolutely necessary.
I've used u1 as a the type of an enum that stores only 2 choices, but shouldn't be represented as a boolean. For example `direction: enum(u1) { horizontal, vertical, } = .horizontal, `
In Zig, anything marked as comptime or within a comptime block is evaluated during the compilation of the program, so it can improve runtime performance by eliminating this evaluation cost and inserting the result of the evaluation directly in the binary executable.
In some programming communities, 'names' are referred to as 'identifiers' because they are used to identify not only variables and constants but many other objects like functions, structs etc. Thanks for your video, I find it very informative. Cheers,
Yes, "identifiers" is the best, more accurate term. I guess "names" was just shorter to fit on the title thumbnail! lol
Great content, thanks for the knowledge!
I'm on zig version 0.12.1 and, apparently, since version 0.12.0 you must declare your `var` a `const` if you never modify it. Not doing so will result in `error: local variable is never mutated`.
Yes that was one of the most noticeable changes in that release. It can be annoying at first, but in the long run it's the compiler helping you write better code. consts can be optimized much more than vars can by the compiler.
Great content ! Please zoom in (increase font size), to help in using lower resolutions.
I'll see what I can do ti zoom in. I had previously tried a larger font but then the terminal would start wrapping lines and the code got a little harder to follow. But let's see if I can work around that.
I think Zig should warn the programmer of unused variables and functions. Sometimes I want to create a function, make all the parameters, and then add all the code later.
This has been a topic of much debate in the Zig community. I'n not sure there will be a change, but it's possible if enough users demonstrate a real-world need for this with examples and possible solutions.
@@dudethebuilder I did suggest it in the Zig GitHub.
Warnings create more problems than they solve. I so many times faced the situation that a project started with lax warning settings and people keep producing code that complies cleanly. Then after some time somebody realizes the benefits of some warning and people start cleanup sessions with thousands of warning or errors.
Zig's approach of canonical or unambiguous code is much better. It adds a little boilerplate, but that's a small price to pay in a pinch and that small pain tends to create better code. Either because it's visible in the code that something is unused or because you finish the code fragment you're working on early. The git diff of a vanishing `_ = ...` also might have value.
@@michaelutech4786 Why not have a hybrid approach? You could have debug builds compile with warnings, and release builds compile with forced errors! Also, warnings don't affect the final binary. Compilers are smart enough to widdle things down. It is even to the point where anyone who argues that switch is faster than if is just wrong!
@@oglothenerd It's not as if your proposition wouldn't work and even work well when used responsibly. The problem arises when people don't think it through.
That should not be a problem, unless you checkout the last version and your formerly clean build now throws 12000 warnings or errors.
That happened to me more than once and as far as I can tell it was never my fault. I always work in pedantic mode in languages that have warning level flags ever since that happened the first time. But often in projects I worked in, I was not in charge to setup the project and those who do often don't care for such things. Yet I got hit with this hell over and over again.
Zig is designed to be unusually unambiguous. I love that, because there are little to no flame wars about commas, tabs and similar things. Something like unused items are not essential or even really important. But since it's so easy to just `_` unused items, it quickly becomes an inexpensive habit. Often it takes little more time to just finish the implementation instead of adding a TODO.
But I see that I am very conservative in this regard. I also don't like to pay with credit cards or cheques and prefer to use cash. Debts are uncomfortable if not worse. Even technical debts.
apparently zig writes 0xaa when you use undefined. so the 170 showing up wasnt random and can be a clue when debuggin weird behaviour
Good catch!
mine also 170.. so it is not garbage?
`0xa.a` has got to be the weirdest way to visualize a number.... I can't think of any scenario in which my brain would actually prefer this over `10.625`
I've yet to see a practical use of hex notation for floats, but if it's there, I guess someone needed it. lol
language is great but i am not sure about the undefined thing. What's the point of that, is it optimaztion related, cause in other language linter anyway tells that to users.
You could say that Zig tries its best to avoid using even one single CPU cycle if it's not necessary and you don't tell it to do so. Writing a default value to memory takes CPU cycles, which at a very low level could make a difference, for example in extremely low memory and CPU microcontrollers, where every byte and cycle count. So undefined serves the purpose of saying "I nned space for a variable of this type, but for now, don't do anything with that space."
15:00 - Curious when a u1 would be useful as opposed to a boolean.
I think that when staying in a Zig-only project, booleans would pretty much rule out the need for u1 as an "on", "off", "yes", or "no" flag mechanism. But when integrating with existing C code, maybe then u1 being a true integer would ease compatibility with that type of usage which is common on the C side. Even so, the builtin @intFromBool allows you to use booleans all the time and only switch to the u1 when absolutely necessary.
@@dudethebuilder Thank you. I'm not deeply familiar with C but that makes sense.
I've used u1 as a the type of an enum that stores only 2 choices, but shouldn't be represented as a boolean. For example `direction: enum(u1) {
horizontal,
vertical,
} = .horizontal,
`
Where a comptime tag can be helpful? 🤔
In Zig, anything marked as comptime or within a comptime block is evaluated during the compilation of the program, so it can improve runtime performance by eliminating this evaluation cost and inserting the result of the evaluation directly in the binary executable.