If you browse random Go code from https://pkg.go.dev/ you will have a hard time finding that hypothetical case where most of your code is error handling chores. The problem is artificial.
P.S. That said, any program written in Go is an absolute shitshow of crappy UX because of the (inevitably) inconsistent and often incorrect error handling.
And even then, because Go uses insane and outdated OOP practices like casting all pointers to a generic base class, even reading the source code is a exercise in frustration and rage.
It is silly how many Java or Python programs display stacktraces on trivially preventable problems that are not bugs (e.g. file not found) instead of giving short human readable messages.
Thank God I don't have to code anything in Go myself.
The issue is that application code usually has several layers between the end-user and the fundamental operations like Read()/Write(). Bookkeeping errors through all these layers is a chore. You can skip the layers but then you get spaghetti.