You guys can keep complaining about how go is too verbose, but I love everything about go.
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.)
100% with you on every point. It's the only language I've worked in that lets me read other codebases without an hour or two of "wut?" happening, so they did something right!
> I love the error handling
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;
}
with something like (hypothetical) foo := bar() ||| return ERR;
where the compiler, seeing that bar returns an Either<int,err> can enforce the presence of the ||| clause or, alternatively, require later code to check for errors if the ||| clause isn’t present. I think that’s both more robust (prevents one from forgetting to check for errors) and shorter (allowing for showing a lot more code on a screen or page)I do love the batteries included attitude. Having benchmarking included as well as a mechanism to run tests to check (test) for race-conditions right from the language/build tool is amazing.
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.
I love how during prototyping, the compiler will tell me off for having an unused variable and fail to compile. I totally love the idea of crashing when writing on a closed channel.
If generics were going to ruin the language, they would have by now. I think you can rest easy.
It doesn't have a lot of style guides or linting though. You have to install and configure quite a lot of tooling for that
Oh yeah totally agree. I don't understand why someone would want to write `slices.Contains(s, needle)` when you can write this beautiful poem like a Shakespeare in VSCode:
Oh and I totally want to build a stack trace manually. It's like doing cardio to me. This is very elegant by the way, so that we need errors.Is now, which has to dynamically check if the error implements Unwrap() error or Unwrap() []error. Because having any language facilities for error handling is harmful.