> It was developed at the largest internet company on earth by some of the most accomplished programmers in history.
Paradox answered.
New languages are developed almost daily; as hobbies, by students, by academics and so forth. Most of them you've never heard of, will never take the time to look at, because you don't know what gains the language can bring and spending hours reading the research that went into it aren't worth it until you do. Particularly if the new language introduces something new, which requires you to actually learn something, rather than reimagine something you already know in a different way.
But, if you see that someone famous wrote the paper, it might be worth a read, because they have a reputation, and the no-names who write the other languages every day do not have celebrity status yet.
And it only takes a few of those who are curious enough to read it, to break it down into small bits and publish in a blog what benefits other people might get from using it, which will trigger a wider adoption of people learning.
The argument "that everyone is stupid", is what many in the programming community are willing to do, because how many of the other 364 programming languages developed this year did all of the Go enthusiasts read about before jumping on the bandwagon?
That's like saying Dale Earnhardt could recommend driving a Gremlin... sure, it would get a lot of people to go for a test drive, and a lot of those people would then run away.
I fully admit I clinked on the link to the Go website purely because it was from a big name... the exact same thing I did for Hack and Swift and Rust. But I don't write code in Hack or Swift or Rust. I write code in Go.
Sure, I may have missed some really great language put out by an obscure name that never made it to Hacker News. But then again, evidently so did everyone else.
So why do I write code in Go? Because the language and the ecosystem around it are really good. Because I feel like I can understand any piece of code written in it without needing a PhD from Stanford. Because I feel like it pushes people towards simple, straightforward solutions.
Past that first click, the only thing Google means to me is a guaranteed check to pay the bills of all the great people working on the project.
Golang is good only insomuch as C is good, because it's clearly inspired by C. That's why golang is popular, because it's very similar to something everyone already knows. The switching cost is low and the tooling is really nice. Some things are nicer than in other C-like languages, some things aren't. The bottom line is that language innovation these days is largely not happening in C-like languages, so most language innovations aren't popular. Languages like Swift subvert this rule, however Swift has its own (arguably more influential) corporate backing.
Go isn't bad, it's easy. Very easy. Easier than almost everything else. That's why it's popular.
I've heard Go being advocated twice for development teams and both times the "Google" part was at the top. Second was "binary deployment and static compilation" one time, the other time it was "faster than Python and concurrency". So yeah, I believe it.
Even people who could not articulate why Go would be appropriate for a project/task were jumping on the bandwaggon because of "Google does it so it must be good". Which, well, is not a terrible heuristic for some.
"We know that Java must be pretty good, because it is the cool, new programming language. Or is it? If you look at the world of programming languages from a distance, it looks like Java is the latest thing. (From far enough away, all you can see is the large, flashing billboard paid for by Sun.)"
s/Java/Go/g s/Sun/Google/g
Not to say that Go is a bad language (I'd certainly rather use it than Java!), but looking at the language itself to try to identify the reasons for its relative success is doomed to fail.
Is it? People who use Go and people who designed Go both appeal to the language design. It's users write blog posts about that deliberate balance of simplicity and power they encountered in language, which made them productive. And it's creators write posts and give talks on their deliberate approach to language design to achieve this balance. It seems like both, users and creators, are in perfect alignment here.
So why language design can't be the reason of it's success?
Compared to what? Java at the time Go was introduced? Sure. Java now? Um, I think I'd probably rather use modern Java than Go, thanks (although I'd probably reach for Clojure instead). And I'm a Python guy ...
Go solved one problem well (compilation times of large codebases) and was the first introduction for a lot of programmers to any solution for concurrency.
Everything else is kinda ... mediocre.
But, let me be as nice as I can be. Go solves programming problems that large companies have. Sound like several familiar languages of the past?
I recall that being true of Java, as well, in the early years.
If Facebook, Tencent or even Microsoft were to create and publicize a new programming language written by industry luminaries, it too would likely crack the top 30 languages in terms of popularity.
This broke the "We MUST use only one of the top 5 languages or else" taboo which then allowed things to proliferate.
Go showcases many of the mistakes of the first mover.
Although, to be fair, they aren't all necessarily mistakes. Go has as an OVERRIDING design constraint to be able to compile, very quickly, an absolutely enormous, disjoint codebase. And, it's not clear that any of the other languages can do that.
I, in my personal use of programming languages, don't care about that particular design constraint, so I'm not willing to give up other things in a programming language in service of that particular goal.
None of those two were the best language available, although C# isn't bad by any measure.
New Jersey gives you the web. MIT gives you systemd.
Neither school has been all that effective in reliability, dependability or even composability (especially not interposable interfaces). Neither school is elegant in the slightest.
There's been some fascinating research in this regard, finding that things get popular based on social factors (namely the shape of the social graph) coupled with some amount of random change, largely removed from any intrinsic qualities of the thing in question[1].
Another annoying thing this article—and similar ones like it—does is conflate "different" and "unfamiliar" with "complex". Even if you don't understand it, the Haskell type system is not complex: it's a slight elaboration of the lambda calculus which can be fully described on half a piece of paper with type theoretic notation which translates to maybe a page or two of prose. (Which is only needed to provide some general background information.) Haskell really does boil down to a simple kernel like this which is even used by the compiler (as an intermediate form called "Core"). Everything else is just syntax sugar, usually in transparent ways.
In a similar vein, the article conflates simplicity of implementation with simplicity of language. The two diverge as soon as you start caring about performance—performance breaks all abstractions. That's the only reason GHC is complicated; writing an interpreter for Haskell is actually probably easier than Go because, again, it's just the lambda calculus. That's literally something we teach freshman in a general-purpose intro course (SICP[2]). It's easier to understand what a Haskell program means because of this; it's only harder once you start worrying about low-level optimization. The dynamic semantics of Haskell—what happens as an expression is evaluated—can largely be summed up in a single rule describing function application. That's it! Even if you find it difficult, which is understandable, it is not complex; difficulty is as much a function of your background as anything else.
Popularity is a terrible way of evaluating programming languages on anything but their popularity. Simplicity of implementation is not simplicity in general. This article is decidedly unconvincing.
[1]: Here's a nice summary with references to peer-reviewed studies: http://nautil.us/issue/5/fame/homo-narrativus-and-the-troubl...
[2]: The Structure and Interpretation of Computer Programs, an book introducing CS still used at many universities and available free online: https://mitpress.mit.edu/sicp/
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.
