>This is fine in a prototype or in a research paper, but when it comes to production, you will not win the fight against reality. Indeed, that's the argument I

>This is fine in a prototype or in a research paper, but when it comes to production, you will not win the fight against reality. Indeed, that's the argument I'm making. Where's the disagreement? >or programming languages, I imagine the graphs are roughly features vs. complexity (directly correlated) You know Simple Made Easy is a ubiquitous recommendation here and I don't really have anything to add to it. In Haskell as in Lisp all the complex "features" are described in terms of far simpler features. Languages that build in these features explicitly are complex, languages that let you choose don't have to be. This is why C++ is complex and Common Lisp is simple, even though they have a pretty similar feature set all things considered. As far as I can tell Go was designed by people who think C got most stuff right, and they intended to make a language that was hard to screw up in. I think they failed here though because neither option types nor generics are that hard to understand and eliminate huge classes of errors. As I understand it in Go it's pretty common to cast stuff from interface{}. This is a bad pattern because it eliminates type safety. Somebody wrote on HN a while ago, and I'm inclined to agree, that you either have a static type system with generics or you have a dynamic type system. Go is no exception.