agree. when it's 3:42am and you get called in to debug something in a production system in the middle of the night, it's a hell of a lot quicker to visually and mentally parse and digest golang
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!
while that's an example that I do see in the wild, not every function returns interface. but it doesn't really hurt my argument.
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.
Not in a container, where generics are typically used. Of course, blah could be an interface requiring a comparison or hash method, but the effective result is the same: you have to do reflection to find out what is in the container, there are no compile-time guarantees.
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!