Lies we tell ourselves to keep using Golang (2022)

First off, let's appreciate the fact the author has managed to write this humongous article in a day. That's some writing skill.

And indeed, leveraging writing skills to unleash a flood of words in order to overwhelm anyone trying to respond is just the first tactic of many used by the author to sound more convincing, which is going to be the point of my post. I'm going to analyze each rhetorical device, fallacy, and bias present in the article.

> The author is a platypus

The point of this paragraph is not to present any arguments, it is devoid of them, but to elicit sympathy from the reader for the poor author who is clearly getting ganged up upon. Comments in the referenced HN thread did not in fact attack the credentials of the author in any way. See Appeal to pity [3].

> Mom smokes, so it's probably okay

Lots of words here, but the gist of it is:

> Or you can be horrified, as you realize that those complex problems only exist because Go is being used. Those complex problems would not exist in other languages, not even in C, which I can definitely not be accused of shilling for (and would not recommend as a Go replacement).

Setting aside the validity of the technical arguments, the tactic used here is to imply that since certain other languages don't have the specific mentioned problems, they are strictly superior. In reality, had another language been used, the Tailscale team would simply be dealing with different problems. To riff off the C example, if Tailscale used C, they'd be dealing with memory safety issues instead.

> The good parts

A clever attempt at a lie of omission. First we list a tiny subset of the pros of Go, then we claim that this tiny subset is not enough to make up for the numerous cons. See Cherry picking [4] and Straw man [5].

> And since, just like C and Java, you do not get to decide what is mutable and what is immutable (the const keyword in C is essentially advisory, kinda), passing a reference to something (to avoid a costly copy, for example) is fraught with risk, like it getting mutated from under you, or it being held somewhere forever, preventing it from being freed (a lesser, but very real, problem).

Here we see a thinly veiled reference to the main bias behind the article. Can you guess what language the author is implicitly talking about here?

> Go is an island

Nothing really interesting here, but it's worth noting that, just like the majority of arguments presented so far, this largely applies to most languages out there (but of course not to the language we're really talking about here).

> All or nothing (so let's do nothing)

The thrust is another strawman, quite simply nobody argues this: "It's not like you can prevent all problems anyway.".

This section is only a lead-up to the next one anyway...

> "Rust is perfect and you're all idiots"

Huh, why do we suddenly have a tirade about Rust in what's supposedly an article on Go? If you correctly guessed earlier that this entire article is actually about Rust, congratulations.

> Folks who develop an allergic reaction to "big balls of mutable state without sum types" tend to gravitate towards languages that gives them control over mutability, lifetimes, and lets them build abstractions. That those languages happen to often be Go and Rust is immaterial.

Wait a second, language*s* with sum types, control over mutability, and lifetimes? So, Rust, Rust, and Rust?

> Because function signatures don't tell you much of anything (does this mutate data? does it hold onto it? [...]

Only Rust is good enough, we get it already.

---

Overall, we have quite a few strong technical points here that could have made for a compelling article, but they're marred by copious use of fallacious arguments and blind fanboyism for a certain language.

---

[1]: https://news.ycombinator.com/item?id=31191700

[2]: https://news.ycombinator.com/item?id=31205072

[3]: https://en.wikipedia.org/wiki/Appeal_to_pity

[4]: https://en.wikipedia.org/wiki/Cherry_picking

[5]: https://en.wikipedia.org/wiki/Straw_man

Or how does one optionally throw and exception without an "if" statement? What's the "base" exception call?

Ie if "if" is implemented via exceptions, how do exceptions get triggered?

And is "while" done via an "if exception" and recursion? Or another way?

A failure can propagate in the same circumstances in a Rust program. First, Rust has panics, which are exceptions. Second, if any function you call returns Result, and if propagate any error to your caller with ?, you have the same from-anywhere control flow you're complaining about above.

Programmers who can't maintain invariants in exceptional code can't maintain them at all.

> try…catch is a non-expression statement,

That's a language design choice. Some languages, like Common Lisp, have a catch that's also an expression. So what?

> they are an implicit side-channel treated in the type system like an afterthought an

Non-specific criticism. If your complaint is that exceptions don't appear in function signatures, you can design a language in which they do. The mechanism is called "checked exceptions"

Amazing to me that the same people will laud Result because it lifts errors into signatures in Rust but hate checked exceptions because they lift errors into signatures in Java.

Besides, in the real world, junior Rust programmers (and some senior ones who should be ashamed of themselves) just .unwrap().unwrap().unwrap(). I can abort on error in C too, LOL.

I think that’s misdirected but illustrates the emotional reasons why people develop a negative impression of the concept. Usually it means someone had bad experiences with code written in a poor culture of error handling (e.g. certain Java frameworks) and generalized it to “exceptions are bad” rather than recognizing that error handling isn’t trivial and many programmers don’t take it seriously enough, regardless of the paradigm. As a simple example, C and PHP code have had many, many security and correctness issues caused by _not_ having errors interrupt program execution where the users would have been much better off had the program simply halted on the first unhandled error.

If you write complex programs with lots of mutable shared state, yes, it’s hard to reason about error recovery but that’s misattributing the problem to the mechanism which surfaced the error rather than the fact that their program’s architecture makes it hard to rollback or recover.

I am a professional programmer. Have been one for more than two decades. And perhaps for professionalism, I think there is no space for passion when it comes to choosing the tools of the trade. Passion would make me pick unsuitable tools because well, I would be passionate. Passionate people don't tend to make rational decisions.

I would expect a professional carpenter to be the same. They may have preferences due to familiarity, positive experiences, etc and so forth. But passion?