<>, err = <>
  if err != nil { return nil, err }
  <>, err = <>
  if err != nil { return nil, err }

Is not what software engineers should spend time on, definitely.

Not automating ubiquitous trivial propagations with at least explicit "rie <expr>" (rie for "return if error") is a complete engineering fail under any philosophy.

Oh, I have an idea. If ", err" part is missing from lvalue, insert that mantra automagically under #pragma ARIE=on. This workaround will give designers some stats to embrace.

I consider that explicitly and manually handling every possible error, and making a conscious decision to bubble it up (return) or to interpret it is a very good use of my time as a programmer.

> Is not what software engineers should spend time on, definitely.

But hey! Your editor can easily boilerplate all that... boilerplate!

I think Go will continue to grow until we finally have metrics that say that coding something in Go might get you fast-running code but will be slower to code and hell to maintain.

It really doesn't have to be that way. See http://fsharpforfunandprofit.com/posts/recipe-part2