| <!--{ |
| "Title": "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: |
| </p> |
| |
| <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: |
| </p> |
| |
| <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_status_of_the_project"> |
| What is the status of the project?</h3> |
| |
| <p> |
| Go became a public open source project on November 10, 2009. |
| After a couple of years of very active design and development, stability was called for and |
| Go 1 was <a href="http://blog.golang.org/2012/03/go-version-1-is-released.html">released</a> |
| on March 28, 2012. |
| Go 1, which includes a <a href="/ref/spec">language specification</a>, |
| <a href="/pkg/">standard libraries</a>, |
| and <a href="/cmd/go/">custom tools</a>, |
| provides a stable foundation for creating reliable products, projects, and publications. |
| </p> |
| |
| <p> |
| With that stability established, we are using Go to develop programs, products, and tools rather than |
| actively changing the language and libraries. |
| In fact, the purpose of Go 1 is to provide <a href="/doc/go1compat.html">long-term stability</a>. |
| Backwards-incompatible changes will not be made to any Go 1 point release. |
| We want to use what we have to learn how a future version of Go might look, rather than to play with |
| the language underfoot. |
| </p> |
| |
| <p> |
| Of course, development will continue on Go itself, but the focus will be on performance, reliability, |
| portability and the addition of new functionality such as improved support for internationalization. |
| </p> |
| |
| <p> |
| There may well be a Go 2 one day, but not for a few years and it will be influenced by what we learn using Go 1 as it is today. |
| </p> |
| |
| <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. |
| </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> |
| |
| <h3 id="history"> |
| What is the history of the project?</h3> |
| <p> |
| Robert Griesemer, Rob Pike and Ken Thompson started sketching the |
| goals for a new language on the white board on September 21, 2007. |
| Within a few days the goals had settled into a plan to do something |
| and a fair idea of what it would be. Design continued part-time in |
| parallel with unrelated work. By January 2008, Ken had started work |
| on a compiler with which to explore ideas; it generated C code as its |
| output. By mid-year the language had become a full-time project and |
| had settled enough to attempt a production compiler. In May 2008, |
| Ian Taylor independently started on a GCC front end for Go using the |
| draft specification. Russ Cox joined in late 2008 and helped move the language |
| and libraries from prototype to reality. |
| </p> |
| |
| <p> |
| Go became a public open source project on November 10, 2009. |
| Many people from the community have contributed ideas, discussions, and code. |
| </p> |
| |
| <h3 id="creating_a_new_language"> |
| Why are you creating a new language?</h3> |
| <p> |
| Go was born out of frustration with existing languages and |
| environments for systems programming. Programming had become too |
| difficult and the choice of languages was partly to blame. One had to |
| choose either efficient compilation, efficient execution, or ease of |
| programming; all three were not available in the same mainstream |
| 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. |
| </p> |
| |
| <p> |
| Go is an attempt to combine the ease of programming of an interpreted, |
| dynamically typed |
| language with the efficiency and safety of a statically typed, compiled language. |
| It also aims to be modern, with support for networked and multicore |
| computing. Finally, it is intended to be <i>fast</i>: it should take |
| at most a few seconds to build a large executable on a single computer. |
| To meet these goals required addressing a number of |
| linguistic issues: an expressive but lightweight type system; |
| concurrency and garbage collection; rigid dependency specification; |
| and so on. These cannot be addressed well by libraries or tools; a new |
| language was called for. |
| </p> |
| |
| <h3 id="ancestors"> |
| What are Go's ancestors?</h3> |
| <p> |
| Go is mostly in the C family (basic syntax), |
| with significant input from the Pascal/Modula/Oberon |
| family (declarations, packages), |
| plus some ideas from languages |
| inspired by Tony Hoare's CSP, |
| such as Newsqueak and Limbo (concurrency). |
| However, it is a new language across the board. |
| 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. |
| </p> |
| |
| <h3 id="principles"> |
| What are the guiding principles in the design?</h3> |
| <p> |
| Programming today involves too much bookkeeping, repetition, and |
| clerical work. As Dick Gabriel says, “Old programs read |
| like quiet conversations between a well-spoken research worker and a |
| well-studied mechanical colleague, not as a debate with a compiler. |
| Who'd have guessed sophistication bought such noise?” |
| The sophistication is worthwhile—no one wants to go back to |
| the old languages—but can it be more quietly achieved? |
| </p> |
| <p> |
| Go attempts to reduce the amount of typing in both senses of the word. |
| Throughout its design, we have tried to reduce clutter and |
| complexity. There are no forward declarations and no header files; |
| everything is declared exactly once. Initialization is expressive, |
| automatic, and easy to use. Syntax is clean and light on keywords. |
| Stuttering (<code>foo.Foo* myFoo = new(foo.Foo)</code>) is reduced by |
| simple type derivation using the <code>:=</code> |
| declare-and-initialize construct. And perhaps most radically, there |
| is no type hierarchy: types just <i>are</i>, they don't have to |
| announce their relationships. These simplifications allow Go to be |
| expressive yet comprehensible without sacrificing, well, sophistication. |
| </p> |
| <p> |
| Another important principle is to keep the concepts orthogonal. |
| Methods can be implemented for any type; structures represent data while |
| interfaces represent abstraction; and so on. Orthogonality makes it |
| easier to understand what happens when things combine. |
| </p> |
| |
| <h2 id="Usage">Usage</h2> |
| |
| <h3 id="Is_Google_using_go_internally"> Is Google using Go internally?</h3> |
| |
| <p> |
| Yes. There are now several Go programs deployed in |
| production inside Google. A public example is the server behind |
| <a href="http://golang.org">http://golang.org</a>. |
| It's just the <a href="/cmd/godoc"><code>godoc</code></a> |
| document server running in a production configuration on |
| <a href="https://developers.google.com/appengine/">Google App Engine</a>. |
| </p> |
| |
| <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>gc</code> |
| (the <code>6g</code> program and friends) 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. |
| </p> |
| |
| <p> |
| The <a href="/cmd/cgo/">cgo</a> 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. |
| </p> |
| |
| |
| <h3 id="Does_Go_support_Google_protocol_buffers"> |
| Does Go support Google's protocol buffers?</h3> |
| |
| <p> |
| A separate open source project provides the necessary compiler plugin and library. |
| It is available at |
| <a href="http://code.google.com/p/goprotobuf/">http://code.google.com/p/goprotobuf/</a> |
| </p> |
| |
| |
| <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 you 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="unicode_identifiers"> |
| What's up with Unicode identifiers?</h3> |
| |
| <p> |
| It was important to us to extend the space of identifiers from the |
| confines of ASCII. Go's rule—identifier characters must be |
| letters or digits as defined by Unicode—is simple to understand |
| and to implement but has restrictions. Combining characters are |
| excluded by design, for instance. |
| Until there |
| is an agreed external definition of what an identifier might be, |
| plus a definition of canonicalization of identifiers that guarantees |
| no ambiguity, it seemed better to keep combining characters out of |
| the mix. Thus we have a simple rule that can be expanded later |
| without breaking programs, one that avoids bugs that would surely arise |
| from a rule that admits ambiguous identifiers. |
| </p> |
| |
| <p> |
| On a related note, since an exported identifier must begin with an |
| upper-case letter, identifiers created from “letters” |
| in some languages can, by definition, not be exported. For now the |
| only solution is to use something like <code>X日本語</code>, which |
| is clearly unsatisfactory; we are considering other options. The |
| case-for-visibility rule is unlikely to change however; it's one |
| of our favorite features of Go. |
| </p> |
| |
| <h3 id="Why_doesnt_Go_have_feature_X">Why does Go not 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> |
| |
| <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>. |
| </p> |
| |
| <h3 id="generics"> |
| Why does Go not have generic types?</h3> |
| <p> |
| Generics may well be added at some point. We don't feel an urgency for |
| them, although we understand some programmers do. |
| </p> |
| |
| <p> |
| Generics are convenient but they come at a cost in |
| complexity in the type system and run-time. We haven't yet found a |
| design that gives value proportionate to the complexity, although we |
| continue to think about it. Meanwhile, Go's built-in maps and slices, |
| 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. |
| </p> |
| |
| <p> |
| This remains an open issue. |
| </p> |
| |
| <h3 id="exceptions"> |
| Why does Go not have exceptions?</h3> |
| <p> |
| We believe that coupling exceptions to a control |
| structure, as in the <code>try-catch-finally</code> idiom, results in |
| convoluted code. It also tends to encourage programmers to label |
| too many ordinary errors, such as failing to open a file, as |
| exceptional. |
| </p> |
| |
| <p> |
| Go takes a different approach. For plain error handling, Go's multi-value |
| returns make it easy to report an error without overloading the return value. |
| <a href="/doc/articles/error_handling.html">A canonical error type, coupled |
| with Go's other features</a>, makes error handling pleasant but quite different |
| from that in other languages. |
| </p> |
| |
| <p> |
| Go also has a couple |
| of built-in functions to signal and recover from truly exceptional |
| conditions. The recovery mechanism is executed only as part of a |
| 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. |
| </p> |
| |
| <p> |
| See the <a href="/doc/articles/defer_panic_recover.html">Defer, Panic, and Recover</a> article for details. |
| </p> |
| |
| <h3 id="assertions"> |
| Why does Go not have assertions?</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> |
| |
| <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. |
| </p> |
| |
| <h3 id="csp"> |
| Why build concurrency on the ideas of CSP?</h3> |
| <p> |
| Concurrency and multi-threaded programming have a reputation |
| for difficulty. We believe this is due partly to complex |
| designs such as pthreads and partly to overemphasis on low-level details |
| such as mutexes, condition variables, and memory barriers. |
| Higher-level interfaces enable much simpler code, even if there are still |
| mutexes and such under the covers. |
| </p> |
| |
| <p> |
| One of the most successful models for providing high-level linguistic support |
| for concurrency comes from Hoare's Communicating Sequential Processes, or CSP. |
| Occam and Erlang are two well known languages that stem from CSP. |
| Go's concurrency primitives derive from a different part of the family tree |
| whose main contribution is the powerful notion of channels as first class objects. |
| </p> |
| |
| <h3 id="goroutines"> |
| Why goroutines instead of threads?</h3> |
| <p> |
| Goroutines are part of making concurrency easy to use. The idea, which has |
| been around for a while, is to multiplex independently executing |
| functions—coroutines—onto a set of threads. |
| When a coroutine blocks, such as by calling a blocking system call, |
| the run-time automatically moves other coroutines on the same operating |
| system thread to a different, runnable thread so they won't be blocked. |
| The programmer sees none of this, which is the point. |
| The result, which we call goroutines, can be very cheap: unless they spend a lot of time |
| in long-running system calls, they cost little more than the memory |
| for the stack, which is just a few kilobytes. |
| </p> |
| |
| <p> |
| 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. |
| When it isn't, the run-time allocates (and frees) extension segments automatically. |
| The overhead averages about three cheap instructions per function call. |
| It is practical to create hundreds of thousands of goroutines in the same |
| address space. If goroutines were just threads, system resources would |
| run out at a much smaller number. |
| </p> |
| |
| <h3 id="atomic_maps"> |
| Why are map operations not defined to be atomic?</h3> |
| |
| <p> |
| After long discussion it was decided that the typical use of maps did not require |
| safe access from multiple threads, and in those cases where it did, the map was |
| probably part of some larger data structure or computation that was already |
| synchronized. Therefore requiring that all map operations grab a mutex would slow |
| down most programs and add safety to few. This was not an easy decision, |
| however, since it means uncontrolled map access can crash the program. |
| </p> |
| |
| <p> |
| The language does not preclude atomic map updates. When required, such |
| as when hosting an untrusted program, the implementation could interlock |
| map access. |
| </p> |
| |
| <h2 id="types">Types</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, even built-in types such |
| as plain, “unboxed” integers. |
| They are not restricted to structs (classes). |
| </p> |
| |
| <p> |
| Also, the lack of type hierarchy makes “objects” in Go feel much more |
| lightweight than in languages such as C++ or Java. |
| </p> |
| |
| <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 a struct or any other concrete type are always resolved statically. |
| </p> |
| |
| <h3 id="inheritance"> |
| Why is there no type inheritance?</h3> |
| <p> |
| Object-oriented programming, at least in the best-known languages, |
| involves too much discussion of the relationships between types, |
| relationships that often could be derived automatically. Go takes a |
| different approach. |
| </p> |
| |
| <p> |
| Rather than requiring the programmer to declare ahead of time that two |
| types are related, in Go a type automatically satisfies any interface |
| that specifies a subset of its methods. Besides reducing the |
| bookkeeping, this approach has real advantages. Types can satisfy |
| many interfaces at once, without the complexities of traditional |
| multiple inheritance. |
| Interfaces can be very lightweight—an interface with |
| one or even zero methods can express a useful concept. |
| Interfaces can be added after the fact if a new idea comes along |
| 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. |
| </p> |
| |
| <p> |
| It's possible to use these ideas to construct something analogous to |
| type-safe Unix pipes. For instance, see how <code>fmt.Fprintf</code> |
| enables formatted printing to any output, not just a file, or how the |
| <code>bufio</code> package can be completely separate from file I/O, |
| or how the <code>image</code> packages generate compressed |
| image files. All these ideas stem from a single interface |
| (<code>io.Writer</code>) representing a single method |
| (<code>Write</code>). And that's only scratching the surface. |
| Go's interfaces have a profound influence on how programs are structured. |
| </p> |
| |
| <p> |
| It takes some getting used to but this implicit style of type |
| dependency is one of the most productive things about Go. |
| </p> |
| |
| <h3 id="methods_on_basics"> |
| Why is <code>len</code> a function and not a method?</h3> |
| <p> |
| We debated this issue but decided |
| implementing <code>len</code> and friends as functions was fine in practice and |
| didn't complicate questions about the interface (in the Go type sense) |
| of basic types. |
| </p> |
| |
| <h3 id="overloading"> |
| Why does Go not support overloading of methods and operators?</h3> |
| <p> |
| Method dispatch is simplified if it doesn't need to do type matching as well. |
| Experience with other languages told us that having a variety of |
| methods with the same name but different signatures was occasionally useful |
| but that it could also be confusing and fragile in practice. Matching only by name |
| and requiring consistency in the types was a major simplifying decision |
| in Go's type system. |
| </p> |
| |
| <p> |
| Regarding operator overloading, it seems more a convenience than an absolute |
| requirement. Again, things are simpler without it. |
| </p> |
| |
| <h3 id="implements_interface"> |
| Why doesn't Go have "implements" declarations?</h3> |
| |
| <p> |
| A Go type satisfies an interface by implementing the methods of that interface, |
| nothing more. This property allows interfaces to be defined and used without |
| having to modify existing code. It enables a kind of structural typing that |
| promotes separation of concerns and improves code re-use, and makes it easier |
| to build on patterns that emerge as the code develops. |
| The semantics of interfaces is one of the main reasons for Go's nimble, |
| lightweight feel. |
| </p> |
| |
| <p> |
| See the <a href="#inheritance">question on type inheritance</a> for more detail. |
| </p> |
| |
| <h3 id="guarantee_satisfies_interface"> |
| How can I guarantee my type satisfies an interface?</h3> |
| |
| <p> |
| You can ask the compiler to check that the type <code>T</code> implements the |
| interface <code>I</code> by attempting an assignment: |
| </p> |
| |
| <pre> |
| type T struct{} |
| var _ I = T{} // Verify that T implements I. |
| </pre> |
| |
| <p> |
| If <code>T</code> doesn't implement <code>I</code>, the mistake will be caught |
| at compile time. |
| </p> |
| |
| <p> |
| If you wish the users of an interface to explicitly declare that they implement |
| it, you can add a method with a descriptive name to the interface's method set. |
| For example: |
| </p> |
| |
| <pre> |
| type Fooer interface { |
| Foo() |
| ImplementsFooer() |
| } |
| </pre> |
| |
| <p> |
| A type must then implement the <code>ImplementsFooer</code> method to be a |
| <code>Fooer</code>, clearly documenting the fact and announcing it in |
| <a href="/cmd/godoc/">godoc</a>'s output. |
| </p> |
| |
| <pre> |
| type Bar struct{} |
| func (b Bar) ImplementsFooer() {} |
| func (b Bar) Foo() {} |
| </pre> |
| |
| <p> |
| Most code doesn't make use of such constraints, since they limit the utility of |
| the interface idea. Sometimes, though, they're necessary to resolve ambiguities |
| among similar interfaces. |
| </p> |
| |
| <h3 id="t_and_equal_interface"> |
| Why doesn't type T satisfy the Equal interface?</h3> |
| |
| <p> |
| Consider this simple interface to represent an object that can compare |
| itself with another value: |
| </p> |
| |
| <pre> |
| type Equaler interface { |
| Equal(Equaler) bool |
| } |
| </pre> |
| |
| <p> |
| and this type, <code>T</code>: |
| </p> |
| |
| <pre> |
| type T int |
| func (t T) Equal(u T) bool { return t == u } // does not satisfy Equaler |
| </pre> |
| |
| <p> |
| Unlike the analogous situation in some polymorphic type systems, |
| <code>T</code> does not implement <code>Equaler</code>. |
| The argument type of <code>T.Equal</code> is <code>T</code>, |
| not literally the required type <code>Equaler</code>. |
| </p> |
| |
| <p> |
| In Go, the type system does not promote the argument of |
| <code>Equal</code>; that is the programmer's responsibility, as |
| illustrated by the type <code>T2</code>, which does implement |
| <code>Equaler</code>: |
| </p> |
| |
| <pre> |
| type T2 int |
| func (t T2) Equal(u Equaler) bool { return t == u.(T2) } // satisfies Equaler |
| </pre> |
| |
| <p> |
| Even this isn't like other type systems, though, because in Go <em>any</em> |
| type that satisfies <code>Equaler</code> could be passed as the |
| argument to <code>T2.Equal</code>, and at run time we must |
| check that the argument is of type <code>T2</code>. |
| Some languages arrange to make that guarantee at compile time. |
| </p> |
| |
| <p> |
| A related example goes the other way: |
| </p> |
| |
| <pre> |
| type Opener interface { |
| Open(name) Reader |
| } |
| |
| func (t T3) Open() *os.File |
| </pre> |
| |
| <p> |
| In Go, <code>T3</code> does not satisfy <code>Opener</code>, |
| although it might in another language. |
| </p> |
| |
| <p> |
| While it is true that Go's type system does less for the programmer |
| in such cases, the lack of subtyping makes the rules about |
| interface satisfaction very easy to state: are the function's names |
| and signatures exactly those of the interface? |
| Go's rule is also easy to implement efficiently. |
| We feel these benefits offset the lack of |
| automatic type promotion. Should Go one day adopt some form of generic |
| typing, we expect there would be a way to express the idea of these |
| examples and also have them be statically checked. |
| </p> |
| |
| <h3 id="convert_slice_of_interface"> |
| Can I convert a []T to an []interface{}?</h3> |
| |
| <p> |
| Not directly, because they do not have the same representation in memory. |
| It is necessary to copy the elements individually to the destination |
| slice. This example converts a slice of <code>int</code> to a slice of |
| <code>interface{}</code>: |
| </p> |
| |
| <pre> |
| t := []int{1, 2, 3, 4} |
| s := make([]interface{}, len(t)) |
| for i, v := range t { |
| s[i] = v |
| } |
| </pre> |
| |
| <h3 id="nil_error"> |
| Why is my nil error value not equal to nil? |
| </h3> |
| |
| <p> |
| Under the covers, interfaces are implemented as two elements, a type and a value. |
| The value, called the interface's dynamic value, |
| is an arbitrary concrete value and the type is that of the value. |
| For the <code>int</code> value 3, an interface value contains, |
| schematically, (<code>int</code>, <code>3</code>). |
| </p> |
| |
| <p> |
| An interface value is <code>nil</code> only if the inner value and type are both unset, |
| (<code>nil</code>, <code>nil</code>). |
| In particular, a <code>nil</code> interface will always hold a <code>nil</code> type. |
| If we store a pointer of type <code>*int</code> inside |
| an interface value, the inner type will be <code>*int</code> regardless of the value of the pointer: |
| (<code>*int</code>, <code>nil</code>). |
| Such an interface value will therefore be non-<code>nil</code> |
| <em>even when the pointer inside is</em> <code>nil</code>. |
| </p> |
| |
| <p> |
| This situation can be confusing, and often arises when a <code>nil</code> value is |
| stored inside an interface value such as an <code>error</code> return: |
| </p> |
| |
| <pre> |
| func returnsError() error { |
| var p *MyError = nil |
| if bad() { |
| p = ErrBad |
| } |
| return p // Will always return a non-nil error. |
| } |
| </pre> |
| |
| <p> |
| If all goes well, the function returns a <code>nil</code> <code>p</code>, |
| so the return value is an <code>error</code> interface |
| value holding (<code>*MyError</code>, <code>nil</code>). |
| This means that if the caller compares the returned error to <code>nil</code>, |
| it will always look as if there was an error even if nothing bad happened. |
| To return a proper <code>nil</code> <code>error</code> to the caller, |
| the function must return an explicit <code>nil</code>: |
| </p> |
| |
| |
| <pre> |
| func returnsError() error { |
| if bad() { |
| return ErrBad |
| } |
| return nil |
| } |
| </pre> |
| |
| <p> |
| It's a good idea for functions |
| that return errors always to use the <code>error</code> type in |
| their signature (as we did above) rather than a concrete type such |
| as <code>*MyError</code>, to help guarantee the error is |
| created correctly. As an example, |
| <a href="/pkg/os/#Open"><code>os.Open</code></a> |
| returns an <code>error</code> even though, if not <code>nil</code>, |
| it's always of concrete type |
| <a href="/pkg/os/#PathError"><code>*os.PathError</code></a>. |
| </p> |
| |
| <p> |
| Similar situations to those described here can arise whenever interfaces are used. |
| Just keep in mind that if any concrete value |
| has been stored in the interface, the interface will not be <code>nil</code>. |
| For more information, see |
| <a href="/doc/articles/laws_of_reflection.html">The Laws of Reflection</a>. |
| </p> |
| |
| |
| <h3 id="unions"> |
| Why are there no untagged unions, as in C?</h3> |
| |
| <p> |
| Untagged unions would violate Go's memory safety |
| guarantees. |
| </p> |
| |
| <h3 id="variant_types"> |
| Why does Go not have variant types?</h3> |
| |
| <p> |
| Variant types, also known as algebraic types, provide a way to specify |
| that a value might take one of a set of other types, but only those |
| types. A common example in systems programming would specify that an |
| error is, say, a network error, a security error or an application |
| error and allow the caller to discriminate the source of the problem |
| by examining the type of the error. Another example is a syntax tree |
| in which each node can be a different type: declaration, statement, |
| assignment and so on. |
| </p> |
| |
| <p> |
| We considered adding variant types to Go, but after discussion |
| decided to leave them out because they overlap in confusing ways |
| with interfaces. What would happen if the elements of a variant type |
| were themselves interfaces? |
| </p> |
| |
| <p> |
| Also, some of what variant types address is already covered by the |
| language. The error example is easy to express using an interface |
| value to hold the error and a type switch to discriminate cases. The |
| syntax tree example is also doable, although not as elegantly. |
| </p> |
| |
| <h2 id="values">Values</h2> |
| |
| <h3 id="conversions"> |
| Why does Go not provide implicit numeric conversions?</h3> |
| <p> |
| The convenience of automatic conversion between numeric types in C is |
| outweighed by the confusion it causes. When is an expression unsigned? |
| How big is the value? Does it overflow? Is the result portable, independent |
| of the machine on which it executes? |
| It also complicates the compiler; “the usual arithmetic conversions” |
| are not easy to implement and inconsistent across architectures. |
| For reasons of portability, we decided to make things clear and straightforward |
| at the cost of some explicit conversions in the code. |
| The definition of constants in Go—arbitrary precision values free |
| of signedness and size annotations—ameliorates matters considerably, |
| though. |
| </p> |
| |
| <p> |
| A related detail is that, unlike in C, <code>int</code> and <code>int64</code> |
| are distinct types even if <code>int</code> is a 64-bit type. The <code>int</code> |
| type is generic; if you care about how many bits an integer holds, Go |
| encourages you to be explicit. |
| </p> |
| |
| <h3 id="builtin_maps"> |
| Why are maps built in?</h3> |
| <p> |
| The same reason strings are: they are such a powerful and important data |
| structure that providing one excellent implementation with syntactic support |
| makes programming more pleasant. We believe that Go's implementation of maps |
| is strong enough that it will serve for the vast majority of uses. |
| If a specific application can benefit from a custom implementation, it's possible |
| to write one but it will not be as convenient syntactically; this seems a reasonable tradeoff. |
| </p> |
| |
| <h3 id="map_keys"> |
| Why don't maps allow slices as keys?</h3> |
| <p> |
| Map lookup requires an equality operator, which slices do not implement. |
| They don't implement equality because equality is not well defined on such types; |
| there are multiple considerations involving shallow vs. deep comparison, pointer vs. |
| value comparison, how to deal with recursive types, and so on. |
| We may revisit this issue—and implementing equality for slices |
| will not invalidate any existing programs—but without a clear idea of what |
| equality of slices should mean, it was simpler to leave it out for now. |
| </p> |
| |
| <p> |
| In Go 1, unlike prior releases, equality is defined for structs and arrays, so such |
| types can be used as map keys. Slices still do not have a definition of equality, though. |
| </p> |
| |
| <h3 id="references"> |
| Why are maps, slices, and channels references while arrays are values?</h3> |
| <p> |
| There's a lot of history on that topic. Early on, maps and channels |
| were syntactically pointers and it was impossible to declare or use a |
| non-pointer instance. Also, we struggled with how arrays should work. |
| Eventually we decided that the strict separation of pointers and |
| values made the language harder to use. Introducing reference types, |
| including slices to handle the reference form of arrays, resolved |
| these issues. Reference types add some regrettable complexity to the |
| language but they have a large effect on usability: Go became a more |
| productive, comfortable language when they were introduced. |
| </p> |
| |
| <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>. |
| </p> |
| |
| <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>. |
| </p> |
| |
| <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> |
| |
| <p> |
| See the document |
| <a href="contribute.html">Contributing to the Go project</a> |
| for more information about how to proceed. |
| </p> |
| |
| <h3 id="Why_does_the_project_use_Mercurial_and_not_git"> |
| Why does the project use Mercurial and not git?</h3> |
| |
| <p> |
| The Go project, hosted by Google Code at |
| <a href="http://code.google.com/p/go">code.google.com/p/go</a>, |
| uses Mercurial as its version control system. |
| When the project launched, |
| Google Code supported only Subversion and Mercurial. |
| Mercurial was a better choice because of its plugin mechanism |
| that allowed us to create the "codereview" plugin to connect |
| the project to the excellent code review tools at |
| <a href="http://codereview.appspot.com">codereview.appspot.com</a>. |
| </p> |
| |
| <p> |
| Programmers who work |
| with the Go project's source rather than release downloads sometimes |
| ask for the project to switch to git. |
| That would be possible, but it would be a lot of work and |
| would also require reimplementing the codereview plugin. |
| Given that Mercurial works today, with code review support, |
| combined with the Go project's mostly linear, non-branching use of |
| version control, a switch to git doesn't seem worthwhile. |
| </p> |
| |
| <h2 id="Pointers">Pointers and Allocation</h2> |
| |
| <h3 id="pass_by_value"> |
| When are function parameters passed by value?</h3> |
| |
| <p> |
| As in all languages in the C family, everything in Go is passed by value. |
| That is, a function always gets a copy of the |
| thing being passed, as if there were an assignment statement assigning the |
| value to the parameter. For instance, passing an <code>int</code> value |
| to a function makes a copy of the <code>int</code>, and passing a pointer |
| value makes a copy of the pointer, but not the data it points to. |
| (See the next section for a discussion of how this affects method receivers.) |
| </p> |
| |
| <p> |
| Map and slice values behave like pointers: they are descriptors that |
| contain pointers to the underlying map or slice data. Copying a map or |
| slice value doesn't copy the data it points to. Copying an interface value |
| makes a copy of the thing stored in the interface value. If the interface |
| value holds a struct, copying the interface value makes a copy of the |
| struct. If the interface value holds a pointer, copying the interface value |
| makes a copy of the pointer, but again not the data it points to. |
| </p> |
| |
| <h3 id="methods_on_values_or_pointers"> |
| Should I define methods on values or pointers?</h3> |
| |
| <pre> |
| func (s *MyStruct) pointerMethod() { } // method on pointer |
| func (s MyStruct) valueMethod() { } // method on value |
| </pre> |
| |
| <p> |
| For programmers unaccustomed to pointers, the distinction between these |
| two examples can be confusing, but the situation is actually very simple. |
| When defining a method on a type, the receiver (<code>s</code> in the above |
| examples) behaves exactly as if it were an argument to the method. |
| Whether to define the receiver as a value or as a pointer is the same |
| question, then, as whether a function argument should be a value or |
| a pointer. |
| There are several considerations. |
| </p> |
| |
| <p> |
| First, and most important, does the method need to modify the |
| receiver? |
| If it does, the receiver <em>must</em> be a pointer. |
| (Slices and maps are reference types, so their story is a little |
| more subtle, but for instance to change the length of a slice |
| in a method the receiver must still be a pointer.) |
| In the examples above, if <code>pointerMethod</code> modifies |
| the fields of <code>s</code>, |
| the caller will see those changes, but <code>valueMethod</code> |
| is called with a copy of the caller's argument (that's the definition |
| of passing a value), so changes it makes will be invisible to the caller. |
| </p> |
| |
| <p> |
| By the way, pointer receivers are identical to the situation in Java, |
| although in Java the pointers are hidden under the covers; it's Go's |
| value receivers that are unusual. |
| </p> |
| |
| <p> |
| Second is the consideration of efficiency. If the receiver is large, |
| a big <code>struct</code> for instance, it will be much cheaper to |
| use a pointer receiver. |
| </p> |
| |
| <p> |
| Next is consistency. If some of the methods of the type must have |
| pointer receivers, the rest should too, so the method set is |
| consistent regardless of how the type is used. |
| See the section on <a href="#different_method_sets">method sets</a> |
| for details. |
| </p> |
| |
| <p> |
| For types such as basic types, slices, and small <code>structs</code>, |
| a value receiver is very cheap so unless the semantics of the method |
| requires a pointer, a value receiver is efficient and clear. |
| </p> |
| |
| |
| <h3 id="new_and_make"> |
| What's the difference between new and make?</h3> |
| |
| <p> |
| In short: <code>new</code> allocates memory, <code>make</code> initializes |
| the slice, map, and channel types. |
| </p> |
| |
| <p> |
| See the <a href="/doc/effective_go.html#allocation_new">relevant section |
| of Effective Go</a> for more details. |
| </p> |
| |
| <h3 id="q_int_sizes"> |
| Why is <code>int</code> 32 bits on 64 bit machines?</h3> |
| |
| <p> |
| The sizes of <code>int</code> and <code>uint</code> are implementation-specific |
| but the same as each other on a given platform. |
| The 64 bit Go compilers (both gc and gccgo) use a 32 bit representation for |
| <code>int</code>. Code that relies on a particular |
| size of value should use an explicitly sized type, like <code>int64</code>. |
| On the other hand, floating-point scalars and complex |
| numbers are always sized: <code>float32</code>, <code>complex64</code>, |
| etc., because programmers should be aware of precision when using |
| floating-point numbers. |
| The default size of a floating-point constant is <code>float64</code>. |
| </p> |
| |
| <p> |
| At the moment, all implementations use 32-bit ints, an essentially arbitrary decision. |
| However, we expect that <code>int</code> will be increased to 64 bits on 64-bit |
| architectures in a future release of Go. |
| </p> |
| |
| <h3 id="stack_or_heap"> |
| How do I know whether a variable is allocated on the heap or the stack?</h3> |
| |
| <p> |
| 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. |
| </p> |
| |
| <p> |
| The storage location does have an effect on writing efficient programs. |
| When possible, the Go compilers will allocate variables that are |
| 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. |
| Also, if a local variable is very large, it might make more sense |
| to store it on the heap rather than the stack. |
| </p> |
| |
| <p> |
| In the current compilers, if a variable has its address taken, that variable |
| is a candidate for allocation on the heap. However, a basic <em>escape |
| analysis</em> recognizes some cases when such variables will not |
| live past the return from the function and can reside on the stack. |
| </p> |
| |
| <h2 id="Concurrency">Concurrency</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="/ref/mem">Go Memory Model specification</a>. |
| </p> |
| |
| <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> |
| |
| <p> |
| Do not communicate by sharing memory. Instead, share memory by communicating. |
| </p> |
| |
| <p> |
| See the <a href="/doc/codewalk/sharemem/">Share Memory By Communicating</a> code walk and its <a href="http://blog.golang.org/2010/07/share-memory-by-communicating.html">associated article</a> for a detailed discussion of this concept. |
| </p> |
| |
| <h3 id="Why_no_multi_CPU"> |
| Why doesn't my multi-goroutine program use multiple CPUs?</h3> |
| |
| <p> |
| You must set the <code>GOMAXPROCS</code> shell environment variable |
| or use the similarly-named <a href="/pkg/runtime/#GOMAXPROCS"><code>function</code></a> |
| of the runtime package to allow the |
| run-time support to utilize more than one OS thread. |
| </p> |
| |
| <p> |
| Programs that perform parallel computation should benefit from an increase in |
| <code>GOMAXPROCS</code>. |
| </p> |
| |
| <h3 id="Why_GOMAXPROCS"> |
| Why does using <code>GOMAXPROCS</code> > 1 sometimes make my program |
| slower?</h3> |
| |
| <p> |
| It depends on the nature of your program. |
| Problems that are intrinsically sequential cannot be sped up by adding |
| more goroutines. |
| Concurrency only becomes parallelism when the problem is |
| intrinsically parallel. |
| </p> |
| |
| <p> |
| In practical terms, programs that spend more time |
| communicating on channels than doing computation |
| will experience performance degradation when using |
| multiple OS threads. |
| This is because sending data between threads involves switching |
| contexts, which has significant cost. |
| For instance, the <a href="/ref/spec#An_example_package">prime sieve example</a> |
| from the Go specification has no significant parallelism although it launches many |
| goroutines; increasing <code>GOMAXPROCS</code> is more likely to slow it down than |
| to speed it up. |
| </p> |
| |
| <p> |
| Go's goroutine scheduler is not as good as it needs to be. In future, it |
| should recognize such cases and optimize its use of OS threads. For now, |
| <code>GOMAXPROCS</code> should be set on a per-application basis. |
| </p> |
| |
| <h2 id="Functions_methods">Functions and Methods</h2> |
| |
| <h3 id="different_method_sets"> |
| Why do T and *T have different method sets?</h3> |
| |
| <p> |
| From the <a href="/ref/spec#Types">Go Spec</a>: |
| </p> |
| |
| <blockquote> |
| The method set of any other named type <code>T</code> consists of all methods |
| with receiver type <code>T</code>. The method set of the corresponding pointer |
| type <code>*T</code> is the set of all methods with receiver <code>*T</code> or |
| <code>T</code> (that is, it also contains the method set of <code>T</code>). |
| </blockquote> |
| |
| <p> |
| If an interface value contains a pointer <code>*T</code>, |
| a method call can obtain a value by dereferencing the pointer, |
| but if an interface value contains a value <code>T</code>, |
| there is no useful way for a method call to obtain a pointer. |
| </p> |
| |
| <p> |
| Even in cases where the compiler could take the address of a value |
| to pass to the method, if the method modifies the value the changes |
| will be lost in the caller. |
| As a common example, this code: |
| </p> |
| |
| <pre> |
| var buf bytes.Buffer |
| io.Copy(buf, os.Stdin) |
| </pre> |
| |
| <p> |
| would copy standard input into a <i>copy</i> of <code>buf</code>, |
| not into <code>buf</code> itself. |
| This is almost never the desired behavior. |
| </p> |
| |
| <h3 id="closures_and_goroutines"> |
| What happens with closures running as goroutines?</h3> |
| |
| <p> |
| Some confusion may arise when using closures with concurrency. |
| Consider the following program: |
| </p> |
| |
| <pre> |
| func main() { |
| done := make(chan bool) |
| |
| values := []string{"a", "b", "c"} |
| for _, v := range values { |
| go func() { |
| fmt.Println(v) |
| done <- true |
| }() |
| } |
| |
| // wait for all goroutines to complete before exiting |
| for _ = range values { |
| <-done |
| } |
| } |
| </pre> |
| |
| <p> |
| One might mistakenly expect to see <code>a, b, c</code> as the output. |
| What you'll probably see instead is <code>c, c, c</code>. This is because |
| each iteration of the loop uses the same instance of the variable <code>v</code>, so |
| each closure shares that single variable. When the closure runs, it prints the |
| value of <code>v</code> at the time <code>fmt.Println</code> is executed, |
| but <code>v</code> may have been modified since the goroutine was launched. |
| </p> |
| |
| <p> |
| To bind the current value of <code>v</code> to each closure as it is launched, one |
| must modify the inner loop to create a new variable each iteration. |
| One way is to pass the variable as an argument to the closure: |
| </p> |
| |
| <pre> |
| for _, v := range values { |
| go func(<b>u</b> string) { |
| fmt.Println(<b>u</b>) |
| done <- true |
| }(<b>v</b>) |
| } |
| </pre> |
| |
| <p> |
| In this example, the value of <code>v</code> is passed as an argument to the |
| anonymous function. That value is then accessible inside the function as |
| the variable <code>u</code>. |
| </p> |
| |
| <p> |
| Even easier is just to create a new variable, using a declaration style that may |
| seem odd but works fine in Go: |
| </p> |
| |
| <pre> |
| for _, v := range values { |
| <b>v := v</b> // create a new 'v'. |
| go func() { |
| fmt.Println(<b>v</b>) |
| done <- true |
| }() |
| } |
| </pre> |
| |
| <h2 id="Control_flow">Control flow</h2> |
| |
| <h3 id="Does_Go_have_a_ternary_form"> |
| Does Go have the <code>?:</code> operator?</h3> |
| |
| <p> |
| There is no ternary form in Go. You may use the following to achieve the same |
| result: |
| </p> |
| |
| <pre> |
| if expr { |
| n = trueVal |
| } else { |
| n = falseVal |
| } |
| </pre> |
| |
| <h2 id="Packages_Testing">Packages and Testing</h2> |
| |
| <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 need for forward declarations or a header file. |
| </p> |
| |
| <p> |
| Other than being split into multiple files, the package will compile and test |
| just like a single-file package. |
| </p> |
| |
| <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 |
| </p> |
| |
| <pre> |
| func TestFoo(t *testing.T) { |
| ... |
| } |
| </pre> |
| |
| <p> |
| Run <code>go test</code> in that directory. |
| That script finds the <code>Test</code> functions, |
| builds a test binary, and runs it. |
| </p> |
| |
| <p>See the <a href="/doc/code.html">How to Write Go Code</a> document, |
| the <a href="/pkg/testing/"><code>testing</code></a> package |
| and the <a href="/cmd/go/#Test_packages"><code>go test</code></a> subcommand for more details. |
| </p> |
| |
| <h3 id="testing_framework"> |
| Where is my favorite helper function for testing?</h3> |
| |
| <p> |
| Go's standard <a href="/pkg/testing/"><code>testing</code></a> package makes it easy to write unit tests, but it lacks |
| features provided in other language's testing frameworks such as assertion functions. |
| An <a href="#assertions">earlier section</a> of this document explained why Go |
| doesn't have assertions, and |
| the same arguments apply to the use of <code>assert</code> in tests. |
| 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> |
| |
| <p> |
| A related point is that testing frameworks tend to develop into mini-languages |
| of their own, with conditionals and controls and printing mechanisms, |
| but Go already has all those capabilities; why recreate them? |
| We'd rather write tests in Go; it's one fewer language to learn and the |
| approach keeps the tests straightforward and easy to understand. |
| </p> |
| |
| <p> |
| If the amount of extra code required to write |
| good errors seems repetitive and overwhelming, the test might work better if |
| table-driven, iterating over a list of inputs and outputs defined |
| in a data structure (Go has excellent support for data structure literals). |
| The work to write a good test and good error messages will then be amortized over many |
| test cases. The standard Go library is full of illustrative examples, such as in |
| <a href="/src/pkg/fmt/fmt_test.go">the formatting tests for the <code>fmt</code> package</a>. |
| </p> |
| |
| |
| <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/Mach-O/PE binaries. |
| </p> |
| |
| <p> |
| We considered writing <code>gc</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 the <a href="/pkg/go/"><code>go</code></a> package.) |
| </p> |
| |
| <p> |
| We also considered using LLVM for <code>gc</code> but we felt it was too large and |
| slow to meet our performance goals. |
| </p> |
| |
| <h3 id="How_is_the_run_time_support_implemented"> |
| How is the run-time support implemented?</h3> |
| |
| <p> |
| Again due to bootstrapping issues, the run-time code is mostly in C (with a |
| tiny bit of assembler) although Go is capable of implementing most of |
| it now. <code>Gccgo</code>'s run-time support 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. |
| The <code>gccgo</code> compiler implements segmented |
| stacks on Linux only, supported by recent modifications to the gold linker. |
| </p> |
| |
| <h3 id="Why_is_my_trivial_program_such_a_large_binary"> |
| Why is my trivial program such a large binary?</h3> |
| |
| <p> |
| The linkers in the gc tool chain (<code>5l</code>, <code>6l</code>, and <code>8l</code>) |
| do static linking. 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. |
| </p> |
| |
| <p> |
| A simple C "hello, world" program compiled and linked statically using gcc |
| on Linux is around 750 kB, |
| including an implementation of <code>printf</code>. |
| An equivalent Go program using <code>fmt.Printf</code> |
| is around 1.2 MB, but |
| that includes more powerful run-time support. |
| </p> |
| |
| <h3 id="unused_variables_and_imports"> |
| Can I stop these complaints about my unused variable/import?</h3> |
| |
| <p> |
| The presence of an unused variable may indicate a bug, while |
| unused imports just slow down compilation. |
| Accumulate enough unused imports in your code tree and |
| things can get very slow. |
| For these reasons, Go allows neither. |
| </p> |
| |
| <p> |
| When developing code, it's common to create these situations |
| temporarily and it can be annoying to have to edit them out before the |
| program will compile. |
| </p> |
| |
| <p> |
| Some have asked for a compiler option to turn those checks off |
| or at least reduce them to warnings. |
| Such an option has not been added, though, |
| because compiler options should not affect the semantics of the |
| language and because the Go compiler does not report warnings, only |
| errors that prevent compilation. |
| </p> |
| |
| <p> |
| There are two reasons for having no warnings. First, if it's worth |
| complaining about, it's worth fixing in the code. (And if it's not |
| worth fixing, it's not worth mentioning.) Second, having the compiler |
| generate warnings encourages the implementation to warn about weak |
| cases that can make compilation noisy, masking real errors that |
| <em>should</em> be fixed. |
| </p> |
| |
| <p> |
| It's easy to address the situation, though. Use the blank identifier |
| to let unused things persist while you're developing. |
| </p> |
| |
| <pre> |
| import "unused" |
| |
| // This declaration marks the import as used by referencing an |
| // item from the package. |
| var _ = unused.Item // TODO: Delete before committing! |
| |
| func main() { |
| debugData := debug.Profile() |
| _ = debugData // Used only during debugging. |
| .... |
| } |
| </pre> |
| |
| <h2 id="Performance">Performance</h2> |
| |
| <h3 id="Why_does_Go_perform_badly_on_benchmark_x"> |
| Why does Go perform badly on benchmark X?</h3> |
| |
| <p> |
| One of Go's design goals is to approach the performance of C for comparable |
| programs, yet on some benchmarks it does quite poorly, including several |
| in <a href="/test/bench/shootout/">test/bench/shootout</a>. The slowest depend on libraries |
| for which versions of comparable performance are not available in Go. |
| For instance, <a href="/test/bench/shootout/pidigits.go">pidigits.go</a> |
| depends on a multi-precision math package, and the C |
| versions, unlike Go's, use <a href="http://gmplib.org/">GMP</a> (which is |
| written in optimized assembler). |
| Benchmarks that depend on regular expressions |
| (<a href="/test/bench/shootout/regex-dna.go">regex-dna.go</a>, for instance) are |
| essentially comparing Go's native <a href="/pkg/regexp">regexp package</a> to |
| mature, highly optimized regular expression libraries like PCRE. |
| </p> |
| |
| <p> |
| Benchmark games are won by extensive tuning and the Go versions of most |
| of the benchmarks need attention. If you measure comparable C |
| and Go programs |
| (<a href="/test/bench/shootout/reverse-complement.go">reverse-complement.go</a> is one example), you'll see the two |
| languages are much closer in raw performance than this suite would |
| indicate. |
| </p> |
| |
| <p> |
| Still, there is room for improvement. The compilers are good but could be |
| better, many libraries need major performance work, and the garbage collector |
| isn't fast enough yet. (Even if it were, taking care not to generate unnecessary |
| garbage can have a huge effect.) |
| </p> |
| |
| <p> |
| In any case, Go can often be very competitive. |
| There has been significant improvement in the performance of many programs |
| as the language and tools have developed. |
| See the blog post about |
| <a href="http://blog.golang.org/2011/06/profiling-go-programs.html">profiling |
| Go programs</a> for an informative example. |
| |
| <h2 id="change_from_c">Changes from C</h2> |
| |
| <h3 id="different_syntax"> |
| Why is the syntax so different from C?</h3> |
| <p> |
| 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 analyze |
| 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. |
| </p> |
| |
| <h3 id="declarations_backwards"> |
| Why are declarations backwards?</h3> |
| <p> |
| 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 <code>*</code> for pointers is an exception that proves the rule). In C, |
| the declaration |
| </p> |
| <pre> |
| int* a, b; |
| </pre> |
| <p> |
| declares <code>a</code> to be a pointer but not <code>b</code>; in Go |
| </p> |
| <pre> |
| var a, b *int |
| </pre> |
| <p> |
| declares both to be pointers. This is clearer and more regular. |
| Also, the <code>:=</code> short declaration form argues that a full variable |
| declaration should present the same order as <code>:=</code> so |
| </p> |
| <pre> |
| var a uint64 = 1 |
| </pre> |
| <p> |
| has the same effect as |
| </p> |
| <pre> |
| a := uint64(1) |
| </pre> |
| <p> |
| Parsing is also simplified by having a distinct grammar for types that |
| is not just the expression grammar; keywords such as <code>func</code> |
| and <code>chan</code> keep things clear. |
| </p> |
| |
| <p> |
| See the article about |
| <a href="/doc/articles/gos_declaration_syntax.html">Go's Declaration Syntax</a> |
| for more details. |
| </p> |
| |
| <h3 id="no_pointer_arithmetic"> |
| Why is there no pointer arithmetic?</h3> |
| <p> |
| 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 have 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. |
| </p> |
| |
| <h3 id="inc_dec"> |
| Why are <code>++</code> and <code>--</code> statements and not expressions? And why postfix, not prefix?</h3> |
| <p> |
| 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 <code>++</code> and <code>--</code> |
| (consider <code>f(i++)</code> and <code>p[i] = q[++i]</code>) |
| 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, a library for a language whose name contains, ironically, a |
| postfix increment. |
| </p> |
| |
| <h3 id="semicolons"> |
| Why are there braces but no semicolons? And why can't I put the opening |
| brace on the next line?</h3> |
| <p> |
| Go uses brace brackets for statement grouping, a syntax familiar to |
| programmers who have worked with any language in the C family. |
| Semicolons, however, are for parsers, not for people, and we wanted to |
| eliminate them as much as possible. To achieve this goal, Go borrows |
| a trick from BCPL: the semicolons that separate statements are in the |
| formal grammar but are injected automatically, without lookahead, by |
| the lexer at the end of any line that could be the end of a statement. |
| 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. |
| </p> |
| |
| <p> |
| 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 |
| to be formatted automatically by |
| <a href="/cmd/gofmt/"><code>gofmt</code></a>, |
| <i>some</i> style must be chosen. That style may differ from what |
| you've used in C or Java, but Go is a new language and |
| <code>gofmt</code>'s style is as good as any other. More |
| important—much more important—the advantages of a single, |
| programmatically mandated format for all Go programs greatly outweigh |
| any perceived disadvantages of the particular style. |
| Note too that Go's style means that an interactive implementation of |
| Go can use the standard syntax one line at a time without special rules. |
| </p> |
| |
| <h3 id="garbage_collection"> |
| Why do garbage collection? Won't it be too expensive?</h3> |
| <p> |
| One of the biggest sources of bookkeeping in systems programs is |
| memory management. We feel it's critical to eliminate that |
| programmer overhead, and advances in garbage collection |
| technology in the last few years give us confidence that we can |
| implement it with low enough overhead and no significant |
| latency. |
| </p> |
| |
| <p> |
| Another point is that a large part of the difficulty of concurrent |
| and multi-threaded programming is memory management; |
| as objects get passed among threads it becomes cumbersome |
| to guarantee they become freed safely. |
| Automatic garbage collection makes concurrent code far easier to write. |
| Of course, implementing garbage collection in a concurrent environment is |
| itself a challenge, but meeting it once rather than in every |
| program helps everyone. |
| </p> |
| |
| <p> |
| Finally, concurrency aside, garbage collection makes interfaces |
| simpler because they don't need to specify how memory is managed across them. |
| </p> |
| |
| <p> |
| The current implementation is a parallel mark-and-sweep |
| collector but a future version might take a different approach. |
| </p> |
| |
| <p> |
| On the topic of performance, keep in mind that Go gives the programmer |
| considerable control over memory layout and allocation, much more than |
| is typical in garbage-collected languages. A careful programmer can reduce |
| the garbage collection overhead dramatically by using the language well; |
| see the article about |
| <a href="http://blog.golang.org/2011/06/profiling-go-programs.html">profiling |
| Go programs</a> for a worked example, including a demonstration of Go's |
| profiling tools. |
| </p> |