Why Go and Not Rust? (2019)
A rarely covered topic in these discussions is architectural benefits that Go provides.<p>Rust tends to solve problems by adding more constraints, which often leads to more complexity. It&#x27;s great when that complexity is inherent (like with static typing), but quite painful when the complexity is artificial&#x2F;incidental. In the domains I work in, the healthier approach is usually to decouple more, rather than add more constraints.<p>For example, in Rust, we often have to use an index or an ID where a regular reference would do in Go. We need to do extra refactoring of function signatures to pass collections down the call stack so we can then use that index&#x2F;ID... and then find we can&#x27;t modify a function signature because it&#x27;s a trait override, and resort to tricky workarounds. In Go, we just use a reference. That choice is decoupled from memory concerns.<p>Another example is that in Rust, we often need to refactor to add `async` keywords to callers (and their callers) and run into the same problem. Go decouples all that coloring away.<p>Another example is how Go interfaces are structural, which further decouples a caller from a callee.<p>Hillel Wayne had a stellar article on how constraints lead to complexity: <a href="https:&#x2F;&#x2F;www.hillelwayne.com&#x2F;post&#x2F;complexity-constraints&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.hillelwayne.com&#x2F;post&#x2F;complexity-constraints&#x2F;</a><p>Go is designed to decouple away details that are unimportant for the vast majority of domains. That means a codebase can change faster, require less refactoring, and generally be healthier in an architectural sense.<p>That isn&#x27;t saying that Rust is bad. It&#x27;s amazing for embedded programming, it&#x27;s much faster for some domains, and it doesn&#x27;t have some of Go&#x27;s other nonsense like nil and how their defer isn&#x27;t block-scoped. But one can&#x27;t discount Go&#x27;s architectural benefits, especially when starting a new project that will be worked on by a large team.<p>Just my two cents, reasonable opinions may differ =)