
For Better or for Worse - BarkMore
http://jmoiron.net/blog/for-better-or-for-worse/
======
vezzy-fnord
MIT v. New Jersey is a false dichotomy. MIT tends to put the cognitive
overhead on the callee, where New Jersey does so on the caller. New Jersey
tends to eschew in-depth architectural modeling leading to insufficient
generality and flexibility, whereas MIT creates overly coarse-grained results
from axiomatically underthought standards for "correctness" and an overbearing
sense for what is "complete" (which usually starts to infringe on mechanism
and begins making policy decisions, hence again lowering generality).

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.

~~~
valarauca1
Entropy dictates a compromise always wins.

------
sparkie
> If Go is bad, why is it so popular? The cognitive dissonance is particularly
> difficult to contend with this time around.

> 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?

~~~
natefinch
The Google name surely gets a lot of people's attention. But if the language
actually sucked, it's not going to matter. This is a tool that you have to use
EVERY DAY. The Google name is far from a guaranteed hit maker. See Google
Plus, Google Wave, etc.

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.

~~~
jolux
It's not that golang is bad, just that it's not good. Understanding the
difference between those two is understanding why golang is popular, why Java
is popular, why C is popular, why any number of other mediocre things are
popular. Golang gets a lot of stuff right, but most of the stuff it gets right
isn't to do with the intrinsic design of the language.

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.

~~~
natefinch
The Go language is an excellent tool for shipping maintainable server-side
applications.

~~~
zeckalpha
Maintainable in the short-term.

~~~
NateDad
What makes you say that?

~~~
jolux
Because it has a few fundamental quirks that make it a poor choice for
enormous systems. It uses mutable data by default, the type system is not all
that strong, and it has no facilities for making abstractions due to it being
_too simple_. The developers of golang consciously throw out like 30 years of
research in programming language theory because the idea of a language that
gets "back to the basics" is appealing to a large group of (mostly good,
experienced) programmers even though it's not a particularly good idea.

The first answer to this Quora question by one of the developers of D explains
a few other points and also what golang is really good at:

[https://www.quora.com/Which-language-has-the-brightest-
futur...](https://www.quora.com/Which-language-has-the-brightest-future-in-
replacement-of-C-between-D-Go-and-Rust-And-Why)

~~~
natefinch
All of the most popular languages have mutable data by default. 99.99% of all
enormous systems were written with mutable by default languages.

The type system not being "strong" simply means that you put logic in
functions and methods instead of magic parts of the type system.

And Go can absolutely make abstractions. The standard library is full of
abstractions. Every Go package is an abstraction. Hell, every function is an
abstraction.

~~~
zeckalpha
> 99.99% of all enormous systems were written with mutable by default
> languages.

And are they easy to maintain?

~~~
natefinch
Not so bad. And the one I'm working on in Go is definitely helped by being in
a simpler language. I don't really think immutable data would be a huge boon
to maintainability. Some sure, but I think it would also complicate some of
the code.

~~~
jolux
So you think syntactical simplicity is more important to the maintainability
of a large system than whether or not it uses immutable data? Ok.

Because immutability is a massive boon to horizontal scaling and
maintainability in ways that are simply unattainable in languages where it's
not encouraged. It makes concurrency and parallelism observably trivial, it
makes your code safer. Assuming you're using a strictly evaluated (AKA eager,
greedy, whatever else you know to mean not-lazy) language with immutable data,
race conditions are eliminated.

Let's review that again. In a large distributed codebase written in an
immutable language, (let's say Elixir, it's fashionable at the moment and good
for doing this kind of stuff) concurrency and parallelism are trivial and race
conditions are nonexistent. This is even before we get to type safety and
stuff like the actor model. That's huge. That's the immutability advantage. I
could go on but it's late and I have school tomorrow.

------
kijiki
From
[http://www.paulgraham.com/icad.html](http://www.paulgraham.com/icad.html)

"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.

~~~
divan
> 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?

~~~
bsder
> It's users write blog posts about that deliberate balance of simplicity and
> power they encountered in language, which made them productive.

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?

------
norswap
There is simply no excuse for not having generics. Node, nada. If you think
that co/contra-variance is confusing (which it is, we need better materials to
teach it), at least go the Dart way and make everything covariant by default.

~~~
Retra
Why doesn't someone just make a preprocessor for Go? Make a simple template
system.

~~~
bsder
Why don't we just use a better language? It's not like we have a shortage.

------
tikhonj
There's no cognitive dissonance needed: popularity is simply not a strong
indicator of quality. I'm not saying that "popular things are bad" but rather
that "popular things _can be_ bad" and that quality is mostly orthogonal to
popularity. There's no more conflict in saying that Go is bad despite its
popularity any more than there is in saying that Big Macs are poor quality
food. (Which are, of course, developed by leading minds at one of the largest
food processing corporations in the world...)

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...](http://nautil.us/issue/5/fame/homo-narrativus-and-the-trouble-with-
fame)

[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://mitpress.mit.edu/sicp/)

~~~
catnaroek
Indeed. The only objectively valid measure of a programming language's
simplicity is the size of its formal semantics, with a large penalty for any
behavior left undefined. Mathematics, unlike English, doesn't let you sweep
details under the rug.

------
xiaoma
The pedigree of its authors and the backing of Google goes a very long way in
explaining its ability to gain some modest level of popularity.

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.

~~~
bsder
It was also one of the first "new" languages coming out that had backing of a
big company.

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.

------
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.

