Lies we tell ourselves to keep using Golang
As people have remarked, Amos&#x27;s style can be grating and hyperbolic. That doesn&#x27;t make a lot of his complaints about Go as a language incorrect.<p>I do think he&#x27;s misunderstanding that the design intent is &quot;networked C&quot; and that Go + Protobuf is much better than he thinks. A lot of his complaints with the language and runtime boil down to:<p>- It&#x27;s got a primitive type system (yep, nobody disagrees)<p>- It leaves a lot of problems to you (yep, just like C)<p>- you can&#x27;t integrate it into existing binaries (yep, distributed systems connected by RPC)<p>He comes to terms with the last one and admits it, but it is not only the thing Go is good at but it was the <i>design intent</i>. If you start from &quot;we want a language and runtime for writing distributed systems that would otherwise be written in C or Java&quot; then Go is pretty good!<p>I&#x27;m a happy Go, Rust, C, and C++ person. They&#x27;re each for different things. That Rust worked out (is working out?) despite being an incredibly powerful and complex language (compared to C) is awesome. In the mid-2000s, it&#x27;s not clear that you&#x27;d bet on a language like Rust. It is clear you could do better than Java or C++ for distributed systems programming, and Go hit that pretty reasonably (I do wish the language had a better type system, and I&#x27;m glad to see Ian finally land generics, but I&#x27;d absolutely reach for Rust when writing code in a small group that can handle the &quot;language complexity&quot; in exchange for the benefits).