Another is that generics already exist in the language - map works even for user defined types. But since you can't make your own generics, map is all you get. With generics map is just a standard library feature rather than a core language feature, and you could write your own containers too if you wanted.

These might not make the language spec strictly shorter, but definitely more orthogonal.

For example, he completely missed defer.

Unfortunately, the Cheez Whiz ponies aren't implemented yet, but if D ever hits 3.0 maybe it can be pushed into the spec.

I'd wait first for the any of the existing D2 compiler(s) to at least implement the features that are in D2 'spec', as it currently stands there are no implementations of D2, and that is without going into all the bugs in the most used compilers.

Every language is designed according to that rule. No language designer thinks, "Let me just slap some extra unneeded stuff in there." They just differ on what they consider necessary.

In Go's case, I think many of the things they've omitted from the language are actually useful features and they've just pushed the complexity onto the users. For example, no exceptions just ends up meaning "if err != nil { return nil; }" everywhere.

False. Ruby and Perl were both designed (at least for a time) by adding stuff people were asking for or talking about. Not all language designers set a high priority on the thought, "Can we do without it?"

The defer statement is certainly Go-esque, but not as clean as RAII, because I can still forget to write the defer statement after opening a file. This violates DRY when doing file I/O. You can argue that Go never purported to support these concepts in the first place, but, at the end of the day, I'm writing code over and over again needlessly. Not elegant in the slightest.