From 3227445b75044cb94649e55b75e12656ca93f2d6 Mon Sep 17 00:00:00 2001 From: Russ Cox Date: Thu, 22 Oct 2009 00:13:51 -0700 Subject: [PATCH] add FAQ R=r DELTA=13 (0 added, 8 deleted, 5 changed) OCL=35985 CL=35987 --- doc/go_faq.html | 348 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 348 insertions(+) create mode 100644 doc/go_faq.html diff --git a/doc/go_faq.html b/doc/go_faq.html new file mode 100644 index 00000000000..a44a35be8f7 --- /dev/null +++ b/doc/go_faq.html @@ -0,0 +1,348 @@ + + +

Origins

+ +

+What is the purpose of the project?

+ +

+No major systems language has emerged in over a decade, but over that time +the computing landscape has changed tremendously. There are several trends: + +

+ +

+We believe it's worth trying again with a new language, a concurrent, +garbage-collected language with fast compilation. Regarding the points above: + +

+ +

+What is the origin of the name?

+ +

+"Ogle" would be a good name for a Go debugger. + +

Why is the compiler called 6g?

+ +

+The 6g (and 8g) compiler is named in the +tradition of the Plan 9 C compilers, described in + +http://plan9.bell-labs.com/sys/doc/compiler.html +(see the table in section 2). + +6 is the architecture letter for amd64 (or x86-64, if you prefer). +g stands for go. + +

+Why not just write some libraries for C++ to do communication?

+ +

We considered doing that, but too many of the problems—lack of +garbage collection, long dependency chains, nested include files, +lack of concurrency awareness—are caused by the C++ language itself. +We felt a viable solution required a more complete approach. + +

Usage

+ +

+Who do you expect to use the language?

+ +

+Go is an experiment. We hope adventurous users will give it a try and see +if it provides a viable alternative to the status quo. Not every programmer +will like it but we hope enough will find satisfaction in the approach it +offers to justify further development. + +

+ +

+There are two Go compilers, 6g and gccgo. +6g uses a different calling convention and linker and can +therefore only be linked with C programs using the same convention. +There is such a C compiler but no C++ compiler. Gccgo is a +gcc front-end that can, with care, be linked with gcc-compiled +C or C++ programs. However, because Go is garbage-collected it will be +unwise to do so, at least naively. + +

+Work is underway to provide a 'foreign function interface' to allow safe +interoperation of languages in a running program. + +

+Does Go support protocol buffers?

+ +

+Protocol buffers are supported. The next release of the +protocol compiler project will include Go code generators +and a Go library for them. +It is still being tweaked but works well. + +

Design

+ +

Why doesn't Go have feature X?

+ +

+Every language contains novel features and omits someone's favorite +feature. Go was designed with an eye on felicity of programming, speed of +compilation, orthogonality of concepts, and the need to support features +such as concurrency and garbage collection. Your favorite feature may be +missing because it doesn't fit, because it affects compilation speed or +clarity of design, or because it would make the fundamental system model +too difficult. + +

+Before you get too worried about Go not having feature X, +please investigate the features that Go does have. You might find that +they compensate in interesting ways for the lack of X. + +

+Why is the syntax so different from C++?

+ +

+This and other language design questions are answered in +the separate language FAQ. + +

+Object-Oriented Programming

+ +

+Is Go an object-oriented language?

+ +

+Yes and no. Although Go has types and methods and allows an +object-oriented style of programming, there is no type hierarchy. +The concept of "interface" in Go provides a different approach that +we believe is easy to use and in some ways more general. There are +also ways to embed types in other types to provide something +analogous—but not identical—to subclassing. + +

+The lack of type hierarchy makes "objects" in Go feel much more +lightweight than in languages such as C++ and Java. + +

+How do I get dynamic dispatch of methods?

+ +

+The only way to have dynamically dispatched methods is through an +interface. Methods on structs or other types are always resolved statically. + +

Concurency

+ +

+What operations are atomic? What about mutexes?

+ +

+We haven't fully defined it all yet, but some details are available in the +Go Memory Model specification. + +

+One point that has come up: at least for now, maps do not guarantee atomic +update from multiple threads of execution. This is not the place for a +full discussion but in essence it was felt that shared maps are usually +part of some larger synchronized object and forcing synchronization in the +map implementation would be too costly considering how rarely it would +actually help. + +

+The sync +package implements mutexes, but we hope Go programming style will +encourage people to try higher-level techniques. In particular, consider +structuring your program so that only one goroutine at a time is ever +responsible for a particular piece of data. + +

+Do not communicate by sharing memory. Instead, share memory by communicating. + +

Writing Code

+ +

