Are generics really considered as "esoteric comp sci topics"?

I needed to use C# for some project. Used generics without actually being aware what they were. Helps that C# implements generics without type erasure.

> Helps that C# implements generics without type erasure.

For about 95% of "using generics" that makes no difference, and you'd have had no more issue in Java.

That aside, Go is implementing reified generics (there is no real backwards compatibility concern as the "core" collections are already ad-hoc parametric types, and the rest is not a great loss).

Java had a lot more legacy code using a much higher number of standard but not-generic-at-all collections, I'd bet there were also concerns around the forward compatibility of legacy reflection code, and they'd probably considered a lot of collections-related goodwill spent with Java 1.2's Collections Framework and the deprecation of the limited set of original collections.

If you want coding to be accessible to people without comp sci degrees, and those who are NOT employed as full time developers.

I’m not sure Go has ever been a great language for non-CS people, but it’s been a very long time since I was new to programming. Go is pretty clearly a “get shit done” language catered to developers: a productivity tool. Why should it have its capabilities restricted?

English is used in both reality TV shows and scientific journals. The vocabulary used in the latter doesn’t prevent it from being useful in the former.

Go will still be usable the exact same way it is today after generics are brought in. It’s not like all the existing more approachable code written without generics won’t just disappear overnight.

That said, I agree with GP. Generics aren’t that complex anyway.

If people can understand functions, they can understand generics. Nothing more complicated, generics are just functions on a few type arguments.

Here’s an example from this very thread that shows how complex generics get relatively quickly.

https://news.ycombinator.com/item?id=28255738

That example is essentially the most basic use of generics. There are much more complex examples that would support your argument better.

What do you find confusing about that code?

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?

I learned C++ when I was 13, Haskell at age 15. I don't have a CS degree nor do I work as a developer.

I learned C++ templates during high school, back when C++ARM book was the official standard.