Look, with Go's interface{} system and its out-of-box "pseudo-generic" typed arrays, slices, maps and channels -- there really isn't an awful lot missing in day

Look, with Go's interface{} system and its out-of-box "pseudo-generic" typed arrays, slices, maps and channels -- there really isn't an awful lot missing in day-to-day pragmatic programming. Pragmatic as in "old-school imperative line-by-line programming with a few modern ideas mixed in as feasible" -- not necessarily software engineering concoctions of patterns of factories etc. Again -- the interface{}s and boxing/unboxing, typed maps/slices/arrays/channels -- they all represent stuff where (A) the compiler can infer type knowledge safely and (B) very fast compile-and-link times are not compromised. Like any language, Go isn't designed to cater to every use-case or programming style. You wouldn't even consider C for your above issues -- right? -- well the safe bet is to always view Go more in the realm of a modern, saner C rather than comparing it to Haskell, or Python, or Scala, or ...... The topic of generics comes up about 2x a week on the golang mailing list / Google Group, often (well sometimes) discussed in-depth with good arguments and quality of discourse. So... either the core gophers are just too clueless and dogmatic to be adding them to the language, or their reasons are still as valid as last month or year with regard to Go's primary design goals and focus.