We Already Have Go 2

In many ways it's really a meta-rant on the criticism's he's received about his first article. And where it's not, it is mostly just re-litigating the same arguments he made previously, which could be summed up as "Go is not Rust". "Go doesn't have sum types", "no immutable types", "no operator overloading", etc. Yes, Go is not Rust. It's also not Java, or Lisp, or C.

Rust and Go have very different language models with very different design goals:

Go was designed to be a very simple language to understand and develop in where reasoning about the program is very easy. The language spec can be read and understood in under a day, and programmers can be reasonably proficient in a week. It was designed to be a system language at Google, where there are lots of smart developers that may know how to code but may not know one of Google's "Big Four" languages (Java, C++, Python, and now Go). Many of the design trade-offs were made to specifically address common code problems found in both the Google and the various Bell Labs code-bases. (Pike and Thompson both worked at Bell Labs before Google.) For example, the lack of operating overloading in Go was not an oversight, it was an explicit design decision arrived at through looking at millions and millions of lines of code: operator overloading is frequently misused and creates subtle, difficult to debug errors.

Rust, on the other hand is a very difficult language to learn and master: the borrow-checker is a harsh mistress, and learning the memory model takes time, practice, and significant cognitive load. The reward for climbing that steep learning curve is the resulting code should be easy to reason about and be very safe. But, Rust code can be inscrutable and have errors and security problems, too, it's just much harder to do than it is in many other languages.

Which one is right? Depends on your goals. Go allows you to solve problems quickly and onboard developers very quickly. Rust requires much longer developer onboarding but provides strong safety guarantees. Both have their place.

Ultimately, the author is arguing in bad faith. There is no objective assessment of the two languages' strengths and weaknesses. And he points out sharp edges in Go--some of which are contrived examples that are explicitly antagonistic to the language design--without acknowledging that Rust is anything less than perfect.

And some of the examples he gives are valid, but are not the indictment that he claims. For example, the Tailscale netaddr.IP article shows that while the design of Go's standard library implementation of the network address type has a number of design issues when used at very large scale. But it also shows that it's possible to create a set of types that satisfies even Tailscale's production demands.

Go has limitations and some sharp edges, but so does every language, especially when used in ways that go against the language design. That doesn't make Go the useless, idiosyncratic development tool that his titles and prose imply.