Go Home Page The Go Programming Language

The Go Programming Language Design FAQ

Why are you creating a new language?

TODO

What is the history of the project?

TODO

What are Go's ancestors?

Go is in the C family, but also borrows some ideas from CSP-inspired languages such as Newsqueak and Limbo. The interface idea may be related to other languages but was designed in isolation; ditto packages. 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.

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 has 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.

TODO

TODO:

Why does Go not have:
- assertions
- exceptions
- generic types

What do you have planned?
- variant types?

explain:
package designa
slices
oo separate from storage (abstraction vs. implementation)
goroutines
why garbage collection?



no data in interfaces

concurrency questions:
	why aren't maps atomic
	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