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
527 points (96.8% liked)
Programmer Humor
19623 readers
2833 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 1 year 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
Yes, 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.
Making a variable just to hold a debug value to look at with a breakpoint, but Go says no.
You can do _ = variable
Print-style debugging/logging has entered the chat.
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.
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?
Its an effort to keep large code bases clean. I think they should allow them when running go run but not when building.
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
but I’m paranoid it breaks my code accidentally
Automated tests and version control should prevent that from being a problem, I imagine.
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~~ those errors enabled for production builds.
load more comments
(1 replies)
Has Google never heard of CI to perform such checks?
load more comments
(1 replies)
Keep in mind that this is the same language that prefers function names ToBeLikeThis(), and the reason is that it looks different than Java.
Every time I think "perhaps I should give Golang another try", it's shit like this that keeps me noping out
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.
load more comments
(1 replies)
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).
load more comments
(4 replies)
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.
load more comments
(7 replies)
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.
You'll go fmt and you'll like it. Go has the single easiest to Google name of any programming language. Thou shalt not question golang decisions.
Go has the single easiest to Google name of any programming language.
Ackchually
C is also bad - but I do think .Net takes the cake. I'm willing to give C a pass though since it existed before we had search engines... Go was specifically developed at Google so there's no excuse.
it's like half the number of keystrokes
Ah yes. The good old go figure --it out
I ran across an old Stackoverflow question from many years ago where someone asked a question about types and wondered if generics could solve it. There was a very high-minded, lengthy reply that Go does not have generics, because that makes the language small and clean.
Since then, Go has implemented generics. Because who the hell wants a strongly typed language without generics on this side of 2010?
I honestly only think generics made it into Go because the designers started getting embarrassed by the solution to nearly every problem being "create an empty interface".
on this side of 2010?
On this side of 1990. I'm not saying C++ did this right, but it embraced the idea that maybe the compiler could do a little more for us. And every time someone fielded a new language with some traction, eventually they added generics or just used duck-typing from the start.
I thought everyone else just did what I do -- if there's a squiggle, take away the squiggle part. If something's missing, make a blank line and then blindly bounce on the tab key until Copilot fixes it.
That's step 1, and if that doesn't work, step 2 is to actually look at what's going on and try to fix it.
You bring back my bad memories of having to implement a server program in rust and all my searches ended up with about 1/3 useful results and the rest being hosting options for rust gameservers
load more comments
(1 replies)
Imagine getting segmentation faults at runtime
This post was brought to you by the Rust crew
Neither does Haskell, and Haskell won't waste time doing something that doesn't matter.
Imagine using a linked list as your default sequential container.
Rust iterators are lazy btw.
load more comments
(5 replies)
As a use-rust-for-even-the-most-basic-task elitist, I laugh.
panic();
Panik !!
It's not easy to discover that you passed an empty memory pointer.
view more: next ›