Go’s Concurrency in Conversation

I recently came across an interesting pair of articles regarding Go's concurrency model. Together, they constitute a dialogue or conversation about the nature of the language.

The first is a post on Uber's engineering blog describing their experience adopting the Go programming language, as well as the challenges they encountered. In particular, they contend that Go's implementation of concurrency is inherently susceptible to data races.

There's a lot of information in the article - the authors describe how they searched approximately 50 million lines of code, and they provide detailed examples of the issues they discovered. They conclude that these issues result from design choices within the Go language. The challenges of working at Uber's scale - particularly with the massive codebases that go along with it - are always interesting to read about, and for this reason alone I think this article is worth your time.

The second piece is a specific response to Uber by Scott White. White is a director of software engineering and experienced Go developer, and he challenges the Uber team's contention that their issues are Go's fault. He dives deeply into the examples given by Uber, but reaches different conclusion. In particular, he argues that the examples and issues Uber highlights result from needlessly complicated code - a contravention of Go's spirit of simplicity - and that Uber failed to follow a validated concurrency pattern. As White sees it, rather than an issue with Go, the problem lies with the way Uber used the language.

I'm still processing the substance of this exchange, but a few things stand out:

• This difference in views may be product of the different situations of the authors. Uber probably has a large number of developers with differing levels of experience in Go - some may be new to the language, with habits picked up elsewhere. By contrast, White is an experienced Go developer, overseeing a smaller team, and a smaller codebase; as such, there is likely greater oversight and mentorship.
• A lot of White's critique is based in arguments over best coding practices. I find this ironic, since Go's simplicity was supposed to make this a nonissue. Even if White is right, and the issue is with the specific code rather than the language, Uber's original critique might still be right in a way - you could argue that Go is flawed in that it allows developers to write code that causes these kind of issue. This is a stretch, however, and I don't think it's particularly fair. Perhaps there are inherent limits to what can be accomplished with language design, and there will always be some responsibility on the developer.

I think the most important takeaway from all this doesn't have anything to do with the this specific issue. Rather, it serves as a caution against infallibility. In the developer ecosystem, company tech blogs are an especially important source of knowledge, and those from the giants are generally considered the most authoritative. After all, the largest tech companies have the greatest resources, the largest teams, and presumably the best talent. It is therefore tempting to consider publications or pronouncements from engineers at these companies to be the ultimate truth.

However, the dialectic between these two articles suggests that this assumption is not always true. Even the biggest, most prestigious tech teams aren't always right, and it's on the reader to exercise their own judgment in addition.