Go’s Language Design Leaves Others Behind
Seismic changes in the world of computing and software design in the last few years have meant programming languages have had to evolve as well. The need for simplicity in programming languages emerged as a core theme during this year’s GopherCon India. We’ve already heard a few developers explain why they’ve switched to Go. Here, Sydney, Australia-based programmer, author and Go contributor Dave Cheney provides some insights into the genesis of Go, and why it is the programming language for these rapidly changing times.
Cheney notes most contemporary languages start out simple, then “settle” for being merely “powerful.” He believes complex languages’ inherent “clumsy syntax [and] non-orthogonality” is glossed over by euphemistic rationalizations that these languages are powerfully expressive, rather than truthfully admitting they fail to be simple and straightforward.
In terms of language design, Cheney points out there must be trade-offs. Most languages are launched idealistically with the goal of being simple, but many fail because they succumb to the idea they must also include the same features and successes as their predecessors. He sees this as the stumbling block new languages face — the pressure that they become a “superset of [the languages] they seek to replace” — which results in the “baroque,” needlessly complex languages we now see littering the landscape.
He believes a new language should be a refinement, not a mere replacement, that learns from the mistakes of its forebears.
Cheney explains how and why Go is different from previous languages. First, it does away with the conventions that other languages have gotten programmers accustomed to — conventions that are not absolutely necessary. Go’s success is due inasmuch to what has been left out, as to what has been added in. Secondly, Go allows programmers to build solid foundations. Cheney uses the analogy of a large structure built on shifting sands, “masking decades of accumulated debris,” likening it to large programs that have been built on cumbersome languages that are neither simple nor solid.
“You cannot add simplicity after the fact,” he cautions. “Simplicity is only gained by taking things away.”
Making a comprehensible language doesn’t mean making it easy; rather, it means keeping it straightforward. Cheney cites the example of keeping a language simple by limiting the number of semantic conveniences available to experienced programmers, which will also avoid alienating newcomers.
Cheney believes today’s need for simplicity in programming is self-evident, and recalls the story of how Go was created. Rob Pike, one of Go’s co-creators, saw it as a language that “wasn’t designed by committee. [It] represented a distillation of the experiences of Ken Thompson, Robert Griesemer and himself” — all experienced programmers who all agreed there would be no “extraneous garbage” in Go. Go is designed to be simple; simplicity is one of its primary features, rather than being a byproduct.
In the area of collaboration, Cheney poses the rhetorical question of whether programming is an art or a science. He states programming professionals must often work as a team, and so Go was made to co-exist in a larger environment, addressing the problems that exist in commercial programming today. He says “Go is a small language, but it is deliberately designed to handle large teams of programmers. The lack of warnings, refusal to allow unused inputs and refusal to allow unused local variables are all facets of choices designed to help Go work for big teams.”
The relative ambiguity of other languages whose source code must be “decoded” to understand the program’s intent is addressed with Go’s regularity of grammar. It’s true that Go’s simplicity may provide fewer opportunities for individual expression; however, this makes it easier to determine its function. Go is designed to be transposed, transformed and processed, which opens up new forms of analysis and code generation that can be used in the wider community. Since Go is a language for collaboration, features such as Go’s format (gofmt) help to moderate code, ensuring it sticks to accepted conventions, so it can be easily read and understood.
Cheney observes that Go subscribes to the UNIX philosophy of universality by using “simple, sharp tools which combine together to solve more complex tasks. More importantly, [these are] tasks that were never envisaged by their original authors.” Go’s packages interact with one another using common interfaces that are simpler, less restrictive, can be implicitly satisfied, yet are more powerful and more composable, compared to other languages like Java or C++, leading to simpler implementations.
Cheney discusses Go’s strengths in its error handling and its simple approach to integrating dependencies. He explains how Go has assumed a strong position in the container orchestration market, thanks to specific design decisions that take into account the software design lifecycle, as well as the deployment phase. Cheney believes we are at the cusp of a “renaissance of command lines,” driven by the “rediscovery of languages that produce compiled, self-contained programs, enabling programmers to develop simple programs that fit together, cross-platform,” in the cloud. Ultimately, he believes Go leads the pack, remarking that, after all,
“Go is a language for programmers who want to get things done.”