I can't believe how they're actually using "Built-in generic types, i.e. the current Go approach (generic types map/chan/slice)" as an argument AGAINST generics

I can't believe how they're actually using "Built-in generic types, i.e. the current Go approach (generic types map/chan/slice)" as an argument AGAINST generics. I mean this is unbelievable. Of course that list is not complete, as there are more generic datatypes in Go (arrays, function return value-tuples, ...). Fact is, the golang authors are using generics (and polymorphism, and ...) in the language and in the compiler. So they have answered all the questions about generics : > does it result in a slow compiler ? Obviously not, after all the compiler has generics. > are generic structures less useful ? Well how useful do the Go authors find map/slice/arrays/... the generic Go datatypes ? So obviously this is both a bullshit argument and one people like Rob Pike don't actually believe is true. > Generic structures are less optimized If this is true, then clearly Go's authors find this an acceptable cost. More generally, let's take a look at Rob Pike's example code. For instance here is a talk described as "An hour-long talk delivered by Rob Pike at Google in October 2009. The language's first public introduction." http://talks.golang.org/2009/go_talk-20091030.pdf http://talks.golang.org/2009/go_talk-20091030.pdf First code example that isn't hello world, first function called : if len(str) > 0 { ch = str[0] } A polymorphic function ... weekend := []string{ "Saturday", "Sunday" } timeZones := map[string]TZ { "UTC":UTC, "EST":EST, "CST":CST, //... } Generic data types. Why are we arguing about this ? There is no disagreement between Go's users and authors : Go needs generics. The authors simply don't feel capable of implementing it. How about, like hundred other problems in Go we simply ask ourselves "is this hard to program in a compiler ?", and yes it is. So they put in an ugly hack for their own special cases. This argument, first of all, consistently fits all Go languge decisions leading to the correct conclusion, as opposed to all the arguments given by the Go authors that have no end of exceptions and personal preferences to take into account to arrive at the correct conclusion. Go's authors clearly have some trouble understanding the mathematical foundations of type systems, which is plainly visible in Go's type system. It's inconsistent. Without massive holes in the language, like we currently, this will become VERY visible and move people away from Go.