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.)
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.
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;
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.
Which is a great way to make sure they're not overused, which in my experience is better than underuse.
You can see it's used by _a lot_ of linters already:
https://pkg.go.dev/golang.org/x/tools/go/analysis?tab=import...
[0]: https://github.com/authzed/spicedb/tree/main/tools/analyzers
An 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...