Learn the functional style, and it will look so much more simple. >Where's all the logical exit branches from this for error recovery? No exit; the error is c

Learn the functional style, and it will look so much more simple. >Where's all the logical exit branches from this for error recovery? No exit; the error is carried on in the pipe until the end. Successive transformations simply have no effect, since the data is in error. The chain output type can be either the data you want, or an error. > Is this properly null checking if required? Stop using null's. > This style of programming is what i call 'happy path' programming. It only works properly with valid input. The unhappy path can be handled just as well, you merely have to incorporate it in the type of output your system can produce. In that way, errors are also a happy path. > Go forces the developer to explore non-happy path cases during development. [...] The syntax is ugly however, personally believe that it leads to higher quality systems. When I program in a language like Haskell, not exploring unhappy paths leads to code that doesn't even compile. Usually this leads to pretty good quality.