Bug counts/kloc seem to be consistent across languages.
Of course, the problem is that for the compiler implementation, those traits are completely reversed (adding generics at this point is like hitting the compiler with a mallet); and that happens to be Go's primary excuse for lack of generics/templating/macros/anything sane. I think dev ease-of-use matters a lot more than core dev ease-of-use though. Even if the compiler must grow in complexity and average compile time, the benefits to devs are worth it.
Yes, if you want to generalize code to release a library to a much wider audience, you'll either end up writing quite a bit of duplicate code, using the code generation tools, or diving into the "reflect" package (which would let you write Sum in one method).
That said, I've never had to do either of these in writing about 10k lines of Go code.
>Generics are convenient but they come at a cost in complexity in the type system and run-time. We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it.
Not hard as in "can't do it", but hard as in too hard to implement without adding the ever feared "complexity".
For the record, I like Go and its philosophy, but I think, above all other issues with the language, the lack of generics is a huge weakness and will eventually be looked back on as a mistake. Not just for not having them before 1.0, but also for waiting as long as they did for adding them, assuming they ever do add them.
I admit I'm not an expert in programming language design though, so I may be completely wrong about both Java and Go.
Lots of C++ "features" on banned on major projects because of complexity and build time issues -- templates, exceptions, operator overloading...