diff --git a/doc/go_faq.html b/doc/go_faq.html index 5f92b0528a6..953092f051d 100644 --- a/doc/go_faq.html +++ b/doc/go_faq.html @@ -26,6 +26,7 @@ are not well supported by popular systems languages.
  • The emergence of multicore computers has generated worry and confusion. +

    We believe it's worth trying again with a new language, a concurrent, @@ -49,12 +50,14 @@ concurrent execution and communication. By its design, Go proposes an approach for the construction of system software on multicore machines. +

    What is the origin of the name?

    “Ogle” would be a good name for a Go debugger. +

    What's the origin of the mascot?

    @@ -83,6 +86,7 @@ http://plan9.bell-labs.com/sys/doc/compiler.html 6 is the architecture letter for amd64 (or x86-64, if you prefer), while g stands for Go. +

    What is the history of the project?

    @@ -104,7 +108,6 @@ and libraries from prototype to reality. Many others have contributed ideas, discussions, and code.

    -

    Why are you creating a new language?

    @@ -117,6 +120,7 @@ language. Programmers who could were choosing ease over safety and efficiency by moving to dynamically typed 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 an interpreted, dynamically typed @@ -131,7 +135,6 @@ and so on. These cannot be addressed well by libraries or tools; a new language was called for.

    -

    What are Go's ancestors?

    @@ -147,7 +150,6 @@ about what programmers do and how to make programming, at least the kind of programming we do, more effective, which means more fun.

    -

    What are the guiding principles in the design?

    @@ -179,7 +181,6 @@ interfaces represent abstraction; and so on. Orthogonality makes it easier to understand what happens when things combine.

    -

    Usage

    @@ -190,15 +191,17 @@ Go is an experiment. We hope adventurous users will give it a try and see if they enjoy it. Not every programmer will, but we hope enough will find satisfaction in the approach it offers to justify further development. +

    Is Google using Go internally?

    -

    Yes. There are now several Go programs deployed in +

    +Yes. There are now several Go programs deployed in production inside Google. For instance, the server behind http://golang.org is a Go program; in fact it's just the godoc document server running in a production configuration. - +

    @@ -211,11 +214,14 @@ 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. +

    The cgo program provides the mechanism for a “foreign function interface” to allow safe calling of C libraries from Go code. SWIG extends this capability to C++ libraries. +

    +

    Does Go support Google's protocol buffers?

    @@ -226,6 +232,7 @@ It is available at http://code.google.com/p/goprotobuf/

    +

    Can I translate the Go home page into another language?

    @@ -277,11 +284,13 @@ 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. +

    If it bothers you that Go is missing feature X, please forgive us and investigate the features that Go does have. You might find that they compensate in interesting ways for the lack of X. +

    Why does Go not have generic types?

    @@ -289,6 +298,7 @@ Why does Go not have generic types? Generics may well be added 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 @@ -298,6 +308,7 @@ 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.

    @@ -311,6 +322,7 @@ convoluted code. It also tends to encourage programmers to label too many ordinary errors, such as failing to open a file, as exceptional.

    +

    Go takes a different approach. Instead of exceptions, it has a couple of built-in functions to signal and recover from truly exceptional @@ -319,11 +331,11 @@ function's state being torn down after an error, which is sufficient to handle catastrophe but requires no extra control structures and, when used well, can result in clean error-handling code.

    +

    See the Defer, Panic, and Recover article for details.

    -

    Why does Go not have assertions?

    @@ -336,6 +348,7 @@ 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 @@ -348,17 +361,20 @@ answer for 2 and therefore no more tests were run. The programmer who triggers the test failure may not be familiar with the code that fails. 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. 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 sometimes worth trying a different approach. +

    Why build concurrency on the ideas of CSP?

    @@ -370,6 +386,7 @@ such as mutexes, condition variables, and even memory barriers. Higher-level interfaces enable much simpler code, even if there are still mutexes and such under the covers.

    +

    One of the most successful models for providing high-level linguistic support for concurrency comes from Hoare's Communicating Sequential Processes, or CSP. @@ -392,6 +409,7 @@ The result, which we call goroutines, can be very cheap: unless they spend a lot in long-running system calls, they cost little more than the memory for the stack.

    +

    To make the stacks small, Go's run-time uses segmented stacks. A newly minted goroutine is given a few kilobytes, which is almost always enough. @@ -420,7 +438,6 @@ as when hosting an untrusted program, the implementation could interlock map access.

    -

    Types

    @@ -435,10 +452,12 @@ also ways to embed types in other types to provide something analogous—but not identical—to subclassing. Moreover, methods in Go are more general than in C++ or Java: they can be defined for any sort of data, not just structs. +

    Also, the lack of type hierarchy makes “objects” in Go feel much more lightweight than in languages such as C++ or Java. +

    How do I get dynamic dispatch of methods?

    @@ -446,6 +465,7 @@ 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. +

    Why is there no type inheritance?

    @@ -455,6 +475,7 @@ involves too much discussion of the relationships between types, relationships that often could be derived automatically. Go takes a different approach.

    +

    Rather than requiring the programmer to declare ahead of time that two types are related, in Go a type automatically satisfies any interface @@ -469,6 +490,7 @@ or for testing—without annotating the original types. Because there are no explicit relationships between types and interfaces, there is no type hierarchy to manage or discuss.

    +

    It's possible to use these ideas to construct something analogous to type-safe Unix pipes. For instance, see how fmt.Fprintf @@ -479,6 +501,7 @@ stream ciphers. All these ideas stem from a single interface (io.Writer) representing a single method (Write). And that's only scratching the surface.

    +

    It takes some getting used to but this implicit style of type dependency is one of the most exciting things about Go. @@ -503,6 +526,7 @@ but that it could also be confusing and fragile in practice. Matching only by n and requiring consistency in the types was a major simplifying decision in Go's type system.

    +

    Regarding operator overloading, it seems more a convenience than an absolute requirement. Again, things are simpler without it. @@ -574,7 +598,6 @@ the interface idea. Sometimes, though, they're necessary to resolve ambiguities among similar interfaces.

    -

    Values

    @@ -592,6 +615,7 @@ The definition of constants in Go—arbitrary precision values free of signedness and size annotations—ameliorates matters considerably, though.

    +

    A related detail is that, unlike in C, int and int64 are distinct types even if int is a 64-bit type. The int @@ -610,7 +634,6 @@ If a specific application can benefit from a custom implementation, it's possibl to write one but it will not be as convenient syntactically; this seems a reasonable tradeoff.

    -

    Why don't maps allow structs and arrays as keys?

    @@ -637,7 +660,6 @@ language but they have a large effect on usability: Go became a more productive, comfortable language when they were introduced.

    -

    Writing Code

    @@ -650,6 +672,7 @@ command line or on the web. An instance is running at http://golang.org/pkg/. In fact, godoc implements the full site at http://golang.org/. +

    Is there a Go programming style guide?

    @@ -663,6 +686,7 @@ More directly, the program gofmt is a pretty-printer whose purpose is to enforce layout rules; it replaces the usual compendium of do's and don'ts that allows interpretation. All the Go code in the repository has been run through gofmt. +

    How do I submit patches to the Go libraries?

    @@ -670,12 +694,13 @@ How do I submit patches to the Go libraries?

    The library sources are in go/src/pkg. If you want to make a significant change, please discuss on the mailing list before embarking. +

    See the document Contributing to the Go project for more information about how to proceed. - +

    Pointers and Allocation

    @@ -751,6 +776,7 @@ From a correctness standpoint, you don't need to know. Each variable in Go exists as long as there are references to it. The storage location chosen by the implementation is irrelevant to the semantics of the language. +

    The storage location does have an effect on writing efficient programs. @@ -759,11 +785,13 @@ local to a function in that function's stack frame. However, if the compiler cannot prove that the variable is not referenced after the function returns, then the compiler must allocate the variable on the garbage-collected heap to avoid dangling pointer errors. +

    In the current compilers, the analysis is crude: if a variable has its address taken, that variable is allocated on the heap. We are working to improve this analysis so that more data is kept on the stack. +

    Concurrency

    @@ -830,7 +858,6 @@ should recognize such cases and optimize its use of OS threads. For now, GOMAXPROCS should be set on a per-application basis.

    -

    Functions and Methods

    @@ -994,6 +1021,7 @@ standard GCC back end. Gc is written in C using 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 @@ -1003,10 +1031,12 @@ set up a Go environment. Gccgo, which came later, makes it possible consider writing a compiler 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 run-time support implemented?

    @@ -1021,6 +1051,7 @@ compiled with a version of the Plan 9 C compiler that supports segmented stacks for goroutines. Work is underway to provide the same stack management in gccgo. +

    Why is my trivial program such a large binary?

    @@ -1030,12 +1061,14 @@ The gc tool chain (5l, 6l, and 8l) only generate statically linked binaries. All Go binaries therefore include the Go run-time, along with the run-time type information necessary to support dynamic type checks, reflection, and even panic-time stack traces. +

    A trivial C "hello, world" program compiled and linked statically using gcc on Linux is around 750 kB. An equivalent Go program is around 1.1 MB, but that includes more powerful run-time support. We believe that with some effort the size of Go binaries can be reduced. +

    Performance

    @@ -1070,7 +1103,6 @@ isn't fast enough yet (even if it were, taking care not to generate unnecessary garbage can have a huge effect).

    -

    Changes from C

    @@ -1169,6 +1201,7 @@ This works very well in practice but has the effect that it forces a brace style. For instance, the opening brace of a function cannot appear on a line by itself.

    +

    Some have argued that the lexer should do lookahead to permit the brace to live on the next line. We disagree. Since Go code is meant @@ -1195,6 +1228,7 @@ implement it with low enough overhead and no significant latency. (The current implementation is a plain mark-and-sweep collector but a replacement is in the works.)

    +

    Another point is that a large part of the difficulty of concurrent and multi-threaded programming is memory management; @@ -1205,8 +1239,8 @@ Of course, implementing garbage collection in a concurrent environment is itself a challenge, but meeting it once rather than in every program helps everyone.

    +

    Finally, concurrency aside, garbage collection makes interfaces simpler because they don't need to specify how memory is managed across them.

    -