this part of error handling is pure religion. it goes even against one of the most basic go tenents. that code should be easy to read not write. Try reading and understanding the logic of a particular method where 75% of the lines are error noise and only 25% are the ones you need to understand what the method does. yes it's noise because whenever read a codebase for the first time you are never interested on the the error edge case. first glance readability needs to tell you what you are trying to accomplish and only after what you are doing to make sure that is correct.

on this point go's error handling is a massive fail. Notice that I'm not saying explicit error handling is bad. I'm saying the insistence that error handling needs to be implemented inline interleaved with the happy path is the problem. You can have explicit error handling in dedicated error handling sections

> yes it's noise because whenever read a codebase for the first time you are never interested on the the error edge case.

maybe this has something to do with how bug-prone it usually is for a new hire to modify a codebase for the first time in most orgs

you could also just do things fail-fast style and panic everywhere if you REALLY wanted to stop inlining error conditions. or ignore error checks until some sort of guard layer that validates things.

IME you usually don't want to do either of those things, and the go approach at least encourages you to think about it closer to the site than checked exceptions (which you can more easily toss up and up and up and auto-add to signatures of callers). unchecked exceptions are arguably less-bad than "just ignore go return errors" - they'll get seen! - but terrible for a reliability/UX perspective.

optional-esque approaches are nice but just a different flavor of the same overhead IMO.

Do you have examples for the latter?