Also this quote explains the design of Go (even thou he said it in the context of Plan9/Inferno)[1]

"Thompson. The aggressive use of a small number of abstractions is, I think, the direct result of a very small number of people who interact closely during the implementation. It's not a committee where everyone is trying to introduce their favorite thing. Essentially, if you have a technical argument or question, you have to sway two or three other people who are very savvy. They know what is going on, and you can't put anything over on them."

Rob Pike says the same thing. "All three of us need to be convinced for a feature to make it into the language"

[1] http://genius.cat-v.org/ken-thompson/interviews/unix-and-bey...

You are right, Rob Pike said it was for "large teams". In most places (maybe not Google) "large team" will often mean an average skill level that is mediocre. I do not understand why a large team of very skilled programmers can't build large systems that are very maintainable in more powerful and expressive languages. I do not understand the argument that a language is "too complex" in this context.

edit: You are right and I added this to my top-level comment. The "mediocre programmer" comment is really out of line and a major distraction. I guess I actually think this IS a feature of Go: more maintainable code than C/C++ from mediocre developers. I'm bitter and tired ofdebugging twenty-year old C programs and I wish they were all written in Go. I shouldn't read that into Thompson's or Pike's intentions though.

Whenever I hear someone denigrate simplicity in a language as something that caters to 'mediocre' or 'average' programmers, I'm reminded of the surveys where 80% of people think they're an above average driver.

>The creators of the language (who are not mediocre) like simple languages.

They are surely not mediocre programmers (or mediocre contributors to computing).

They are however mediocre in their modern language design skills. What are their language credentials?

Lars Bak is a compiler/language guy. Wirth was a compiler/language guy. Hejlsberg is a compiler/language guy.

The Go guys? Not so much.

Having designed the best systems language 40 years ago is not a sure sign that you can also design a good systems (or not) language 40 years later. Compiler design has changed a lot since then, but it's not like Go has a lot to show for it (ok, they also wrote 1-2 other ho-hum languages, like the Plan9 one).

Plus, beside the language specs, there is also the compiler. Did those guys ever wrote a top-notch compiler? The original C compiler wasn't the state of the art in the language. It took lots of efforts and different companies to get to the advanced optimized C compilers we have today.

Plan 9 was far more impressive a feat than Go was, and much closer to where the team's skills are.

Fair points but I wrote the response above saying that its not really about ability, its about taste. Neverthelesss I had to assert something about the Go language designer's ability in order to refute the top post about mediocrity. Now you are back to talking about ability and credentials. We could go back and forth all day. The point is that Go is the first mainstream systems language to focus on leaving stuff out. Think about lisp, its beautiful because its really just one thing but you can do everything with that one thing. Go is not the same but the aesthetic is similar. It's a question of taste. Do you like a powerful tool with loads of abstractions? Or do you like to strip everything down to the metal and see what is the minimum you can run with and still retain most of the fire? Some of those things that you leave out may turn out to be those things that have come out of "modern language design".

Scala has many modern language features yet Martin Odersky said, of Go "I like a lot of the design decisions they made in the language. Basically, I like all of them." He can appreciate it because there is also an aesthetic in Scala that focuses on a minimal, simple, consistent core. But Scala has a shell with a bigger surface area. Depending on the context and the kind of person you are you might want one or the other but there is no point in criticising Go by saying "Its missing feature X". That's like criticising a race car because it doesn't have a sat nav. It still does 80% of what a normal car does but it does the core things that a car does really well and its not just that you have less weight its also that you can focus on driving it because there is less to distract you. (Where driving == building cool stuff faster because I'm not constantly getting distracted by thinking about how to make the code more clever ('Hmm maybe I could metaprogram that and save another three lines')). In general the simpler car is also easier to fix and easier to understand (these attributes are more important in programming languages than in cars, no matter what the ability of the programmers (cognitive load)). Of course there is an argument for having a sat nav in other contexts.