> Having fewer keywords does make Go simpler to learn and simpler to read other peoples code Go carefully touts how few reserved keywords it has, but I think i

> Having fewer keywords does make Go simpler to learn and simpler to read other peoples code Go carefully touts how few reserved keywords it has, but I think it would actually be a simpler to reason about language if it had more reserved keywords. For example, you may notice that "true", "false", "len", "new", etc all aren't reserved keywords. This sometimes does lead to bugs, for example someone may make a function, like "func memoize(new func(...interface{}) interface{}) func(...interface{}) interface{}", which shadows a common builtin function with a function argument. Usually, the above leads to a compiler error when you try to use the "copy" argument (a value) as a function, but every once in a while, you end up with a type-compatible shadow, at which point things can really break. It would be less confusing if things like "new", "len", "copy", and "true" were keywords, rather than builtins that someone may accidentally alias and shadow. If you account for things like rather essential builtins as well, go's list of keywords starts to look far less impressive, and on-par with java or C#.