You can write any useful program in assembly, but compile time is dirt cheap so it's far more reasonable to automate anything that doesn't require thought and creativity. E.g., a large set of identical function bodies with similar but different types, where if I write them by hand the best I can do is not make any mistakes.

Agreed that “excess abstraction entering the Go ecosystem” is probably the main danger, but even still, I’m not too worried. The Go community is all about simplicity, and I don’t see that changing. It’s not going to suddenly become the Enterprise Java community. Libraries with crazy abstract APIs won’t become popular.

I expect it’ll be similar to Python, which supports generics, very powerful reflection, many programming paradigms, etc., but the popular libraries tend to have simple, easy to understand APIs, because that’s just the culture of the community.

This last point isn’t true at all. Lots of popular libraries do weird things. Lots of popular library functions do completely different things based on the types and combinations of provided parameters (Pandas being one of the most egregious offenders, but the stdlib does this all over too) or they overload operators to make a clever, magical DSL (e.g., SQLAlchemy). Or they use metaclasses to programmatically generate APIs (e.g., AWS sdk, SQLAlchemy, etc). I take notice because I use Python professionally and spend so much more time pouring over docs and source code trying to grok APIs than I do with Go.

Yeah, the scientific Python world is a different story, but I’d say most Python libraries are simple to use, including the AWS SDK. Agreed that SQLAlchemy is much tougher to use if you opt in to their DSL, but to be fair that’s true of every SQL lib with a DSL, in every language I’ve used.

Basically, I find that though it’s possible to do all sorts of crazy shit in Python, most popular libraries have simple APIs, because simplicity is part of Python’s culture. There are certainly exceptions though.

Agreed that the scientific community are the worst offenders, but I don't think it's just them. There are examples all over, but I don't think this conversation will benefit from their enumeration. I will point out that you're letting SQLAlchemy off the hook because their DSL is "opt in" and it's par for the course for DSLs; however, their DSL is not really "opt in", it's the standard way for building queries. Further, "DSLs will be DSLs" is kind of missing the point, which is that the Go community rejects these kinds of hacky DSLs while the Python community embraces them.

At the end of the day, I notice a significant difference in wanton magic between the Go and Python communities, and it's big enough to make me prefer Go over Python when given the choice (despite that I've used Python far longer and more regularly).

Those overly abstracted libraries already exist, they are just using interface {} everywhere or go generate.

Maybe, although I suspect that these libraries are but a shadow of what will follow the release of generics. Hopefully I’m wrong! :)

Of course we can, after all we were writing code before generics became mainstream around the mid-2000's.

The point was creating a language without them after they had become a common language feature across all major static languages.

C doesn't have generics. Objective-C didn't get generics until 2015, which is well after Go was released. Not all major static languages have generics and not all major static languages had generics when Go was being planned.

Not that Go ever planned to not have generics. It was always simply a question of how to implement them in a non-ridiculous way. They were warned early on by members of the Java team to tread carefully and not make the same mistakes they did.

The team has crafted many generics proposals over the years, but they all fell short one way or another.

C has basic support for generics since 2011.

Objective-C merges C's type system with the dynamism of Smalltalk. Generics are only meant as a mechanism to ease interop with Swift.

Dynamic languages naturally don't require generics due to their semantics.

The team always handwaved the remarks of many of us as they now themselves recognise.

"In retrospect, we were biased too much by experience with C++ without concepts and Java generics. We would have been well-served to spend more time with CLU and C++ concepts earlier."

To be fair, we had macros and they covered many of the uses of generics people are arguing with.

Yeah, I can't count the times I heard some variation of "It's literally impossible to ship software without generics" from /r/programming alone. The OP's idealism/pragmatism comment is particularly misguided, since Go consistently favors pragmatism over idealism and in fact that was why Go has held off for so long on adding generics (idealism would have added them from day 1, consequences be damned).