I find it hard to reason about text which contains stylistic assumptions which are quite handwavy, such as > which is opaque, hard to reason about, and can enc

I find it hard to reason about text which contains stylistic assumptions which are quite handwavy, such as > which is opaque, hard to reason about, and can encourage some lazy programming habits. In the same handwaving vein to me it is not opaque and does not encourage lazy programming habits. Having to return `err` is no different to raising an exception except that you do not do stack unwinding, but it does force you to write more code because the language designers have decided that dealing with every possible error, inline, using conditionals, is way more important to them than making the happy path of the algorithm readable as one unit of prose. To me there is no difference in outcome when the happy path is written out first, and then the possible failure conditions are enumerated. It can be accomplished with sum types, but it can also be accomplished by matching on exception types. The difficult part about Go's errors is that they are neither. For example, if you want a backtrace: congratulations, you have to use `errors` and wrap every single error you receive from your callees. You want to accumulate the causes of an error and pass it up? Well you better hope that your callees already have stored this metadata for you. The error is in `net/http/internalpkgoranother`? Bad luck, as it surely won't be wrapping for you. So some essential metadata is missing. Want to avoid ambiguous returns? Bad luck. If you read from an `io.Reader` and it returns you no error but the "read count" of 0, what do you do then? When you type match on the return value of the `io.Reader.Read()` and it tells you it read N bytes but it also gives you the EOF error - what do you handle first? Even the basic Go idioms which are touted as great examples of composability and interface application (with which I can agree actually) have these edge cases of a double-meaning-return. Neither exceptions NOR sum types have this problem, so I guess both camps are unhappy. What does put me off though is that the Go community seems to have this style of examining a (possibly arbitrary) Go design choice, and then to position it as THE way to write software. Sometimes it is done by denigrating developers who voice their stylistic disagreements with the choices designers have made ("you are not smart enough to use exceptions", "you are not smart enough to use sum types", "you are not smart enough to use generics"), and sometimes it is done with handwavy statements about code using other idioms being "opaque and hard to reason about". I would really appreciate if the Go community could be a bit more mindful of when their praises of language designers sound to people preferring other tech like lecturing (or scolding, if you will). For instance because despite some very large projects using Go it might be alienating or "othering" a lot of people who do not share the enthusiasm or would otherwise use the language – and contribute to the ecosystem in a meaningful way – just for the sake of getting the job done.