I don’t find it confusing, but it is certainly more complex than a simple function call. I chose it because it is a basic usage of generics, to highlight that basic generics are more complex than basic function calls.
A code base that makes heavy usage of generics takes more time to understand than one that doesn’t make heavy use of generics. The readability of go is what I love about it, amongst a few other things.
Without generics, you'd have N functions instead of 1. Are you sure N times the complexity of non-generic function is less than 1 time the complexity of a generic function?
No one knows for sure. I’ve seen a study or two that found that reading and writing generic code is a lot harder, while using a generic library is relatively easy.
Writing generic code is indeed harder than writing non-generic code, but what I wanted to point out is that you can't compare generic code to a non-generic piece that handles only one type (which is often what people do), because the functionality is not the same, it is apples to oranges. What you should compare is non-generic code that handles the same cases as the generic one. So the non-generic code would also get a lot of additional complexity due to that - e.g. instance-of checks or repetition that would be absent in the generic one.
I think genericity is like any other abstraction e.g. functions or interfaces. Applying it blindly can lead to more complexity, but in hands of someone who knows what they are doing it can be a great tool for reducing complexity.
“ in hands of someone who knows what they are doing it can be a great tool for reducing complexity.”
It really boils down to this, but what does that really mean? I’ve been coding for a very long time, and go is one of the very few languages where it’s relatively easy for me to jump into a code base I’ve never seen before and make sense of it. Maybe the majority of code isn’t written be people that “know what they are doing”?
I like to think in terms of optionality, the magnitude of possible upside and down side. I’ve come to the conclusion that heavy abstraction has a large magnitude of downside risk and relatively small upside benefit for large teams and institutions.
Proper abstraction can have a huge upside by allowing people to understand a part of the project without the need to understand all of it. We're using abstractions all the time really, you don't need generics for that. An iterator, a collection, a file, a network connection, a database table are all abstractions. You don't have to read N millions of lines of database code to learn how to use a database. Abstractions like these are good.
Abstractions where the description of the usage (API) is just as complex as the implementation are bad, and I bet you can create them in Go quite easily without generics. At least I know it is possible in Java, and also was before Java 5.
Again, a lot is packed into your usage of the term “proper”. I find new code bases in go far easier to read than new code bases in every other language I’ve used. Are you suggesting that most code bases are written by people that don’t know what they are doing, and are improperly using the language features?
A code base that makes heavy usage of generics takes more time to understand than one that doesn’t make heavy use of generics. The readability of go is what I love about it, amongst a few other things.