> Not necessarily. Maybe you want to return the number of bytes read until the error AND the error.
Not mutually exclusive. The number of bytes read until the error occurred could be part of the error itself. Sum types are practically always better. The problem is that Go does not support them.
It's not a problem, because you can simply use product types, so you don't have to extend the language with yet another concept. For the Maybe monad / Option types you'd need lots of additional cruft like parametric polymorphism and probably something like the 'do' notation to make monads bearable. Go would lose all its charm of simplicity. Go would be another Haskell or ML, and we all know that these languages have failed to become successful by ignoring the human aspect of programming. We'd end up with articles like this http://www.haskell.org/haskellwiki/Typeclassopedia , longer than the entire Go specification.
Haskell and ML are practically FP oriented. You might want to check out Rust for a language that is not purely FP oriented (it is multi-paradigm), yet attempts to take pragmatic choices from such languages. There seems to be a good community response to it.
The community response seems to be mostly from people who like to talk about programming language features all day without actually using it for real projects.
I think that's pretty unfair. Rust has not even reached 1.0 yet, and there are already some cool projects being implemented. There were even a couple of games written in Rust for Ludum Dare, not to mention at least one case of use in production.
Not mutually exclusive. The number of bytes read until the error occurred could be part of the error itself. Sum types are practically always better. The problem is that Go does not support them.