From 320406d15563233ea09a1717db074385924285af Mon Sep 17 00:00:00 2001 From: Rob Pike Date: Mon, 28 Sep 2009 14:37:14 -0700 Subject: [PATCH] start of a language design FAQ. R=rsc DELTA=224 (214 added, 10 deleted, 0 changed) OCL=35041 CL=35050 --- doc/go_lang_faq.html | 213 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 213 insertions(+) create mode 100644 doc/go_lang_faq.html diff --git a/doc/go_lang_faq.html b/doc/go_lang_faq.html new file mode 100644 index 0000000000..9e4385e1a9 --- /dev/null +++ b/doc/go_lang_faq.html @@ -0,0 +1,213 @@ + + + + + + The Go Programming Language Design FAQ + + + + + + + + +
+ + + + +
+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
+
+ + +
+ + + + + -- 2.48.1