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
Step 1: Remove the LSP from IDE.mod
Step 2: Run
go mod tidyI 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
_ = variablePrint-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 runbut 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 runliterally 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 leaveitthose errors enabled for production builds.deleted by creator
Has Google never heard of CI to perform such checks?
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.
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.
just dogsled shit
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?
*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.
“Nah, only when working…”
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
-werrorfor 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
-werrorflag 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.
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 fmtand 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
I’m gonna name some language “``` head -n1 /dev/random | base64 ``” so it’s easy to search
I’m a cruel person - so I’ve been contemplating naming a language
.NETYou wouldn’t dare! Nobody’s that evil…
At least it isn’t confused with a certain Java clone by an evil company or ++ version of itself or not acknowledged at all, because it is just named after a single character, like
Cfor example…a certain Java clone by an evil company
Because Oracle are the good guys now?
Never said that Oracle isn’t evil, just pointed out M$ is extra evil
Java clone by an evil company
… J++? Visual J#?
Dalvik
Ah yes. The good old
go figure --it outI 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
gofumpt’s even beter, also golaegci-lint-langserver
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.You can’t random-access an iterator and use it again later. Can Rust compute the value of calling a function an infinite number of times?
— former rustacean
it can compute how often I needed to compute the value of calling a function an infinite number of times.
println!("0");If you’ve used a parser library’s recursive parser, you have infinite calls right there. If it supplies a recursive-parser function, that function is a type-limited equivalent to
fix, which performs the infinite call operation. Your Rust library most likely implements recursion using hidden mutability, but in Haskell, your parsers can remain infinitely-recursive while still referencing themselves and immutable.Also, we get to ask people if they know what a monad is.
You can’t random-access an iterator and use it again later.
If your specific use case really needs random access to a list while lazy computing the elements just wrap them in
Lazyand put them in a vector.Can Rust compute the value of calling a function an infinite number of times?
The return type of an infinitely recursive function / infinite loops is ⊥, a type that by definition has no values. (Known in rust as
!)Haskell lets you infinitely recurse while still completing in finite time, and there’s even a function (
fix) for that. Doing e.g.fix (+ 2)would be an infinite loop if evaluated, yes, butfix (2 :)would give you a useful value that’s an infinite stream of 2s. (it’s also useful for other things too)
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
Resulttype.MustGetwhere you’d except a panicOrElseto 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.Eithercan for instance be useful to have arbitrary type unions in structs. I haven’t usedOptionthat much but seems similar to Rust’s.
deleted by creator
Panik !!
It’s not easy to discover that you passed an empty memory pointer.
deleted by creator
