| <!-- FAQ --> |
| |
| <h2 id="Origins">Origins</h2> |
| |
| <h3 id="What_is_the_purpose_of_the_project"> |
| What is the purpose of the project?</h3> |
| |
| <p> |
| No major systems language has emerged in over a decade, but over that time |
| the computing landscape has changed tremendously. There are several trends: |
| |
| <ul> |
| <li> |
| Computers are enormously quicker but software development is not faster. |
| <li> |
| Dependency management is a big part of software development today but the |
| “header files” of languages in the C tradition are antithetical to clean |
| dependency analysis—and fast compilation. |
| <li> |
| There is a growing rebellion against cumbersome type systems like those of |
| Java and C++, pushing people towards dynamically typed languages such as |
| Python and JavaScript. |
| <li> |
| Some fundamental concepts such as garbage collection and parallel computation |
| are not well supported by popular systems languages. |
| <li> |
| The emergence of multicore computers has generated worry and confusion. |
| </ul> |
| |
| <p> |
| We believe it's worth trying again with a new language, a concurrent, |
| garbage-collected language with fast compilation. Regarding the points above: |
| |
| <ul> |
| <li> |
| It is possible to compile a large Go program in a few seconds on a single computer. |
| <li> |
| Go provides a model for software construction that makes dependency |
| analysis easy and avoids much of the overhead of C-style include files and |
| libraries. |
| <li> |
| Go's type system has no hierarchy, so no time is spent defining the |
| relationships between types. Also, although Go has static types the language |
| attempts to make types feel lighter weight than in typical OO languages. |
| <li> |
| Go is fully garbage-collected and provides fundamental support for |
| concurrent execution and communication. |
| <li> |
| By its design, Go proposes an approach for the construction of system |
| software on multicore machines. |
| </ul> |
| |
| <h3 id="What_is_the_origin_of_the_name"> |
| What is the origin of the name?</h3> |
| |
| <p> |
| “Ogle” would be a good name for a Go debugger. |
| |
| <h3 id="What_kind_of_a_name_is_6g"> |
| What kind of a name is 6g?</h3> |
| |
| <p> |
| The <code>6g</code> (and <code>8g</code> and <code>5g</code>) compiler is named in the |
| tradition of the Plan 9 C compilers, described in |
| <a href="http://plan9.bell-labs.com/sys/doc/compiler.html"> |
| http://plan9.bell-labs.com/sys/doc/compiler.html</a> |
| (see the table in section 2). |
| |
| <code>6</code> is the architecture letter for amd64 (or x86-64, if you prefer), while |
| <code>g</code> stands for Go. |
| |
| <h3 id="Why_not_just_write_some_libraries_for_Cpp_to_do_communication"> |
| Why not just write some libraries for C++ to do communication?</h3> |
| |
| <p>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 rooted in the design of |
| the C and C++ languages themselves. |
| We felt a viable solution required a more complete approach. |
| |
| <h3 id="Why_doesnt_Go_run_on_Windows"> |
| Why doesn't Go run on Windows?</h3> |
| |
| <p> |
| We understand that a significant fraction of computers in the world |
| run Windows and it would be great if those computers could run Go |
| programs. However, the Go team is small and we don't have the |
| resources to do a Windows port at the moment. We would be |
| more than willing to answer questions and offer advice to anyone |
| willing to develop a Windows version. |
| </p> |
| |
| <h3 id="Whats_the_origin_of_the_mascot"> |
| What's the origin of the mascot?</h3> |
| |
| <p> |
| The mascot and logo were designed by |
| <a href="http://reneefrench.blogspot.com">Renée French</a>, who also designed |
| <a href="http://plan9.bell-labs.com/plan9/glenda.html">Glenda</a>, |
| the Plan 9 bunny. |
| The gopher is derived from one she used for an <a href="http://wfmu.org/">WFMU</a> |
| T-shirt design some years ago. |
| The logo and mascot are covered by the |
| <a href="http://creativecommons.org/licenses/by/3.0/">Creative Commons Attribution 3.0</a> |
| license. |
| </p> |
| |
| <h2 id="Usage">Usage</h2> |
| |
| <h3 id="Who_should_use_the_language"> |
| Who should use the language?</h3> |
| |
| <p> |
| 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. |
| |
| <h3 id="Is_Google_using_go_internally"> Is Google using Go |
| internally?</h3> |
| |
| <p> The Go project was conceived to make it easier to write the kind |
| of servers and other software Google uses internally, but the |
| implementation isn't quite mature enough yet for large-scale |
| production use. While we continue development we are also doing |
| experiments with the language as a candidate server environment. It's |
| getting there. For instance, the server behind <a |
| href="http://golang.org">http://golang.org</a> is a Go program; in |
| fact it's just the <a href="/cmd/godoc"><code>godoc</code></a> document server running in a |
| production configuration. |
| |
| |
| <h3 id="Do_Go_programs_link_with_Cpp_programs"> |
| Do Go programs link with C/C++ programs?</h3> |
| |
| <p> |
| There are two Go compiler implementations, <code>6g</code> and friends, generically called |
| <code>gc</code>, and <code>gccgo</code>. |
| <code>Gc</code> 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. <code>Gccgo</code> 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. |
| |
| <p> |
| There is a “foreign function interface” to allow safe calling of C-written |
| libraries from Go code. We expect to use SWIG to extend this capability |
| to C++ libraries. There is no safe way to call Go code from C or C++ yet. |
| |
| <h3 id="Does_Go_support_Google_protocol_buffers"> |
| Does Go support Google's protocol buffers?</h3> |
| |
| <p> |
| Protocol buffers are supported. We plan to have the next release of the |
| protocol buffer source code include Go code generators |
| and a Go library for them. The implementation uses data reflection |
| at run time so it is slow, but a new implementation is planned. |
| |
| <h3 id="Can_I_translate_the_Go_home_page"> |
| Can I translate the Go home page into another language?</h3> |
| |
| <p> |
| Absolutely. We encourage developers to make Go Language sites in their own languages. |
| However, if choose to add the Google logo or branding to your site |
| (it does not appear on <a href="http://golang.org/">golang.org</a>), |
| you will need to abide by the guidelines at |
| <a href="http://www.google.com/permissions/guidelines.html">http://www.google.com/permissions/guidelines.html</a> |
| </p> |
| |
| <h2 id="Design">Design</h2> |
| |
| <h3 id="Why_doesnt_Go_have_feature_X">Why doesn't Go have feature X?</h3> |
| |
| <p> |
| 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. |
| |
| <p> |
| If it bothers you that Go is missing feature <var>X</var>, |
| please forgive us and investigate the features that Go does have. You might find that |
| they compensate in interesting ways for the lack of <var>X</var>. |
| |
| <h3 id="Why_is_the_syntax_so_different_from_Cpp"> |
| Why is the syntax so different from C++?</h3> |
| |
| <p> |
| This and other language design questions are answered in |
| the separate <a href="go_lang_faq.html">language design FAQ</a>. |
| |
| <h2 id="Object_Oriented_Programming"> |
| Object-Oriented Programming</h2> |
| |
| <h3 id="Is_Go_an_object-oriented_language"> |
| Is Go an object-oriented language?</h3> |
| |
| <p> |
| 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. |
| Moreover, methods in Go are more general than in C++ or Java: |
| they can be defined for any sort of data, not just structs. |
| |
| <p> |
| Also, the lack of type hierarchy makes “objects” in Go feel much more |
| lightweight than in languages such as C++ or Java. |
| |
| <h3 id="How_do_I_get_dynamic_dispatch_of_methods"> |
| How do I get dynamic dispatch of methods?</h3> |
| |
| <p> |
| The only way to have dynamically dispatched methods is through an |
| interface. Methods on structs or other types are always resolved statically. |
| |
| <h2 id="Concurrent_programming">Concurrent programming</h2> |
| |
| <h3 id="What_operations_are_atomic_What_about_mutexes"> |
| What operations are atomic? What about mutexes?</h3> |
| |
| <p> |
| We haven't fully defined it all yet, but some details about atomicity are available in the |
| <a href="go_mem.html">Go Memory Model specification</a>. |
| Also, some concurrency questions are answered in more detail in the |
| <a href="go_lang_faq.html">language design FAQ</a>. |
| |
| <p> |
| Regarding mutexes, the <a href="/pkg/sync">sync</a> |
| package implements them, 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. |
| |
| <p> |
| Do not communicate by sharing memory. Instead, share memory by communicating. |
| |
| <h2 id="Writing_Code">Writing Code</h2> |
| |
| <h3 id="How_are_libraries_documented"> |
| How are libraries documented?</h3> |
| |
| <p> |
| There is a program, <code>godoc</code>, 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 |
| <a href="http://golang.org/pkg/">http://golang.org/pkg/</a>. |
| In fact, <code>godoc</code> implements the full site at |
| <a href="http://golang.org/">http://golang.org/</a>. |
| |
| <h3 id="Is_there_a_Go_programming_style_guide"> |
| Is there a Go programming style guide?</h3> |
| |
| <p> |
| Eventually, there may be a small number of rules to guide things |
| like naming, layout, and file organization. |
| The document <a href="effective_go.html">Effective Go</a> |
| contains some style advice. |
| More directly, the program <code>gofmt</code> 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 <code>gofmt</code>. |
| |
| <h3 id="How_do_I_submit_patches_to_the_Go_libraries"> |
| How do I submit patches to the Go libraries?</h3> |
| |
| <p> |
| The library sources are in <code>go/src/pkg</code>. |
| If you want to make a significant change, please discuss on the mailing list before embarking. |
| |
| <p> |
| See the document |
| <a href="contribute.html">Contributing to the Go project</a> |
| for more information about how to proceed. |
| |
| <h3 id="How_do_I_create_a_multifile_package"> |
| How do I create a multifile package?</h3> |
| |
| <p> |
| 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. |
| |
| <p> |
| Other than being split into multiple files, the package will compile and test |
| just like a single-file package. |
| |
| <h3 id="How_do_I_write_a_unit_test"> |
| How do I write a unit test?</h3> |
| |
| <p> |
| Create a new file ending in <code>_test.go</code> in the same directory |
| as your package sources. Inside that file, <code>import "testing"</code> |
| and write functions of the form |
| |
| <pre> |
| func TestFoo(t *testing.T) { |
| ... |
| } |
| </pre> |
| |
| <p> |
| Run <code>gotest</code> in that directory. |
| That script finds the <code>Test</code> functions, |
| builds a test binary, and runs it. |
| |
| <h3 id="Where_is_assert"> |
| Where is assert?</h3> |
| |
| <p> |
| 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. |
| |
| <p> |
| The same arguments apply to the use of <code>assert()</code> 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 |
| <code>isPrime</code> gives the wrong answer for 2, 3, 5, and 7 (or for |
| 2, 4, 8, and 16) than to report that <code>isPrime</code> gives the wrong |
| 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. |
| |
| <p> |
| 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. |
| |
| <p> |
| 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. |
| |
| <h2 id="Implementation">Implementation</h2> |
| |
| <h3 id="What_compiler_technology_is_used_to_build_the_compilers"> |
| What compiler technology is used to build the compilers?</h3> |
| |
| <p> |
| <code>Gccgo</code> has a C++ front-end with a recursive descent parser coupled to the |
| standard GCC back end. <code>Gc</code> is written in C using |
| <code>yacc</code>/<code>bison</code> for the parser. |
| Although it's a new program, it fits in the Plan 9 C compiler suite |
| (<a href="http://plan9.bell-labs.com/sys/doc/compiler.html">http://plan9.bell-labs.com/sys/doc/compiler.html</a>) |
| and uses a variant of the Plan 9 loader to generate ELF binaries. |
| |
| <p> |
| We considered writing <code>6g</code>, 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. <code>Gccgo</code>, which came later, makes it possible to |
| 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 <a href="/pkg/go/"><code>/pkg/go</code></a>.) |
| |
| <p> |
| We also considered using LLVM for <code>6g</code> but we felt it was too large and |
| slow to meet our performance goals. |
| |
| <h3 id="How_is_the_runtime_implemented"> |
| How is the runtime implemented?</h3> |
| |
| <p> |
| 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. <code>Gccgo</code>'s runtime uses <code>glibc</code>. |
| <code>Gc</code> uses a custom library, to keep the footprint under |
| control; it is |
| 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 |
| <code>gccgo</code>. |