For Better or for Worse | Hacker News Reader

For Better or for Worse

jmoiron.net

57 pointsBarkMore33 comments

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.

Entropy dictates a compromise always wins.

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

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.

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.

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

Maintainable in the short-term.

What makes you say that?

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

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.

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

And are they easy to maintain?

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.

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.

I very much dislike that invalid states are left representable in idiomatic go error handling.

I trust Go's authors more than others because I trust their experience. They have solved hard problems and I believe have wisdom about how to develop software well. There are certainly people who have done that as well but aren't famous. I hope I will discover their work so I can learn from it. But since Go's marketing is much better, I will use it and benefit from the learned experience of its creators.

Indeed. Go is very polished. The tooling is excellent. This stuff matters a lot.

> Paradox answered.

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.

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

Not an entirely accurate comparison. My toaster doesn't announce "Powered by Go!!!" when I turn it on, unlike all the Java gizmos around here do. Google seems content to let people decide to use Go, or not, without buying up Superbowl ads to promote it.

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

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

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

I recall that being true of Java, as well, in the early years.

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.

Or avoid subtyping altogether. Interfaces (Type classes) are enough.

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

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

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

[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/

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.

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.

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.

Why the "would" there? Microsoft did it, twice; and it did become one of the top 5, twice. (Oh, well, in fact it was three times, but the first time they were small.)

None of those two were the best language available, although C# isn't bad by any measure.

You mean like Facebook's Hack language?

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

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.

Reply on news.ycombinator.com