> But nothing gets in your face how to use the programming language "correctly".
It doesnt let you have unused variables and theres no multiline comment support. These are fairly significant productivity issues for me
It doesnt let you have unused variables and theres no multiline comment support. These are fairly significant productivity issues for me
Ugh. This is something I hate about Go. I would be happy to have unused variables generate warnings, but as errors, they turn the toolchain into an adversary.
It's common for me to temporarily comment out a variable's use when developing new code, as I experiment with ideas. It's even more common when working in unfamiliar code, such as tracking down a bug or incrementally adding a new feature. It's an important part of my exploration process.
When I hit Compile at that point, I expect the compiler to build the work-in-progress exactly as it is in that moment. Executing the output allows me to spot check the snapshot's behavior against my expectations and mental model. The compile step also assures me that no syntax errors have crept in while I was focused on the logic flow or general shape of the code.
When a compiler refuses to do its job, and instead barfs up spurious errors complaining about unused variables, it brings my workflow to a screeching halt. In order to make progress, I am forced to abruptly leave my current context to visit all the different places where those variables are introduced, edit them, try again, discover that those forced edits have left more variables unused, and repeat the process until the combative compiler shuts up and does what I told it to do in the first place. By the time I'm allowed to return to what I was doing, my train of thought has been derailed, the bits of logic that I had been juggling have fallen to the ground, and my focus destroyed. And then, once I have recovered my original thoughts and seen the output of my snapshot build, I have to go back and revert all those forced edits before I can resume my work.
What an aggravating, disruptive, and completely unnecessary waste of my time and attention.
I hope Andrew has the good sense to let errors of this kind be silenced or demoted to warnings, perhaps with a compiler flag or debug build mode.
Yeah it drives me insane. Working in any ide's golang lsp/plugin that tries to solve this for you every time you hit save also drives me insane. Feel like something is lost experiencing/learning/becoming masterful at a language when these types of decisions get automated while you're hand crafting.
I actually really valued my exploration into C where if i did that, id get a fat warning on compile, but I could still proceed to test my stuff. When I'm ready to commit to some cleanup efforts which is usually a headspace-thing, then I go cruise around and cleanup unused variables.
I know I'll need so-and-so import, so i write it at the top of the file before i even start, I press ctrl-s and it dissapears... I honestly laughed out loud the first time i used gopls.
Overall the code gets smaller and easier to understand when it only has things that need to be there. If you comment out a an unused variable you can see from find-results that in effect that occurrence cannot matter.
Unused variables are "noise" that hide actually important things.
If they wanted the release build to be an error I wouldn't care. Having the current solution be "have the editor automatically change code to include or remove the underscore" is so wrong to me. Just invented a problem that needs tooling to modify source code to fix.
Andrew Kelly on that:
https://www.youtube.com/watch?v=iqddnwKF8HQ&t=2927s
Looks like you might be able to get rid of the error easily with annotations.
"Both parties can have their preference" - this was already true of C where you can just turn enable unused variable warnings or turn them into hard errors, this has nothing to do with the decision.
I also don't want my lsp randomly rewriting my code (???)
_ = variable_to_discard
I am sorta unsure why Zig doesn't have multiline comments, but its also not at version 1 yet, so that will likely come, along with better IDE support.
Multiline comments are less important, but its still convenient for commenting out large chunks of code. IDEs make this a bit easier when you can press e.g. Ctrl+/ to comment out the selected lines with //, but it doesn't work in all cases.
The friction stops zig from being fun imo. A shame because I really like comptime.