found := false
for _, v := range s {
if v == needle {
found = true
break
}
}
if err != nil {
return fmt.Errorf("my function name but in spaces: %w", err);
}
No, making error handling verbose mandatory is meant to make developers do mental cardio and be mindful of what they are doing.
You can either keep developers mindful or punish them after they make a mistake by shouting at them and make them waste their time during re-compiling.
P.S.: Yes, I love Go's error handling mechanics, which makes handling errors mandatory, not optional, and if you ignore the error, this is a deliberate choice and the burden is on the developer. Go does the former, Rust does the latter.
Rust bakes this into the type system, a function can truly return a result or an error.
The problem is painstakingly and manually having to build the stack trace, and then unwrapping it few layers above if you ever need to check what error it was.
I have written a fresh example at https://files.bayindirh.io/misc/error_example.go. Give it a Go. ;)
OTOH, gopls is a great LSP, though, and it warns you about this immediately.
Considering some expensive Go calls do the same caching underneath, this is the preferred design pattern, I assume.
So, you handle the error in the end, or forcefully and intentionally ignore it. Again, if the code goes boom, it's on the developer, not on Go.
> Rust bakes this into the type system, a function can truly return a result or an error.
Error being a variable or baked into the type system doesn't change the practical result. You must handle the error or purposefully ignore it.
> only Rust actually forces you to handle errors.
When you have two programming languages which makes you handle the error, the word only becomes a little invalid.
Semantics doesn't change the result. You have to acknowledge and act on the error either way.
Except Go doesn’t actually require you to handle the error. You can forget to handle the error, or forget to do a nil check. And Go won’t tell you until it crashes and explodes at runtime.
Technically the user’s fault, but good systems protect the users from their own mistakes.
But as someone else pointed out, unhandled errors are very rare in practice in Go because every Go project tends to use static code analysis tools that catches this. When people talking about things blowing up during runtime I can’t help but think that they can’t be serious Go users.
On every build I generally run vet, lint (revive), staticcheck, gosec and test. And that’s the “light” build that doesn’t run leak analysis, fuzzing, race testing, benchmark regression and integration tests in addition. The light build is still faster than the Rust compiler. I haven’t compared the heavier build.
When people pretend the absence of features is a huge problem, I tend to think that these are people who either aren’t regular Go users or perhaps they are more interested in debating languages than writing code.
Let’s not pretend this is something it isn’t.
The fact that external tools exist that "every Go project tends to use" to fill common a gap in the type system indicates to me that maybe the language itself could be improved.
I have commented inside the code, but to recap here:
- If you don't declare err variable, the code won't compile.
- If you don't use err variable, the code won't compile again.
The only way to "forget" is to declare err as "_", which I call IDGAF placeholder, and this is a deliberate choice to ignore that variable. So you willingly and knowingly ignore the error variable.
Otherwise Go won't give you Go ahead.
Seriously, try to compile the example I have given. It's fresh, so hold with mittens.
``` a, err := f() b, err := g() if err != nil {} c:=a+b ```
The language will happily build and run, even though it should prevent to let you shoot in the foot.
In a little blunt form: This machine has no brain, use yours.
Go errors if you try to assign a number to a string, so it's clear there is some intention for the machine to catch when your brain makes a silly mistake.
I can also think a couple of cases where I deliberately catch the error, but don't do anything on it explicitly, esp. if I'm talking with a buggy hardware. I'd still log the errors as INFOs or WARNs though. I have seen too many "task failed successfully" errors in my life.
Especially as someone who's read a lot of code written by newcomers to Rust.
``` package main
import ( "errors" "fmt" )
func getMessage() (string, error) { return "DO NOT INSPECT", errors.New("something went wrong") }
func main() { msg, _ := getMessage() // Ignore the error. fmt.Println(msg) } ```
Compiles normally and prints "DO NOT INSPECT"
Don't make me spit my tea. That monitor is expensive. Of course, yes: https://git.sr.ht/~bayindirh/nudge
Jokes aside...
You used "_" to ignore the error variable, which I call "IDGAF" placeholder.
So, you willingly ignored the error and tell me that you don't have to check the error? You told the compiler that you don't care about the error explicitly (via "_"). That's on you then.
In my first comment I noted in the P.S. section:
...if you ignore the error, this is a deliberate choice and the burden is on the developer.
I mean, do you even read the language documents to understand how a language works?
package main
import ( "errors" "fmt" )
func getMessage() (string, error) { return "DO NOT INSPECT", errors.New("something went wrong") }
func main() { msg, err := getMessage() fmt.Println(msg) fmt.Println(err) }
This is the same argument C (and Zig!) people have for manual memory management. You can avoid memory problems by being a good developer.
On the other hand, Go explicitly warns and tries to prevent you from ignoring or not handling possible errors. This is a bit different than a happy C compiler which doesn't warn you about leaking memory.
I am skeptical about Go's error handling, but there are cases where it is desirable to return both a result and also an error, like returning what can be returned while warning users about any errors. That can be modeled in Rust and other languages as well, though it is the default for Go.
2.That error handling is one of the best features. It makes me explicitly acknowledge the errors instead of letting them just happen. No error goes unnoticed!
Each if err != nil is an explicit reminder to check, do I need to clean up? Do I need to log this error to a file?
"And no more oh an error happened I wonder where"
With LLMs verbosity is not an excuse anymore. Just generate it and focus on other things then
That’s a total statement, not leaving any room for criticism.
Also, if error wrapping hurts you so much (I don't use it), just implement a project-specific error that works how you want. This could be something that is JSON serializable, that captures a line number at each return site, etc. It will take like 10 minutes to get your project's errors working exactly how you want.
My projects usually do -
log.SetFlags(log.LstdFlags | log.Lshortfile)
// ...
if err != nil {
log.Println(err)
return errors.New("Error doing the thing.")
}
I think that one is true. Like, if you're building something that is able to be successful despite having a poor type system, frequent panics, and difficult to correctly use concurrency primitives, Go is a great language for letting the lowest common denominator programmer be productive.
If you're building more serious software, then it can be a very bad tradeoff that destroys your company or product, but you know, that's true of a bunch of languages.
Rust async has a bad reputation in Rust circles, due to difficulties like deadlocks and poisoning (also regarding the messy panic system Rust has).
> Rite of passage for a Rust developer is creating a deadlock through an if-statement.
found := false
for _, v := range s {
if v == needle {
found = true
break
}
}
If you'd used `slices.Contains(s, needle)`, on the other hand, it could have such a performance bug in it and you'd never know.
Perhaps you're much better at programming than I am, but I prefer these semantics in a language because I figure they're much more likely to have been optimized empirically, support vectorization, and be less buggy than another rote loop I'm trying to speed through.
Even when Russ Cox and Go team had come to term with reality and stopped pretending like we are in 70s still, these lot will move goalposts. It is a kind of psychosis and sycophancy that is beyond rational discourse.
https://cs.opensource.google/go/go/+/refs/tags/go1.26.5:src/...
wut...? the debate isn't between closed (incompetent) source and open (competent) source - the debate is between verbose language and expressive language.
Even if you prefer manually checking for errors after every call that might fail, I fail to see how one can love go’s verbosity. Compare go’s
foo, err := bar()
if err != nil {
return ERR;
}
foo := bar() ||| return ERR;
While the first occupies more lines I suspect I’d spend less time spotting it in the code. The physical shape of the expression is something my brain is used to seeing after 40 years of programming. Even when code grows more complex.
The second is OK when it stands alone, but I am not so certain it would be as easy to spot in more complex surroundings. Even on a single line, there is something a bit ugly about the code. Even before we get to the desperate triple-pipe. That kind of reminds me of the desperate attempts at repairing JS after they realized its equality semantics were shot. Just heap more characters on it.
The thing is: it is actually very hard to judge how ergonomic a language is by just looking at it. You have to use it and you have to use it enough to realize where the paint points really are. I’ve read through a lot of the responses in this discussion and I’ll be honest: I think a lot of people who criticize other languages (be they Rust, C, Go or whatever) aren’t very fluent in them. It takes a couple of years to develop fluency.
foo := thinger()
_ = foo # no longer unused
Which is a great way to make sure they're not overused, which in my experience is better than underuse.
My only wish is that go could become less verbose. There are several frontends to go that are more compact, compile down into golang, and then let you enjoy all the benefits.
[0]: https://github.com/authzed/spicedb/tree/main/tools/analyzers
You can see it's used by _a lot_ of linters already:
https://pkg.go.dev/golang.org/x/tools/go/analysis?tab=import...
The early loop looked like this:
/goal improve the perf by 20%
-> a great deal of plausible code
-> a confusing benchmark
-> another plausible patch
find the expensive work
-> explain why it happens
-> change one mechanism
-> compare with the previous Rust revision
-> test the complete application
-> retain, revise, or rejectAn example from one of my recent projects: https://github.com/verdverm/gmd/blob/main/Makefile (give agents simple "tool calls" instead of needing to divine the correct args/flags every time, essentially invocable agents.md content)
One of the interesting things to call out from this is using build tags for testing { unit, coverage, recorded, real api }, with the buffet allowing the agent to iterate faster and more targeted. I tend to run the linting and coverage in a new session, have a report generated, and then another fresh session to start dealing with gaps.
Another super cool testing tool in the Go internal source is `testscript`. Roger Peppe extracted a number of those internal utilities here https://github.com/rogpeppe/go-internal/tree/master/testscri...
I love the error handling, I love the forced formatting, i love all the linting it has including style guides. When you read other source code it's so easy to understand it and make sense of it. Thank you go team
(Ok, maybe I am a bit sceptical with the latest generic additions, but overall it's a great language. I love it.)