Re: go Away()
-
Making reply as topic, as I'm going to ask questions / start a discussion, not help @masonwheeler:
@masonwheeler said in go Away():
Ugh. I just discovered that in Go, "variable is declared but never used" is a compile-time error. Not a warning like it should be, like it is in more sane languages; an error. Which makes incremental development that much more difficult; if you want to evaluate something to a variable, look at its value in the debugger, and then write some more based on what you find, you need to find some way to work around that.
If you don't have any use for the variable yet, why have you declared it? I'm kind of confused by the use case you're describing here.
-
@boomzilla Doing some work where I'm not quite sure what to do next. I want to evaluate a value, store it to a variable, and then Do The Right Thing with that variable, but it'll be a lot easier to know what The Right Thing is after I'm able to examine the variable in the debugger and see what it contains.
-
@masonwheeler It sounds like you have no idea what you're going to get. I'm trying to imagine what sort of situation this would be where you have no idea what's going to happen at all. Is this, like, while trying to reverse engineer something? An undocumented API?
-
@boomzilla
Have you never declared several variables that you know you will eventually need up front?
-
@boomzilla I'm working with an API I've never used before, and the documentation is less than ideal. I have a somewhat vague idea that one of three different things will happen, and depending on which one it is I would need to treat it differently.
-
@dragoon said in Re: go Away():
@boomzilla
Have you never declared several variables that you know you will eventually need up front?Typically I declare variables at the point where I need them. But I don't run the code or anything until I have an idea.
Now...the API discovery sort of task that @masonwheeler seems to be doing? I'd probably just log that stuff and then I can look at it that way. Viewing the value in a debugger is more ephemeral than I'd like for this sort of thing.
-
The core point is that errors should be errors and warnings should be warnings - the compiler shouldn't raise an error just because you're Doing it Wrong.
It's indeed most annoying when you're making small temporary changes to test stuff. E.g. I often temporarily delete, replace or add a block of code to debug & understand tricky issues. This makes Jeffier compilers start pouring out errors about unused variables and unreachable code which I then have to waste my time fixing (and later reverting again), even though the compiler could've well compiled the code as-is with just a warning.
-
@createdtodislikethis said in Re: go Away():
It's indeed most annoying when you're making small temporary changes to test stuff. E.g. I often temporarily delete, replace or add a block of code to debug & understand tricky issues. This makes Jeffier compilers start pouring out errors about unused variables and unreachable code which I then have to waste my time fixing (and later reverting again), even though the compiler could've well compiled the code as-is with just a warning.
This, exactly. I often slap a return in the middle of a function I'm debugging, just to skip the rest of the code (e.g. I want to see the full list of results, without the filtering done afterwards, because I suspect that the list itself is wrong -- sometimes I can just comment out the line that does the filtering, sometimes it's easier to insert an early return). I would rather not have the compiler prevent me from doing it.
-
@remi said in Re: go Away():
sometimes it's easier to insert an early return). I would rather not have the compiler prevent me from doing it.
: return false; : OMG! Unreachable statement!! ( :tableflip:) : if(true) return false; : okeydokey :
-
@boomzilla commenting out chunks of code that result in a variable not being used is one case
-
@createdtodislikethis Not that anybody interested in Go would use one, but if you had an IDE it could easily detect "errors" like this and silently modify the code it sends to the compiler to avoid actually causing the developer pain.
-
@blakeyrat said in Re: go Away():
@createdtodislikethis Not that anybody interested in Go would use one, but if you had an IDE it could easily detect "errors" like this and silently modify the code it sends to the compiler to avoid actually causing the developer pain.
That sounds worse. I find those red squiggles annoying when the IDE is compiling code as I'm modifying it but mysteriously sending different code to the compiler sounds like a recipe for confusion and frustration, especially when it goes wrong.
-
@boomzilla Well it hardly matters, so nobody interested in this shitty language is ever going to use an IDE in the first place. But of course my idea is dumb and stupid and idiotic, etc.
-
@blakeyrat said in Re: go Away():
Well it hardly matters, so nobody interested in this shitty language is ever going to use an IDE in the first place.
Do other IDEs actually do stuff like that?
@blakeyrat said in Re: go Away():
But of course my idea is dumb and stupid and idiotic, etc.
Yeah, it sure sounds like it to me, but it's possible that they do this already and I'm unaware of it.
-
@boomzilla said in Re: go Away():
Do other IDEs actually do stuff like that?
I assume most don't have to because they're written for languages that aren't as shitty. Whether any do, I can't say. I was just proposing an idea.
-
@blakeyrat said in Re: go Away():
I assume most don't have to because they're written for languages that aren't as shitty.
This isn't any different than treating warnings as errors except that you can't turn it off. IDEs definitely support that.
-
@boomzilla "this variable is unused" should only be a warning in languages where you can declare variables by typing their name with no keyword. That's the only time it's probably going to point to a genuine typo-bug and not just annoy the hell out of the user. (Otherwise, it's covered by: "you're using this variable before declaring it" and "you've already declared a variable with this name".)
EDIT: I mean it's great that Go tries to pre-emptively resolve errors like this, at least the intention is good. But the real problem with bugs in software development is software developers who use shitty tools that don't assist them in identifying bugs. And Go ain't doing shit to solve that.
-
@createdtodislikethis said in Re: go Away():
The core point is that errors should be errors and warnings should be warnings - the compiler shouldn't raise an errors just because you're Doing it Wrong.
This. As someone actually writing a compiler, I completely agree with what you're saying.
-
@blakeyrat said in Re: go Away():
@createdtodislikethis Not that anybody interested in Go would use one, but if you had an IDE it could easily detect "errors" like this and silently modify the code it sends to the compiler to avoid actually causing the developer pain.
This is how some golang nuts added bootleg generics to the language. There's a couple of aboriginal characters that look like <>, so someone wrote a script that searches for those characters and generates code for each type referenced in the brackets. And then they proudly shared it with the golang subreddit.
Of course, the beauty of go is that it's just so simple and practical
-
@dkf said in Re: go Away():
@createdtodislikethis said in Re: go Away():
The core point is that errors should be errors and warnings should be warnings - the compiler shouldn't raise an errors just because you're Doing it Wrong.
This. As someone actually writing a compiler, I completely agree with what you're saying.
See: Rust.
-
@blakeyrat said in Re: go Away():
Not that anybody interested in Go would use one, but if you had an IDE
Umm... I'm writing this in VSCode. (Although I suppose if we want to get ic about it, I'm not particularly interested in the language. Just using it because that's what we use at work.)
-
@masonwheeler said in Re: go Away():
Umm...
Umm..............................
Not sure what point (if any) you're trying to make here.
-
@boomzilla said in Re: go Away():
I find those red squiggles annoying when the IDE is compiling code as I'm modifying it
I actually like how VSCode handles it: it doesn't produce red squiggles by compiling while I'm writing; it does that when I hit Save, at which point it knows that the code is in a (relatively) stable state.
-
@dkf said in Re: go Away():
This. As someone actually writing a compiler, I completely agree with what you're saying.
As a compiler maintainer, again I agree with this point.
-
@blakeyrat That I work with Go and I do, in fact, use an IDE. So does everyone here who works in Go.
-
@masonwheeler VS Code isn't an IDE.
-
@blakeyrat Is this one of those True Scotsman things? Because it sure feels like an IDE to me. I can write code, get syntax highlighting, get Intellisense, compile, and invoke a visual, step-through debugger with breakpoints and inspectors for the callstack and locals... what is it missing to be a "proper" IDE?
-
@masonwheeler I dunno, maybe it's an IDE? Whatever.
-
@pie_flavor said in Re: go Away():
See: Rust.
I don't want to. Did you have something more informative to say that didn't involve a random reference to a language where the rest of us don't know what its compiler likes to gripe about?
-
@blakeyrat said in Re: go Away():
maybe it's an IDE? Whatever.
well duh, vs code is an IDE, so I'm not sure what point you're trying to make here
-
@dkf said in Re: go Away():
rest of us don't know what its compiler likes to gripe about?
it's very pedantic about memory safety and leaks
-
@dkf Things you can't do: using static mutables from safe code, keeping pointers around longer than what they point to, having more than one mutable pointer to a value, having mixed mutable and immutable pointers to the same value, having non-Copy types such as Vec be copied simply by reassigning to another variable, passing non-Send types between threads, accessing non-Sync types from multiple threads, etc. All this is compiler-checked.
-
@dragoon said in Re: go Away():
@boomzilla
Have you never declared several variables that you know you will eventually need up front?Only if I already had their resulting code that would assign to them, so.... not really?
Unless sketching could be considered declaring...
-
@createdtodislikethis said in Re: go Away():
the compiler shouldn't raise an error just because you're Doing it Wrong.
Wat.
Edit: I assume I'm just not parsing the spiritual meaning of this statement...
-
@createdtodislikethis said in Re: go Away():
unreachable code
Yeah, that really should be an Info. There are way too few of those...
-
@tsaukpaetra said in Re: go Away():
I assume I'm just not parsing the spiritual meaning of this statement...
There's a key difference between “doing it wrong” and “Doing It Wrong”. The former is fine for things that cannot possibly work such as syntax errors, and the compiler is within its rights to throw errors there. We're grumbling about the latter, where minor infelicities such as an unused variable are causing errors and not warnings. It's the attitude at its worst.
-
@dkf said in Re: go Away():
@tsaukpaetra said in Re: go Away():
I assume I'm just not parsing the spiritual meaning of this statement...
There's a key difference between “doing it wrong” and “Doing It Wrong”. The former is fine for things that cannot possibly work such as syntax errors, and the compiler is within its rights to throw errors there. We're grumbling about the latter, where minor infelicities such as an unused variable are causing errors and not warnings. It's the attitude at its worst.
I'm actually a fan of how IntelliJ and VS (although that might just be ReSharper, not sure) handle this kind of stuff - with that little warning bar on the side. It kinda gamifies coding - I'll get an urge to go through my projects and remove all the warnings one by one until the bar is green again. And if, for some reason, I can't remove the warning, I'll disable the warning with a comment on why I disabled it for that specific line.
Of course, in an actual work environment, I don't know how well that would work. You might build up technical debt faster than you can burn it...
-
@bb36e said in Re: go Away():
well duh, vs code is an IDE, so I'm not sure what point you're trying to make here
An incoherent, idiotic, peurile self-aggrandising mildly-retarded point. The real question is, what did you expect?
-
@dkf said in Re: go Away():
@pie_flavor said in Re: go Away():
See: Rust.
I don't want to. Did you have something more informative to say that didn't involve a random reference to a language where the rest of us don't know what its compiler likes to gripe about?
Have an example:
// /tmp/quicky/src/lib.rs pub fn one() -> () { let a = 1; // warning let _b = 2; } #[allow(unused_variables)] pub fn two() -> () { let c = 2; let d = 2; #[warn(unused_variables)] let e = 2; // warning let f = 2; // no warning } pub fn three() -> () { let g = 2; // warning #[allow(unused_variables)] let h = 2; }
-
@sloosecannon said in Re: go Away():
Of course, in an actual work environment, I don't know how well that would work. You might build up technical debt faster than you can burn it...
For preference, I'd go with having warnings allowed on developer branches and forbidden on main/release branches. I don't mind seeing that things were a bit broken when a developer (including me!) is in the middle of working on something, but when they're on the main branch (
master
,trunk
,davetheboss
, whatever you want to call it) those warnings should be crushed out if possible as they do indicate a potential problem.Unfortunately, some operating systems make completely warning-free builds really difficult to achieve. (I'm looking at you, OSX, with your wonderful habit of deprecating APIs without providing a sufficiently equivalent replacement… )
-
@dkf said in Re: go Away():
@sloosecannon said in Re: go Away():
Of course, in an actual work environment, I don't know how well that would work. You might build up technical debt faster than you can burn it...
For preference, I'd go with having warnings allowed on developer branches and forbidden on main/release branches. I don't mind seeing that things were a bit broken when a developer (including me!) is in the middle of working on something, but when they're on the main branch (
master
,trunk
,davetheboss
, whatever you want to call it) those warnings should be crushed out if possible as they do indicate a potential problem.Unfortunately, some operating systems make completely warning-free builds really difficult to achieve. (I'm looking at you, OSX, with your wonderful habit of deprecating APIs without providing a sufficiently equivalent replacement… )
Theoretically, couldn't you suppress the warnings the same way you would in the IDE?
Of course, that would require someone to make sure you aren't suppressing stuff when you have a perfectly cromulent fix, but that's what code reviews are for...
-
@sloosecannon said in Re: go Away():
Theoretically, couldn't you suppress the warnings the same way you would in the IDE?
The problem is that suppressing can hide other sins too. It's possible to scope things… but it's all very very messy. (It's actually often worse with IDEs.) A good rule of thumb is that suppressions are always a malodorous code smell.
-
@dkf said in Re: go Away():
@sloosecannon said in Re: go Away():
Theoretically, couldn't you suppress the warnings the same way you would in the IDE?
The problem is that suppressing can hide other sins too. It's possible to scope things… but it's all very very messy. (It's actually often worse with IDEs.) A good rule of thumb is that suppressions are always a malodorous code smell.
Well what I'm talking about is something like
//This is a library function, it's not used in the project but must be public //jbsupresswarning:Unused public static String getValue() { }
for specific cases where the warning is wrong. Obviously suppressing all warnings is a bad idea, and even doing that by file is probably not a great idea...
-
@sloosecannon said in Re: go Away():
//This is a library function, it's not used in the project but must be public
Such things should be referenced from tests.
-
@greybeard said in Re: go Away():
@sloosecannon said in Re: go Away():
//This is a library function, it's not used in the project but must be public
Such things should be referenced from tests.
Also, if a public exported function is documented as "this is a public exported function" and your static analysis tools say "OH NO THIS API IS NOT REFERENCED BY THE LIBRARY THAT PROVIDES IT" you need to fire all your employees.
-
@ben_lubar said in Re: go Away():
@greybeard said in Re: go Away():
@sloosecannon said in Re: go Away():
//This is a library function, it's not used in the project but must be public
Such things should be referenced from tests.
Also, if a public exported function is documented as "this is a public exported function" and your static analysis tools say "OH NO THIS API IS NOT REFERENCED BY THE LIBRARY THAT PROVIDES IT" you need to fire all your employees.
I know that sounds like a non-sequitur, but here's a picture of an angry cactus monster:
-
@ben_lubar said in Re: go Away():
Also, if a public exported function is documented as "this is a public exported function" and your static analysis tools say "OH NO THIS API IS NOT REFERENCED BY THE LIBRARY THAT PROVIDES IT" you need to fire all your employees.
Sorry, not following you here. Why, aside from the lack of tests, is this bad?
-
@greybeard said in Re: go Away():
@ben_lubar said in Re: go Away():
Also, if a public exported function is documented as "this is a public exported function" and your static analysis tools say "OH NO THIS API IS NOT REFERENCED BY THE LIBRARY THAT PROVIDES IT" you need to fire all your employees.
Sorry, not following you here. Why, aside from the lack of tests, is this bad?
If you have a function named
getValue
that returns a string and is documented to be "a function" and your static analysis tool says that functions exported by the library are unused and should be deleted, pretty much every single thing I just said is a bad thing you should fix.hashtag WeightedBottom
-
@bb36e said in Re: go Away():
well duh, vs code is an IDE, so I'm not sure what point you're trying to make here
Looks like he's once again making bold assertions about things he doesn't understand. And then when someone who's actually familiar with it points out that no, it doesn't actually work that way, he's all "oh, OK, whatever."
Seems to me it would save a lot of grief and embarrassment to ask questions about things you don't understand instead of making statements you don't actually know to be true and then being shown to be wrong...
-
@masonwheeler I use VS Code every fucking day for TypeScript. It doesn't have anything I'd call an IDE feature.
Ben informs me that if you install the Go plugin it does have a bunch of IDE stuff, so there you go.