The Go Programming Language Design FAQ
Origins
What is the history of the project?
Robert Griesemer, Rob Pike and Ken Thompson started sketching the goals for a new language on the white board on September 21, 2007. Within a few days the goals had settled into a plan to do something and a fair idea of what it would be. Design continued part-time in parallel with unrelated activities. By January 2008, Ken started work on a compiler with which to explore ideas; it generated C code as its output. By mid-year the language had become a full-time project and had settled enough to attempt a production compiler. Meanwhile, Ian Taylor had read the draft specification and written an independent GCC front end.
In the last few months of 2008, Russ Cox joined the team and Go had reached the point where it was usable as the main programming language for the team's own work.
Why are you creating a new language?
Go was born out of frustration with existing languages and environments for systems programming. Programming had become too difficult and the choice of languages was partly to blame. One had to choose either efficient compilation, efficient execution, or ease of programming; all three were not available in the same commonly available language. Programmers who could were choosing ease over safety and efficiency by moving to dynamic languages such as Python and JavaScript rather than C++ or, to a lesser extent, Java.
Go is an attempt to combine the ease of programming of the dynamic languages with the efficiency and type safety of a compiled language. It also aims to be modern, with support for networked and multicore computing. Finally, it is intended to be fast: it should take at most a few seconds to build a large executable on a single computer. To meet these goals required addressing a number of linguistic issues: an expressive but lightweight type system; concurrency and garbage collection; rigid dependency specification; and so on. These cannot be addressed well by libraries or tools; a new language was called for.
What are Go's ancestors?
Go is mostly in the C family (basic syntax), with significant input from the Pascal/Modula/Oberon family (declarations, packages), plus it borrows some ideas from languages inspired by Tony Hoare's CSP, such as Newsqueak and Limbo (concurrency). However, it is a new language across the board. In every respect the language was designed by thinking about what programmers do and how to make programming, at least the kind of programming we do, more effective, which means more fun.
Who are the protagonists?
Robert Griesemer, Rob Pike and Ken Thompson laid out the goals and
original specification of the language. Ian Taylor read the draft
specification and decided to write gccgo. Russ
Cox joined later and helped move the language and libraries from
prototype to reality.
Changes from C
Why is the syntax so different from C?
Other than declaration syntax, the differences are not major and stem from two desires. First, the syntax should feel light, without too many mandatory keywords, repetition, or arcana. Second, the language has been designed to be easy to parse. The grammar is conflict-free and can be parsed without a symbol table. This makes it much easier to build tools such as debuggers, dependency analyzers, automated documentation extractors, IDE plug-ins, and so on. C and its descendants are notoriously difficult in this regard but it's not hard to fix things up.
Why are declarations backwards?
They're only backwards if you're used to C. In C, the notion is that a
variable is declared like an expression denoting its type, which is a
nice idea, but the type and expression grammars don't mix very well and
the results can be confusing; consider function pointers. Go mostly
separates expression and type syntax and that simplifies things (using
prefix * for pointers is an exception that proves the rule). In C,
the declaration
int* a, b;
declares a to be a pointer but not b; in Go
var a, b *int;
declares both to be pointers. This is clearer and more regular.
Also, the := short declaration form argues that a full variable
declaration should present the same order as := so
var a uint64 = 1;has the same effect as
a := uint64(1);
Parsing is also simplified by having a distinct grammar for types that
is not just the expression grammar; keywords such as func
and chan keep things clear.
Why is there no pointer arithmetic?
Safety. Without pointer arithmetic it's possible to create a language that can never derive an illegal address that succeeds incorrectly. Compiler and hardware technology have advanced to the point where a loop using array indices can be as efficient as a loop using pointer arithmetic. Also, the lack of pointer arithmetic can simplify the implementation of the garbage collector.
Why are ++ and -- statements and not expressions? And why postfix, not prefix?
Without pointer arithmetic, the convenience value of pre- and postfix
increment operators drops. By removing them from the expression
hierarchy altogether, expression syntax is simplified and the messy
issues around order of evaluation of ++ and --
(consider f(i++) and p[i] = q[++i])
are eliminated as well. The simplification is
significant. As for postfix vs. prefix, either would work fine but
the postfix version is more traditional; insistence on prefix arose
with the STL, part of a language whose name contains, ironically, a
postfix increment.
Absent features
Why does Go not have generic types?
Generics may well come at some point. We don't feel an urgency for them, although we understand some programmers do.
Generics are convenient but they come at a cost in complexity in the type system and run-time. We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it. Meanwhile, Go's built-in maps and slices, plus the ability to use the empty interface to construct containers (with explicit unboxing) mean in many cases it is possible to write code that does what generics would enable, if less smoothly.
This remains an open issue.
Why does Go not have exceptions?
Exceptions are a similar story. A number of designs for exceptions have been proposed but each adds significant complexity to the language and run-time. By their very nature, exceptions span functions and perhaps even goroutines; they have wide-ranging implications. There is also concern about the effect they would have on the libraries. They are, by definition, exceptional yet experience with other languages that support them show they have profound effect on library and interface specification. It would be nice to find a design that allows them to be truly exceptional without encouraging common errors to turn into special control flow requiring every programmer to compensate.
Like generics, exceptions remain an open issue.
Why does Go not have assertions?
This is answered in the general FAQ.
Concurrency
Why are map operations not defined to be atomic?
After long discussion it was decided that the typical use of maps did not require safe access from multiple threads, and in those cases where it did, the map was probably part of some larger data structure or computation that was already synchronized. Therefore making all map operations grab a mutex would slow down most programs and add safety to few. This was not an easy decision, however, since it means uncontrolled map access can crash the program.
The language does not preclude atomic map updates. When required, such as when hosting an untrusted program, the implementation could interlock map access.
TODO
TODO:
Why does Go not have: - macros? - conditional compilation? What do you have planned? - variant types? explain: package design slices oo separate from storage (abstraction vs. implementation) why garbage collection? no data in interfaces concurrency questions: goroutine design why csp inheritance? embedding? dependency declarations in the language oo questions dynamic dispatch clean separation of interface and implementation why no automatic numeric conversions? make vs new Why do maps only work on builtin types?