Go is a little more verbose in basically two ways: it forces you to handle error states explicitly, and it doesn't let you do overly-clever things to save a few lines of typing. Neither of which increase the maintenance or testing burden.
Does it?
`if err != nil` is a convention. It's not a checked error. It's like saying "C has explicit array bounds checking", if the convention was to check it by hand.
For all the hate Java gets, when I have a checked exception, I know what it is going to be. I don't need to dig around in sourcecode trying to work out if I should care or not. I don't need to check which of the three Golang error-distinction idioms (package-variable errors, error subtypes, plain-old-errors-with-magical-strings) is in play.
As you can guess, I don't like Go.
It's... obviously both.
The advantage of runtime exceptions over Go is that I will get a fatal crash and a stacktrace. I don't have computation proceeding in an undefined, difficult-to-debug way because I forgot to do `err != nil` somewhere (particularly for functions that only return err).
Don't get me wrong, though. I become grumpy when I see empty catch clauses. Or a logger figleaf.
So that's what we're calling the lack of HoFs these days? It's really sad to hear that anyone considers map/fold/filter are "overly-clever".
Tim Sweeney (Epic) says[1]:
"“For” loops in Unreal:
40% are functional comprehensions
50% are functional folds"
I hardly see how changing those loops into a construct that more accurately represents them is overly-clever.
Go has HoFs. The lack of parametric polymorphism is what prevents you from writing `map` in Go (subject to several caveats surrounding efficiency and type safety).
No, it doesn't (simple example: the return value of os.Setenv). errcheck exists for a reason.