It's not needed if it's just on its own, but Go's error handling makes it necessary when chaining functions, which is why you see it so often.
Imagine in Java or Python or C# or ... many languages that use exceptions to handle errors:
return a(b(c(arg)));
...where a(), b(), and c() can throw some kind of exception, so you don't have to handle them then and there. In Go there aren't exceptions, all error handling is explicit and handled conventionally by returning an error as the last (sometimes only) return value, which isn't composable, so you get:
cVal, err := c(arg)
if err != nil {
return nil, err
}
bVal, err := b(cVal)
if err != nil {
return nil, err
}
return a(bVal) // the final call can be simpler
That's the minimum verbosity required. Since Go 1.13 (2019), they officially added the concept of "wrapped" errors (aka "cause" in languages with exceptions) so instead of returning err you can return errors.Wrap("error in the a-b-c function calling c", err). But nonetheless, _every_ level of the call chain has to wrap or pass on all errors with explicit code. Go does have panic() and recover() which allow for exception-like error handling but it's not idiomatic to use them for normal error handling, go wants that to be explicit.
As for why "return nil, err" rather than "return ret, err"? Because while the caller _should_ check for errors, sometimes they just don't.
ret, _ := abc(arg) // just ignore the error
ret.DoSomethingFun()
You as callee don't want to get the blame if you've _partially_ filled an struct because you returned early with an error, and it's then usable but causes a crash because it was partially initalised, because someone ignored the error they got when creating it. That hides where the problem really was. Better to return an empty value, default value or nil.