A great and thoughtful perspective on Go and Go's potential legacy. Nice to read something that responds to the language's explicitly-stated goals, rather than ignoring them outright.
Steele's commentary on "Worse is Better" seems to me to be a better representation of the original essay than the one expressed here about Go. Steele says:
"The gist of ['Worse is Better'] is that the best way to get a language used by many persons is not to design and build 'The Right Thing,' because that will take too long. In a race, a small language with warts will beat a well designed
language because users will not wait for the right thing; they will use the language that is quick and cheap, and put up with the warts. Once a small language fills a niche, it is hard to take its place."
In other words, the lesson of 'Worse is Better' is that getting a 'good enough' thing to market, and benefiting from the network effects of its widespread use, will always beat getting the 'the really good' thing to market in the same category, because the cost of delay is the loss of (community) network effects. The illustrative example here is UNIX and C, but it can be easily cross-applied to more recent projects.
From that vantage point, Go isn't a good example of 'Worse is Better'. It occupies the same niche as C, but was delivered nearly 4 decades later. It seems to be a "second edition of C" designed with very explicit goals of correcting specific deficiencies of C as a systems programming language, but without the scope creep that characterizes many "second systems".
Other languages -- like Python and Scala -- occupy completely different niches and have already achieved similar scale of network effects.
The rest of Guy Steele's talk is worth watching, because his high-level point is that the languages that win aren't the simpler ones, or the ones with the simplest/best design, but instead are the "growable" ones that get to market. For example, from Steele's vantage point, the success of a programming ecosystem like Python's would be evaluated as follows: it isn't that it has the right level of simplicity/dynamism, or an appropriate programming paradigm. That Python made good decisions there helps, but they aren't the key ingredients. Instead, its success is that it shipped in 1991, evolved over time to keep up with programming trends, that it has an awesome 'import' statement, and that programmers feel they can 'grow' the language through libraries (e.g. Django for web development, Pandas for data analysis) without waiting on the slow core language or stdlib evolutionary process.
