Go vs Rust: A Developer's Perspective

A developer with extensive experience in Rust recently transitioned to using Go for industrial development. While the initial learning curve for Go was described as manageable, the practical application over an extended period revealed significant differences. The author identified that Go lacks flexibility in certain areas compared to Rust and presents opportunities for developers to make critical mistakes.

Following nearly 18 months of production work with Go, the author compiled a list of specific grievances. These observations are framed as a comparison for developers considering a move from Rust or similar languages. The core argument is that while Go is functional, it may not offer the same safety or expressiveness that Rust developers are accustomed to.

The shift from Rust to Go was driven by professional requirements rather than personal preference. The author notes that prior familiarity with Go was superficial at best, with the majority of their coding career spent in Rust. Despite the lack of deep prior knowledge, the process of learning Go was not considered difficult. However, the transition became complicated once actual development work began.

Once the team started building software, unpleasant moments began to surface. The author observed that the language design choices in Go sometimes restrict the developer's ability to express complex logic the way they might in Rust. This lack of flexibility became a primary source of frustration during the development cycle.

Working in a production environment highlighted the practical differences between the two languages. The author mentions that Go contains specific patterns or features that allow developers to shoot themselves in the foot. This suggests that Go offers fewer safety rails compared to Rust, which is known for its strict compile-time checks.

After spending almost a year and a half in industrial development using Go, the author felt compelled to document these issues. The goal is to provide a resource for others who might face similar hurdles when moving between these two distinct programming ecosystems.

The comparison is explicitly framed around the author's primary language, Rust. The article serves as a critique of Go through the lens of a Rust developer. The author intends to list specific moments or features in Go that cause pain, without a strict order of severity. This approach allows for a broad overview of the language's shortcomings from a specific technical perspective.

By focusing on the lack of flexibility and the potential for errors, the article highlights the trade-offs between the two languages. It suggests that while Go may be easier to learn, it might require more vigilance to maintain the safety standards expected by developers coming from a Rust background.