In the other hand, it helps prevent people to build needlessly complex abstractions. That's what I like about go: relatively straight-forward code to read in most project that I have seen.
yes go lends code to be verbose and simple, at times feeling like you must make things too much so, but the rate at which I can understand what someone else is trying to accomplish and vice versa, I keep choosing golang, and it's verbosity.
at the end of the day, for me, verbose and simple is preferred to elegant and clever. to an extent, of course.
You think this that functions returning interface{} are easier to debug than functions that return a specific type? Because that's exactly what you are throwing away with generics.
Allowing specification of the element type of a container data structure is not unnecessary abstraction, it's type safety!
type interface blah { behavior() }
if I have a function that returns an interface I can grep who is calling it and probably digest what it is within a few moments and probably 2 or 3 files of code.
with java I find its so once you get through the factories, abstractions, and more, I have never found what I'm looking for in 2-3 files until I am more intimate with the code base.
Most of the typical design patterns do not hinge on generics or even inheritance and can be implemented easily in Go too.
I completely get what you mean about Go being simplistic and easier to reason than your typical J2EE app. But remember you don't have to write your Java apps that way. Unfortunately "design patterns" took off a decade ago and ended up dragging Java and many other languages into the complexity quicksand.
I hope Go learns from these lessons as it matures.
I'm intimately familiar with the jvm and app dynamics and they do have wonderful tooling.
but, without that tooling I would be really paddling upstream.
call me old fashioned but I like simple tools, and golang I can profile faster and find bugs sooner. I have supported critical infrastructure on both platforms ( Java for many years , golang for 2) and it is not a hard choice to make for me, even with app dynamics and similar tools.
Besides from what I understand the lack of generics is mostly about compile time speed. I love how fast go compiles and would rather that not change.
But I don't buy the argument that we don't need them, and that we will necessarily write worse code with them.