> And if you just want to pass it up the stack then there is no syntactic overhead associated with it. "Errors are values" means that this situation is not ver

> And if you just want to pass it up the stack then there is no syntactic overhead associated with it. "Errors are values" means that this situation is not very different from "I just want to pass the result of my sqrt function up the stack" :) By reading code of function that returns the result of computation the next pair of eyes that gonna read this code will clearly see the intent and idea behind the code. The same should be with "unhappy path" – if intent was just to pass error, without caring of annotating it or doing something with it – it should be as clear and explicit as possible. There is another benefit of "syntactic overhead" – incentive to improve the error handling code. I.e. I may not care at the beginning about annotating error, and just use "return err", but later on I want to make error messages more useful, so the "if err != nil {\n return err }\n" structure makes it easy to annotate it. Instead, if Go code was riddled with "?"s or "!"s or whatever syntactic sugar other use, I would not be so eager to switch from "concise and short single-char" to the "bloated 3 line". Incentives matter in coding psychology. I wish more research was done on that. Bottom line, hiding error handling has more long term drawbacks than benefits. PS. I virtually never use "return err" anymore. Always at least annotate the error – it helps error messages readability immensely without resorting to adding wasteful stacktraces.