The problem is that even those are boring. I've used Go for an extended period of time on a large project and there's nothing to report. It works just like what everyone else already says.
In my (limited, biased) experience, there's three camps among the Python community:
1. people who want principle-of-least-surprise: there's a lot to be said for boring languages (if the language is the most interesting thing about your product...). Often the systems engineering/service engineering crowd.
2. people who want it to be more functional – the Haskell/Scala/ML crowd. (I guess the overlap between camp 1 and camp 2 is Erlang...)
3. people who want access to the library ecosystem, particularly the Numpy/Scipy/Pandas/Theano stack (the scientific community, latterly data scientists). This is my tribe.
So you've got three crowds here, at least, unified by a language. Where are they going to head?
Go has nothing for the second crowd; they're all going to go to a purer FP language sooner or later. It doesn't have much for the third (no IPython, LAPACK bindings, Fortran bindings, stats libraries, machine learning, etc...); we all have an eye on Julia. But for the first: great deployment story, small language, decent standard libraries, markedly better performance than Python, much better parallelism story...
Those who tried Go and came from a background of more advanced languages just threw it away quickly and wrote nothing about Go.
[1] http://www.starling-software.com/en/blog/my-beautiful-code/2...
The linked post seems to be a very superficial take of Go. I wonder if he'd keep his opinion of Go after learning about lack of generics, error product types, nulls, mutability of concurrent messages, and all the other show stopper design mistakes...
It would be trivial to specify that all Monads are also Functors by changing the definition of the Monad class a little bit:
class Functor m => Monad m where