
For Better or for Worse - koolhead17
http://jmoiron.net/blog/for-better-or-for-worse/
======
sagichmal
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.

------
pixelmonkey
I recently watched Guy Steele's "Growing a Language" talk. It's very much
related to jmoiron's post here, and is worth a watch despite its age:

[https://www.youtube.com/watch?v=_ahvzDzKdB0](https://www.youtube.com/watch?v=_ahvzDzKdB0)

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.

