When unused packages or variables are present in Go code, the compiler gives error.
Suggestion: make it possible to delete unused variables with the compiler or maybe the gofmt tool
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
When unused packages or variables are present in Go code, the compiler gives error.
Suggestion: make it possible to delete unused variables with the compiler or maybe the gofmt tool.
The thing is, one very often comment out sections of code temporarily, but then the compiler complains and one has to comment out even more.Perhaps the feature I'm really looking for is a way to run the code regardless of unused variables, using some flag.
--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/BWDmZFX9hRI/unsubscribe?hl=en-US.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
More useful, I think, would be an IDE feature that could automatically mark unused variables and imports as one writes code. Add a command to comment or delete this variables or imports or just do it manually.
-Daniel
--
On Friday, May 3, 2013 4:35:19 PM UTC+3, Ostsol wrote:More useful, I think, would be an IDE feature that could automatically mark unused variables and imports as one writes code. Add a command to comment or delete this variables or imports or just do it manually.
-Daniel
Don't you think it would be best if neither the compiler nor a random IDE would have the control, but instead I would be in control of that?
Go, as a language, is just another tool in the shed, another hammer. However hard it may try, it will never ever be a substitute for real logic and understanding when it comes to opting.
My opinion that Go should in fact have lots and lots of warnings: about shadowing, about channels, about interfaces, about structs. A lot of issues are left unnoticed while this uninteresting and dumb one is kept on only as a statement, not as a real proven benefit.
On Friday, May 3, 2013 4:35:19 PM UTC+3, Ostsol wrote:
More useful, I think, would be an IDE feature that could automatically mark unused variables and imports as one writes code. Add a command to comment or delete this variables or imports or just do it manually.
-Daniel
Don't you think it would be best if neither the compiler nor a random IDE would have the control, but instead I would be in control of that?
Go, as a language, is just another tool in the shed, another hammer. However hard it may try, it will never ever be a substitute for real logic and understanding when it comes to opting.
My opinion that Go should in fact have lots and lots of warnings: about shadowing, about channels, about interfaces, about structs. A lot of issues are left unnoticed while this uninteresting and dumb one is kept on only as a statement, not as a real proven benefit.
On Friday, May 3, 2013 5:16:37 PM UTC+3, Andrew Gerrand wrote:Don't you think it would be best if neither the compiler nor a random IDE would have the control, but instead I would be in control of that?No.
Enlightenment comes in many shapes or forms. "No" is not it.
My opinion that Go should in fact have lots and lots of warnings: about shadowing, about channels, about interfaces, about structs. A lot of issues are left unnoticed while this uninteresting and dumb one is kept on only as a statement, not as a real proven benefit.
Your opinion is at odds with the language design goals.
I think I've addressed this one: mold the goals once the language gets in the hands of users. It appears that field testing, sort of speak, goes against the initial concepts baked in a laboratory. If you want Go up then you need to GrOw up.
Every single time it comes to this: "we know better, here's the door".
Unpleasant, to say the least. And very immature.
Let me ask you this: you think that every honest request is out to get Go and ruin it?
On Friday, May 3, 2013 5:16:37 PM UTC+3, Andrew Gerrand wrote:
Don't you think it would be best if neither the compiler nor a random IDE would have the control, but instead I would be in control of that?No.
Enlightenment comes in many shapes or forms. "No" is not it.
Go, as a language, is just another tool in the shed, another hammer. However hard it may try, it will never ever be a substitute for real logic and understanding when it comes to opting.
I don't think Go tries to be a substitute for real logic and understanding.
Yes it does, when it decided to stop my code it doesn't really understand, based on random and bias observations of it.
My opinion that Go should in fact have lots and lots of warnings: about shadowing, about channels, about interfaces, about structs. A lot of issues are left unnoticed while this uninteresting and dumb one is kept on only as a statement, not as a real proven benefit.
Your opinion is at odds with the language design goals.
I think I've addressed this one: mold the goals once the language gets in the hands of users. It appears that field testing, sort of speak, goes against the initial concepts baked in a laboratory. If you want Go up then you need to GrOw up.
If you want suggestions about potential errors in your code, use go vet.Andrew
As the original poster of this possible solution, you don't have to mention this option to me.
--
Mitică
Hold on guys. Let me grab a chair
That is real stupid argumentation against a very simple and clear request.
You really need a shift in mentality, before anything.
I'm sure it will happen eventually, it's just mind boggling how egotistical the language issues have become in the eyes of the language designers at the expanse of the general audience.
--
There is also a certain irony that follows due to this, "we created a language that C++ people should like, but they don't like it! But they must, we did all the "right" things! "
I agree there are certainly people in this group who could be nicer, but I would describe them as pedantic rather than condescending. Indeed, if you look through the archives of this group you can find hundreds of threads where someone has asked for help and received dozens of helpful, factual responses. Numerous times I have seen people outside this group comment on how helpful the people here are.
However, if you come to the group to declare you know a better way of doing things, especially if you do not even write real Go code, then you should expect a chilly response. If you are not at all invested in the project, yet expect your opinions of language design to be respected like those who have invested years working on Go, then you're going to have a bad time.
It should also be said that it is much easier to quibble over minor aspects of language design than to do the hard work that actually improves the Go ecosystem. I am personally chagrined to have spent so much of today contributing to this thread, when I should have been writing code.
Rust is in a different stage to Go: they're still working on the core language, and aren't that close to 1.0. It is natural that they should be more receptive to language design suggestions. I don't know much about the Scala community, but their design philosophy is certainly more inclusive than that of Go.
As has been said elsewhere, Go is an opinionated language. To stay that way it needs to have opinionated maintainers. I personally view that as a virtue, but some people have different ideas and have their feelings hurt when Go's ethos disagrees with them.
There is very little I can do but reiterate our goals, and encourage those with different goals to find another community of people that share their ideas.
Andrew
--
There is also a certain irony that follows due to this, "we created a language that C++ people should like, but they don't like it! But they must, we did all the "right" things! " The language does seem to be attracting a lot of Python/Ruby/etc programmers though, which in retrospect is not really surprising. It seems that Go is becoming another web dev language.
Why don't just add a flag that makes compiler ignore unused packages and variables error? That can be useful for testing incomplete code.
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.