We created Go first and foremost for ourselves. Go is the language we want to be (and are) writing programs in. I haven't had this much fun writing programs in a long time.
It is emphatically NOT true that Go is "created for people less smart than the designers". At no point during any design discussion did we say "well, that will be too difficult for the average programmer".
The part about "large teams of varying abilities" is not true either. What is true is that Go was designed for large-scale programming, though, and the things that work in a 100-line Haskell pearl don't necessarily scale to million-line programs. Rob Pike gave a talk about this at SPLASH titled "Go at Google: Language Design in the Service of Software Engineering" [1]. I highly recommend it if you want to see where we're coming from with some of the design.
Your third point is certainly true, but I can't think of a decent language that doesn't attempt to make certain types of errors harder than the languages it replaces.
What's peculiar is the way certain words are used by the authors, like "systems" programming, or "programming at scale", etc.
I don't see how Go is more "systems-ey" than say, Java; other than allowing you to pack struct members together by separating pointer and value types in a certain way. C# already allows you to do something similar.
Furthermore, the main arguments I've seen for "programming at scale", are that unused vars get treated as errors, interfaces, and the way dependencies are managed (mainly to speed up compile times).
The latter has been solved by probably any modern language post-C++. Warnings as errors is a preference. Interface types aren't that special when looking at languages like Scala and Rust, which provide very nice and powerful type and trait systems that go really well together; while maintaining the ability to extend types by other traits, not that much unlike Go to begin with.
I am not a language designer, but I can't help but feel that the language was somehow designed into a corner, with the way interfaces and composition work together. All this is making adding generics much harder.
This is a brilliant talk, and it gives excellent reasons for most design decisions — except making error handling "intentionally clumsy". Why not borrow what is arguably the most important Erlang feature, process linking and supervision?
However, this talk does not mention some questionable decisions, such as keeping null references in the language. Why would you do that, instead of using option types?
Can you comment on generics in ML-derived languages?
We created Go first and foremost for ourselves. Go is the language we want to be (and are) writing programs in. I haven't had this much fun writing programs in a long time.
It is emphatically NOT true that Go is "created for people less smart than the designers". At no point during any design discussion did we say "well, that will be too difficult for the average programmer".
The part about "large teams of varying abilities" is not true either. What is true is that Go was designed for large-scale programming, though, and the things that work in a 100-line Haskell pearl don't necessarily scale to million-line programs. Rob Pike gave a talk about this at SPLASH titled "Go at Google: Language Design in the Service of Software Engineering" [1]. I highly recommend it if you want to see where we're coming from with some of the design.
Your third point is certainly true, but I can't think of a decent language that doesn't attempt to make certain types of errors harder than the languages it replaces.
[1] http://talks.golang.org/2012/splash.article