Thanks for the Close() example, that's a nice solution, although would it work if you wanted to handle an error (not just log it?) > Standard go error handling

Thanks for the Close() example, that's a nice solution, although would it work if you wanted to handle an error (not just log it?) > Standard go error handling maximises for locality. You don't see many "long range" effects where you have to go and read the rest of the code to understand what's going to happen. Ideally everything you need is in the diff in front of you. I'm assuming you're comparing to exceptions. I don't know about that. I think this relies on discipline of the software engineer. I can see for example someone who is strict and only uses exceptions on failures and returns normal responses during usual operation. With Go you can use errors.Is and errors.As which take away that locality. Or what's worse, you could have someone actually react based on the string of the error message (although with some packages, this might be the only way). I still see your point though, but I also think Rust implemented what Go was trying to do. You get a Result type, which you can either match to get the data and check the error, you can also pass it downward (yes, this will take away that locality, but then compiler will warn you if you have a new unhanded error downstream), or you can chose to unwrap without checking error, which will trigger panic on error.