I couldn't care less about crashes, that's an end-user problem. But do you expect me to go to sleep while that squiggly line in my IDE??
/s just in case
this post was submitted on 14 Feb 2024
488 points (96.9% liked)
Programmer Humor
25460 readers
1050 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 2 years ago
MODERATORS
Step 1: Remove the LSP from IDE.mod
Step 2: Run go mod tidy
I mean it isn't even just a squiggly line, the code fails to compile. Like come on, I will clean up my unused imports and variables before sending it for review, but just let me develop in peace.
Whenever the compiler refuses to compile because of an unused var:
Hey Jeff, we know the variable is unused. WE CAN SEE THE SQUIGGLE
Not a go dev. Is it really preventing compilation or is it just some hardened linting rules? Most languages can prevent compile on those errors if tweaked, but that seems bad if it's not a warning
Unused variable is an error which fails to compile.
Whoah, that seems like you'd flesh out code elsewhere, you know when you throw stuff together to make it work, and then fix it up to standards.
Feels like you should have to make git commits perfectly well before being able to compile...
Put that overwhelmingly intrusive thing in a hook checking out your commits instead (when you push your branch ofc).
You get used to it. The only time I really notice it these days is when I’m debugging and commenting out code.
So... A lot of the time?
"Nah, only when working..."
*when I'm doing debugging that requires commenting out code.
Most of the time, I don't comment out code. I run the code in a debugger, step through it, and see how the behavior deviates from what I expect. I mostly only resort to commenting out code if I'm having trouble figuring out where the problem is coming from, which isn't that often.
What reason is there for this when the compiler could just optimize that variable out of existence? This feels like the most hand holdy annoying "feature" unless I'm missing something.
Cleaner code. That's all.
If you need to take variable you don't use for some reason (like it's a function arg that has to follow an interface, but it doesn't need a specific parameter in this case), then you can prefix it with an underscore.
That's what warnings are for and -werror for production builds in literally any other language. This has been a solved problem for a very long time.
Sure. Tell that to the Go devs.
If the language weren't pushed by Google, nobody would pay it any attention. It's yet another attempt to "do C right" and it makes some odd choices in the attempt.
I for my part prefer it that way. Makes sure the code stays clean and nobody can just silence the warnings and be done with it. Because why would you accept useless variables that clutter the code in production builds? Imagine coming back after some time and try to understand the code again. At least you have the guarantee the variable is used somehow and not just "hmm, what does this do? ..... ah, it's unused"
...you don't accept them. Basically every programming language accepts some kind of -werror flag to turn warnings into errors. Warnings for development builds, errors for production builds. This has been a solved problem for a very long time. Not only is it assinine to force them to be errors always, it's semantically incorrect. Errors should be things that prevent the code from functioning in some capacity.
Oh, that makes warnings errors and does not mean "ignore errors". I'm not too familiar with compiler flags. You could do some mental gymnastics to argue that the unused variable causes the compiler to exit and thus the code is not functioning and thus the unused variable is not a warning but an error :^)
It's a pretty standard flag in basically all compiled languages, just goes by a different name. -werror in C, -Werror in Java, TreatWarningsAsErrors in C#, etc.
I don't think its inherently bad but it feels jarring when the language allows you reference nill pointers. It's so effective in its hand holding otherwise that blowing things up should not be so easy.
Yes but I've never found it to be that annoying.
As a use-rust-for-even-the-most-basic-task elitist, I laugh.
You laugh in 16 GB to compile rust-to-bytecode compiler
Me (Chad): having to get 32GB+ of RAM to compile my memory-safe point-and-click adventure
You(virgin): being able to compile your segmentation faults with 4GB RAM
Giga Chad: having to get 32GB+ of RAM to compile rust-safe memory-leaks
Tera Chad: having to get 32GB+ of RAM to compile bus faults
panic();
Here you are https://pkg.go.dev/github.com/samber/mo
Thank you very much, I'm definitely going to take this for a spin! Can I ask if you or someone you know uses this? I'm curious what the experience is like and if theres any downfalls.
A simple example:
func GetConfig(path string) mo.Result[*Config] {
return mo.Try(func (*Config, error) {
// logic to get the config
})
}
conf := GetConfig.OrElse(&DefaultConfig)
While it might not make much sense for a function you use just once, it can get actually pretty useful to simplify error handling like this for something you use more often.
mostly the Result type. MustGet where you'd except a panic OrElse to pass a fallback value (can be a function with return value of the same type, as the inner function, but without an error). Useful in e.g. more complex constructors where some fields might not be readily available. Either can for instance be useful to have arbitrary type unions in structs. I haven't used Option that much but seems similar to Rust's.
Panik !!
It's not easy to discover that you passed an empty memory pointer.