It isn't difficult, but it is friction. You hit compile and a few seconds later you get an error that is unrelated to the change you wanted to test. I agree with all those errors once those changes are for production, but sometimes I wish the compiler would just shut up and let me test the actual change I just made to ensure it works.
Commenting out a few variables isn't always easy either. Every try to add const to a legacy C++ project - it can take days to fix all the errors resulting from adding const to something that clearly is const in usage. I don't know zig, but I wouldn't be surprised if sometimes you get into this type of situation in a large code base (does anyone have a very large code base in zig yet?)
Good habit, maybe, but it shouldn't cause a compilation failure.
Add to that the snowball effect: you comment out a variable, compile, and you get another error because commenting out variable a made variable b unused. Rinse and repeat.
It's a huge and totally unnecessary time sink.
It should be opt-in, so that it's a warning by default, and then, when I'm ready to push my code, I could run some --strict mode that would force me to clean up my code.
One of the features in go that makes it workable is you can assign it away via:
_ = somevar
That eliminates the unused chain problem. Not sure if zig included that part of the feature as well.
Generally I agree though. The main problem with forcing unused variables, imo, is that it forces you to think a certain way. When I'm exploring the solution space on something, those constraints feel inhibiting.
If one suggested this in any other language to suppress "unused variable" warnings it would be considered a lazy way to avoid fixing the issue.
Meanwhile the developer of Zig himself recommended doing this[0] which only shows what a bad idea it is to make this a compiler error imho. It encourages workarounds and enforces something we automated long ago in the form of dead code elimination.
>it's not like commenting out variables is difficult.
But if you comment var A that uses var B now B is unused and you need to commnet B, but now B was using a function parameter C and this param is unused now so you need to update the function signature (I do not use Go,Zig so maybe they did not forced you to also use all the function params my experience is with linters where ehwn you comment something then more unused warnings appear)
What are you talking about? I don't understand how you've never encountered variables depending on each other.
In any moderately complex function you'll have more than one expression, and those can depend on each other. And you want them to be named and assigned; it makes it easier to read and decode intent and debug things (unless you're one of those wizards who get it right on the first try every time, kudos to you then). I'd not approve a PR that inlines/embeds complex concepts within larger expressions just to avoid creating variables...
Of course I have encountered dependent variables, but if I have a long chain of unused variables that means that either that code is ready to go, or the code organization needs refactoring.
Ah yes, prototyping. The stage of coding where one has lots of snippets of code meant for trying things out quickly. Definitely a context full of long chains of dependent variables.
Dude, it is about debugging, or work in progress...
Did you ever tried to debug some issue and start commenting stuff to try and find the problematic area? Hell when I comment stuff soemtimes private function will get unused , so with a shit compiler you would need to also comment the private functions, remove unused classes etc.
In my code I assure the linter will say 0 warnings.
I am seriously mind-blown that you've never encountered this problem in Go. You're trying something, and you see an error, you comment out a function and replace it with a print statement. And now suddenly you have to comment out a bunch of things up to the import statement just to fucking test out a simple hypothesis.
Possibly because the IDE helps with that. Including adding and removing import statements. I feel like this complaint is more theoretical than something felt by people using Go day to day.
People on the internet contradicts you, You remind me of the Apple fanboys and the keyboard issue , people complain that they keyboard has problems and the fanboys respond with "is working with me, you are using it wrong, you are stupid and probably eat at your keyboard, you broke it yourself"
All those people reporting the issue are not Go developers? Or maybe are not true Go developers, just the other kind, the ones that want generic and nice things.
But yeah, I am not a Go dev, I used linters and I would hate having to be forced to clear all the unused warnings before I can test the code.
As other said, it is not a good practice so inline all the code, I prefer well named variables, and I assume you can find examples in your code where you have a local variable that depends of a function parameter.
Funny enough I was correcting my son c++ homework yesterday, he had a complex if statement like
if (somefunction(m,n, y[j]) == m[j])
and I made him make a local variable to make it clear what is happening. then the code was easier to understand and debug because we culd print that local variable and see if is fine.
Btw, try not too respond that smug, you proved that you are an inexperienced coder and a shit person.
I'm not so sure about that one, despite clearly being in the company of people who feel attacked, I'm not the one attacking people here. I'm commenting on code practices, and baffled at other people's rage about the compiler demanding that you don't have unused variables, but I haven't attacked anyone.
You commented about my code quality, but I will assume you were in a rush and missunderstood that I was talking about work in progress stuff and debugging, so if that was teh case I apologize (if is not the case then you might understand in a few years)
Yes. If Zig takes 100ms to compile, and Rust takes 2s, but you just spent 20 seconds commenting unused vars in your Zig code, then the slow compiler comes out ahead. It's a great example of how good UX can be more important than raw performance numbers.
Yes, but you comment out unused variable once per variable (you can leave those underscores in and clear them out before release). The 2s happens every time you compile. The badness of slow compiles is non-linear, too. As you start to get to 30s, the likelihood that you check Facebook, Twitter, or hn goes up. At least when you're underscoring unused vars you're doing something active.
If it gets to 2-5 minutes the likelihood that you stop writing tests and rely on the compiler for bugfreeness goes up - or the likelihood that you create debt by increasing the complexity of your code organization.
It's really not a problem for me. I've worked on probably about 20k LOC of zig. Probably the one time it was an issue was when I wrote some code that wrote zig -- and then it pushed me into realizing that this was a code smell, and a refactoring fixed it.
Compile times of 2-5 minutes can happen in langs that are not rust. You mentioned rust, not me. And anyways the 30s to hn thing is real.
It is when you have chains of them: see Vulkan setup.
In Zig, I find that I put a whole litany of "_ = varname;" at the bottom of my functions (starting with the function arguments) and they stay there permanently. This is NOT an improvement.
However, it's not really enough to stop me from using the language as that's an easy thing to evantually fix.
