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.
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.
This is the same argument C (and Zig!) people have for manual memory management. You can avoid memory problems by being a good developer.
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.
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;
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.