| ▲ | Mawr a day ago | |
Context for those unaware: This article was a response to a 2022 HN thread [1] about the original article of the author's. Then the following discussion happened: [2]. 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 | ||
| ▲ | sunshowers a day ago | parent [-] | |
Yeah I mean if you care about correctness at scale Rust is basically the only imperative language worth using, due to its separation between mutable and immutable state. I believe having that separation is a fundamental requirement for correctness at scale. I would love to see a simpler language than Rust have that kind of separation, but that doesn't exist at the moment. Not everyone cares about correctness at scale! Python for example is a perfectly fine language to use when getting something out is more important than being correct at scale. A lot of game dev can also live without full correctness because things like player positions can just be fixed up afterwards if there's a bug. But if correctness at scale is a priority, Rust is the only serious imperative option. | ||