+How are libraries documented?

+ +

+There is a program, godoc, written in Go, that extracts +package documentation from the source code. It can be used on the +command line or on the web. An instance is running at +http://go/go. + + +

+Is there a Go programming style guide?

+ +

+Eventually, there will be a small number of rules that guide things +like naming, layout, and file organization. We are thinking of +enforcing layout rules using a pretty-printing program that +implements the rules, rather than writing a compendium of do's and +don'ts that allows interpretation. + +

+How do I submit patches to the Go libraries?

+ +
    +
  1. If it's a significant change, discuss on the mailing list before embarking. + +
  2. Check out the Go source code files. The library sources are in go/src/pkg. + +
  3. Make changes; add tests as appropriate. Try to follow existing style, + including tabs for indentation, and no trailing whitespace. In + documentation comments for public declarations, use full sentences + and begin with the name of the thing being described, because godoc + (or other tools) may someday display these comments out of context. + +
  4. Write the Makefile by following existing examples. + +
  5. Run make and make test in the affected + directories. + +
  6. If you have added a new dependency, you may need to cd go/src/lib; + ./deps.bash to update the Make.deps file included in the Makefile. + For a new component, update the Makefile and then run + deps.bash. +
  7. cd go/src; ./all.bash + +
  8. Once all.bash succeeds (output like + "N known bugs; 0 unexpected bugs" is OK), + submit a CL. +
+ +

+How do I create a multifile package?

+ +

+Put all the source files for the package in a directory by themselves. +Source files can refer to items from different files at will; there is +no header file or need for forward declarations. + +

+Other than being split into multiple files, the package will compile and test +just like a single-file package. + +

+How do I write a unit test?

+ +

+Create a new file ending in _test.go in the same directory +as your package sources. Inside that file, import "testing" +and write functions of the form + +

+func TestFoo(t *testing.T) {
+    ...
+}
+
+ +

+Run gotest in that directory. +That script finds the Test functions, +builds a test binary, and runs it. + +

+Where is assert?

+ +

+Go doesn't provide assertions. They are undeniably convenient, but our +experience has been that programmers use them as a crutch to avoid thinking +about proper error handling and reporting. Proper error handling means that +servers continue operation after non-fatal errors instead of crashing. +Proper error reporting means that errors are direct and to the point, +saving the programmer from interpreting a large crash trace. Precise +errors are particularly important when the programmer seeing the errors is +not familiar with the code. + +

+The same arguments apply to the use of assert() in test programs. Proper +error handling means letting other tests run after one has failed, so +that the person debugging the failure gets a complete picture of what is +wrong. It is more useful for a test to report that +isPrime gives the wrong answer for 2, 3, 5, and 7 (or for +2, 4, 8, and 16) than to report that isPrime gives the wrong +answer for 2 and therefore no more tests were run. The programmer who +triggers the test failure may be someone editing the code months later +or even someone editing a different package on which the code depends. +Time invested writing a good error message now pays off later when the +test breaks. + +

+In testing, if the amount of extra code required to write +good errors seems repetitive and overwhelming, it might work better as a +table-driven test instead. Unlike Java (jUnit's home language), +Go has excellent support for data structure literals. + +

+We understand that this is a point of contention. There are many things in +the Go language and libraries that differ from modern practices, simply +because we feel it's worth trying to do better. + +

Implementation

+ +

+What compiler technology is used to build the compilers?

+ +

+Gccgo has a C++ front-end with a recursive descent parser coupled to the +standard gcc back end. 6g is written in C using yacc/bison for the parser. +Although it's a new program, it fits in the Plan 9 C compiler suite +(http://plan9.bell-labs.com/sys/doc/compiler.html) +and uses a variant of the Plan 9 loader to generate ELF binaries. + +

+We considered writing 6g, the original Go compiler, in Go itself but +elected not to do so because of the difficulties of bootstrapping and +especially of open source distribution - you'd need a Go compiler to +set up a Go environment. Gccgo, which came later, makes it possible to +consider rewriting 6g in Go, which might well happen. (Go would be a +fine language in which to implement a compiler; a native lexer and +parser are already available in pkg/go.) + +

+We also considered using LLVM for 6g but we felt it was too large and +slow to meet our performance goals. + +

+How is the runtime implemented?

+ +

+Again due to bootstrapping issues, the runtime is mostly in C (with a +tiny bit of assembler) although Go is capable of implementing most of +it now. Gccgo's runtime uses glibc; 6g uses a custom library, +compiled with 6c (the Plan 9 C compiler) to keep the footprint under +control. The version of 6c used supports segmented stacks for +goroutines; work is underway to provide the same stack management in +gccgo.