Extending the language is exactly what the go authors and most experienced gophers don't want. I shouldn't have to learn your whole DSL / language extension to use or even read your code. Go intentionally disallows this so that everyone writing go is using the same language, rather than some subset, or god forbid superset, of the language.
Well, it's a wonder that you're speaking English then, since English is routinely extended by means of new words and metaphors. Look, you just used "DSL" and "code", words part of a domain specific language that regular folks do not understand, plus "subset" / "superset" which require basic knowledge of set theory.
Besides, every time you create a new type or interface, you just extended your language with a noun or adjective and every time you come up with a function, you just created a verb. And I have to learn your nouns and your verbs to understand your code, even if you try explicit naming that don't really say anything (my personal favorite being variations on "processItems").
Go is not the first language to take this approach, it won't be last last either. Unfortunately people never learn and it feels like groundhog day, the movie.
There's a difference between adding nouns and verbs, and changing the very structure of the language. If I say "I like to flargle my pofdin in a huffalop" you can still pick out the verb and the nouns, but if I say "#&_35( bar mdfsgh" you can't even tell if what I wrote is valid English.
We aren't talking about changing the structure of the language, but about adding a feature to the language, generics, that would make it easier for people to build reusable libraries, especially libraries that treat functions (the verbs) as values that can be passed around, reused and still keep the static type safety of a language that is static.
Thing is, if you want a language without generics, then you want a dynamic language, because a static language without generics is overkill for building reusable stuff. Go's structural typing is cool and all, that's ad-hoc polymorphism done tastefully, but we are talking about a different kind of polymorphism here with different use-cases.
When you said "a small set of features is bad if users cannot efficiently extend the language because the needed features aren't included" I assumed you meant something like operator overloading or macros or compile-time templates like in other languages. It seems like I was misunderstanding you. If all you meant was "a small set of features is bad if users don't have generics", then yes, my earlier response was not appropriate.
However, I would still have to disagree, given that I have written a lot of very useful code in Go, much of it quite reusable (without interface{} or reflection).
I did go click on that link and started to watch the presentation, FWIW. It's too long for me to watch now, but it definitely looks interesting, so I'll try to watch it in the next couple days. Thanks for pointing it out to me.
