This is why many languages have errors and warnings as separate things. Errors for things that for sure prevent the program from working, and warnings for things that are probably wrong but don’t prevent things from working. If you have a setting to then treat warnings as errors (like for CI checks), then you get all the guarantees and none of the frustration.
Comment on Give me Options or give me death
xmunk@sh.itjust.works 8 months agoYes, and it fucking sucks. It’s a great thing to lint for but it makes debugging such a pain - commenting out an irrelevant block to focus your debugging will sometimes break your ability to compile… it’s extremely jarring.
technojamin@lemmy.world 8 months ago
herrvogel@lemmy.world 8 months ago
Have they given an explanation as to why that is? I mean why make it a fatal error that prevents compilation, when you could make it a warning and have the compiler simply skip it?
YIj54yALOJxEsY20eU@lemm.ee 8 months ago
Its an effort to keep large code bases clean. I think they should just differentiate between a debug build and production build. Maybe ensure the debug build can only only run if its in the same directory as the go.mod file.
RustyNova@lemmy.world 8 months ago
I can see the sentiment here… Going through 100 clippy warning on Rust is just not fun… I know there’s the good old clippy --fix but I’m paranoid it breaks my code accidentally.
Could probably have a compromise like 5 unused variables and your code don’t compile
Faresh@lemmy.ml 8 months ago
but I’m paranoid it breaks my code accidentally
Automated tests and version control should prevent that from being a problem, I imagine.
expr@programming.dev 8 months ago
Or, you know, treat it as a warning like literally every other language. There’s absolutely no good reason for it to prevent a build outright, but then again, there’s not really good reasons for many of the decisions behind go.
nutomic@lemmy.ml 8 months ago
Has Google never heard of CI?
firelizzard@programming.dev 8 months ago
I totally agree that it’s really annoying when debugging, but
go run
literally builds then executes. I think what they should do is add a build flag. So debug builds can pass that flag to get the builder to shut up, and leave it enabled for production builds.
frezik@midwest.social 8 months ago
Keep in mind that this is the same language that prefers function names ToBeLikeThis(), and the reason is that it looks different than Java.
fadhl3y@lemmy.world 8 months ago
Every time I think “perhaps I should give Golang another try”, it’s shit like this that keeps me noping out
YIj54yALOJxEsY20eU@lemm.ee 8 months ago
There’s two types of programming languages, the ones people complain about and the ones nobody uses. Go is still my most productive language and is killer for building webservers. I basically use it as a scripting language since it’s so fast to write, compile, and execute.
pkill@programming.dev 8 months ago
just dogsled shit
AlexWIWA@lemmy.ml 8 months ago
Making a variable just to hold a debug value to look at with a breakpoint, but Go says no.
pipe01@programming.dev 8 months ago
You can do
_ = variable
dejected_warp_core@lemmy.world 8 months ago
Print-style debugging has entered the chat.