The edge cases regarding generics have to do with the mixing of inheritance subtyping and generics. The ML family have working generics and they work well. Go

The edge cases regarding generics have to do with the mixing of inheritance subtyping and generics. The ML family have working generics and they work well. Go made the good decision of avoiding sub-typing, so they should not have a serious problem with generics. The C# author, Anders Hejlsberg, back when C# was around 5 years old has admitted that they failed to study the state of the art of programming language design and repeating the (very old) nullability mistake. This should despell the myth that design mistakes in modern programming languages are intentional trade-off positions. It isn't true -- modern language designers simply forsake the process of learning the various state-of-the-art languages and decide to reinvent the wheel, poorly. People get attached to languages, so this will hurt some feelings here, but I think this is true of Go too. Rob Pike and others have repeated the mistake of failing to learn from the state of the art and re-encoded several age old PL design mistakes that could have easily been averted. A couple of clear mistakes in Go: * Everything is nullable * Boolean blindness Some features that Go should have stolen: * Sum types and pattern-matching (this would help with boolean blindness) * Type-classes (So much more powerful than interface inheritance, and can be implemented more efficiently in many cases) Given the majority of programmers themselves also do not study the state of the art, these designs, for all their (avoidable) mistakes become popular and persist, and make us all live with poorer-quality software for much longer. [1] http://channel9.msdn.com/Shows/Going+Deep/Anders-Hejlsberg-Questions-and-Answers http://channel9.msdn.com/Shows/Going+Deep/Anders-Hejlsberg-Q... (1:00:35)