diff options
Diffstat (limited to 'go/golang/go/doc/go_faq.html')
| -rw-r--r-- | go/golang/go/doc/go_faq.html | 2455 |
1 files changed, 2455 insertions, 0 deletions
diff --git a/go/golang/go/doc/go_faq.html b/go/golang/go/doc/go_faq.html new file mode 100644 index 00000000..b1c15295 --- /dev/null +++ b/go/golang/go/doc/go_faq.html @@ -0,0 +1,2455 @@ +<!--{ + "Title": "Frequently Asked Questions (FAQ)", + "Path": "/doc/faq" +}--> + +<h2 id="Origins">Origins</h2> + +<h3 id="What_is_the_purpose_of_the_project"> +What is the purpose of the project?</h3> + +<p> +At the time of Go's inception, only a decade ago, the programming world was different from today. +Production software was usually written in C++ or Java, +GitHub did not exist, most computers were not yet multiprocessors, +and other than Visual Studio and Eclipse there were few IDEs or other high-level tools available +at all, let alone for free on the Internet. +</p> + +<p> +Meanwhile, we had become frustrated by the undue complexity required to use +the languages we worked with to develop server software. +Computers had become enormously quicker since languages such as +C, C++ and Java were first developed but the act of programming had not +itself advanced nearly as much. +Also, it was clear that multiprocessors were becoming universal but +most languages offered little help to program them efficiently +and safely. +</p> + +<p> +We decided to take a step back and think about what major issues were +going to dominate software engineering in the years ahead as technology +developed, and how a new language might help address them. +For instance, the rise of multicore CPUs argued that a language should +provide first-class support for some sort of concurrency or parallelism. +And to make resource management tractable in a large concurrent program, +garbage collection, or at least some sort of safe automatic memory management was required. +</p> + +<p> +These considerations led to +<a href="https://commandcenter.blogspot.com/2017/09/go-ten-years-and-climbing.html">a +series of discussions</a> from which Go arose, first as a set of ideas and +desiderata, then as a language. +An overarching goal was that Go do more to help the working programmer +by enabling tooling, automating mundane tasks such as code formatting, +and removing obstacles to working on large code bases. +</p> + +<p> +A much more expansive description of the goals of Go and how +they are met, or at least approached, is available in the article, +<a href="//talks.golang.org/2012/splash.article">Go at Google: +Language Design in the Service of Software Engineering</a>. +</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. +Countless people from the community have contributed ideas, discussions, and code. +</p> + +<p> +There are now millions of Go programmers—gophers—around the world, +and there are more every day. +Go's success has far exceeded our expectations. +</p> + +<h3 id="gopher"> +What's the origin of the gopher mascot?</h3> + +<p> +The mascot and logo were designed by +<a href="https://reneefrench.blogspot.com">Renée French</a>, who also designed +<a href="https://9p.io/plan9/glenda.html">Glenda</a>, +the Plan 9 bunny. +A <a href="https://blog.golang.org/gopher">blog post</a> +about the gopher explains how it was +derived from one she used for a <a href="https://wfmu.org/">WFMU</a> +T-shirt design some years ago. +The logo and mascot are covered by the +<a href="https://creativecommons.org/licenses/by/3.0/">Creative Commons Attribution 3.0</a> +license. +</p> + +<p> +The gopher has a +<a href="/doc/gopher/modelsheet.jpg">model sheet</a> +illustrating his characteristics and how to represent them correctly. +The model sheet was first shown in a +<a href="https://www.youtube.com/watch?v=4rw_B4yY69k">talk</a> +by Renée at Gophercon in 2016. +He has unique features; he's the <em>Go gopher</em>, not just any old gopher. +</p> + +<h3 id="creating_a_new_language"> +Why did you create a new language?</h3> + +<p> +Go was born out of frustration with existing languages and +environments for the work we were doing at Google. +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> +We were not alone in our concerns. +After many years with a pretty quiet landscape for programming languages, +Go was among the first of several new languages—Rust, +Elixir, Swift, and more—that have made programming language development +an active, almost mainstream field again. +</p> + +<p> +Go addressed these issues by attempting 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 aimed to be modern, with support for networked and multicore +computing. Finally, working with Go 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> + +<p> +The article <a href="//talks.golang.org/2012/splash.article">Go at Google</a> +discusses the background and motivation behind the design of the Go language, +as well as providing more detail about many of the answers presented in this FAQ. +</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> +When Go was designed, Java and C++ were the most commonly +used languages for writing servers, at least at Google. +We felt that these languages required +too much bookkeeping and repetition. +Some programmers reacted by moving towards more dynamic, +fluid languages like Python, at the cost of efficiency and +type safety. +We felt it should be possible to have the efficiency, +the safety, and the fluidity in a single language. +</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="internal_usage"> +Is Google using Go internally?</h3> + +<p> +Yes. Go is used widely in production inside Google. +One easy example is the server behind +<a href="//golang.org">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> + +<p> +A more significant instance is Google's download server, <code>dl.google.com</code>, +which delivers Chrome binaries and other large installables such as <code>apt-get</code> +packages. +</p> + +<p> +Go is not the only language used at Google, far from it, but it is a key language +for a number of areas including +<a href="https://talks.golang.org/2013/go-sreops.slide">site reliability +engineering (SRE)</a> +and large-scale data processing. +</p> + +<h3 id="external_usage"> +What other companies use Go?</h3> + +<p> +Go usage is growing worldwide, especially but by no means exclusively +in the cloud computing space. +A couple of major cloud infrastructure projects written in Go are +Docker and Kubernetes, +but there are many more. +</p> + +<p> +It's not just cloud, though. +The Go Wiki includes a +<a href="https://github.com/golang/go/wiki/GoUsers">page</a>, +updated regularly, that lists some of the many companies using Go. +</p> + +<p> +The Wiki also has a page with links to +<a href="https://github.com/golang/go/wiki/SuccessStories">success stories</a> +about companies and projects that are using the language. +</p> + +<h3 id="Do_Go_programs_link_with_Cpp_programs"> +Do Go programs link with C/C++ programs?</h3> + +<p> +It is possible to use C and Go together in the same address space, +but it is not a natural fit and can require special interface software. +Also, linking C with Go code gives up the memory +safety and stack management properties that Go provides. +Sometimes it's absolutely necessary to use C libraries to solve a problem, +but doing so always introduces an element of risk not present with +pure Go code, so do so with care. +</p> + +<p> +If you do need to use C with Go, how to proceed depends on the Go +compiler implementation. +There are three Go compiler implementations supported by the +Go team. +These are <code>gc</code>, the default compiler, +<code>gccgo</code>, which uses the GCC back end, +and a somewhat less mature <code>gollvm</code>, which uses the LLVM infrastructure. +</p> + +<p> +<code>Gc</code> uses a different calling convention and linker from C and +therefore cannot be called directly from C programs, or vice versa. +The <a href="/cmd/cgo/"><code>cgo</code></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> + +<p> +You can also use <code>cgo</code> and SWIG with <code>Gccgo</code> and <code>gollvm</code>. +Since they use a traditional API, it's also possible, with great care, +to link code from these compilers directly with GCC/LLVM-compiled C or C++ programs. +However, doing so safely requires an understanding of the calling conventions for +all languages concerned, as well as concern for stack limits when calling C or C++ +from Go. +</p> + +<h3 id="ide"> +What IDEs does Go support?</h3> + +<p> +The Go project does not include a custom IDE, but the language and +libraries have been designed to make it easy to analyze source code. +As a consequence, most well-known editors and IDEs support Go well, +either directly or through a plugin. +</p> + +<p> +The list of well-known IDEs and editors that have good Go support +available includes Emacs, Vim, VSCode, Atom, Eclipse, Sublime, IntelliJ +(through a custom variant called Goland), and many more. +Chances are your favorite environment is a productive one for +programming in Go. +</p> + +<h3 id="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="//github.com/golang/protobuf">github.com/golang/protobuf/</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="//golang.org/">golang.org</a>), +you will need to abide by the guidelines at +<a href="//www.google.com/permissions/guidelines.html">www.google.com/permissions/guidelines.html</a> +</p> + +<h2 id="Design">Design</h2> + +<h3 id="runtime"> +Does Go have a runtime?</h3> + +<p> +Go does have an extensive library, called the <em>runtime</em>, +that is part of every Go program. +The runtime library implements garbage collection, concurrency, +stack management, and other critical features of the Go language. +Although it is more central to the language, Go's runtime is analogous +to <code>libc</code>, the C library. +</p> + +<p> +It is important to understand, however, that Go's runtime does not +include a virtual machine, such as is provided by the Java runtime. +Go programs are compiled ahead of time to native machine code +(or JavaScript or WebAssembly, for some variant implementations). +Thus, although the term is often used to describe the virtual +environment in which a program runs, in Go the word “runtime” +is just the name given to the library providing critical language services. +</p> + +<h3 id="unicode_identifiers"> +What's up with Unicode identifiers?</h3> + +<p> +When designing Go, we wanted to make sure that it was not +overly ASCII-centric, +which meant extending the space of identifiers from the +confines of 7-bit 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, +and that excludes some languages such as Devanagari. +</p> + +<p> +This rule has one other unfortunate consequence. +Since an exported identifier must begin with an +upper-case letter, identifiers created from characters +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. +</p> + +<p> +Since the earliest version of the language, there has been considerable +thought into how best to expand the identifier space to accommodate +programmers using other native languages. +Exactly what to do remains an active topic of discussion, and a future +version of the language may be more liberal in its definition +of an identifier. +For instance, it might adopt some of the ideas from the Unicode +organization's <a href="http://unicode.org/reports/tr31/">recommendations</a> +for identifiers. +Whatever happens, it must be done compatibly while preserving +(or perhaps expanding) the way letter case determines visibility of +identifiers, which remains one of our favorite features of Go. +</p> + +<p> +For the time being, 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> + +<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> +Go was intended as a language for writing server programs that would be +easy to maintain over time. +(See <a href="https://talks.golang.org/2012/splash.article">this +article</a> for more background.) +The design concentrated on things like scalability, readability, and +concurrency. +Polymorphic programming did not seem essential to the language's +goals at the time, and so was left out for simplicity. +</p> + +<p> +The language is more mature now, and there is scope to consider +some form of generic programming. +However, there remain some caveats. +</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> +The topic remains open. +For a look at several previous unsuccessful attempts to +design a good generics solution for Go, see +<a href="https://golang.org/issue/15292">this proposal</a>. +</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. +Also, the <a href="https://blog.golang.org/errors-are-values">Errors are values</a> blog post +describes one approach to handling errors cleanly in Go by demonstrating that, +since errors are just values, the full power of Go can deployed in error handling. +</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 to operate instead of crashing after a non-fatal error. +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 over time +developed a reputation for difficulty. We believe this is due partly to complex +designs such as +<a href="https://en.wikipedia.org/wiki/POSIX_Threads">pthreads</a> +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. +Experience with several earlier languages has shown that the CSP model +fits well into a procedural language framework. +</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: they have little +overhead beyond the memory for the stack, which is just a few kilobytes. +</p> + +<p> +To make the stacks small, Go's run-time uses resizable, bounded stacks. A newly +minted goroutine is given a few kilobytes, which is almost always enough. +When it isn't, the run-time grows (and shrinks) the memory for storing +the stack automatically, allowing many goroutines to live in a modest +amount of memory. +The CPU 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 goroutines, 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> + +<p> +Map access is unsafe only when updates are occurring. +As long as all goroutines are only reading—looking up elements in the map, +including iterating through it using a +<code>for</code> <code>range</code> loop—and not changing the map +by assigning to elements or doing deletions, +it is safe for them to access the map concurrently without synchronization. +</p> + +<p> +As an aid to correct map use, some implementations of the language +contain a special check that automatically reports at run time when a map is modified +unsafely by concurrent execution. +</p> + +<h3 id="language_changes"> +Will you accept my language change?</h3> + +<p> +People often suggest improvements to the language—the +<a href="//groups.google.com/group/golang-nuts">mailing list</a> +contains a rich history of such discussions—but very few of these changes have +been accepted. +</p> + +<p> +Although Go is an open source project, the language and libraries are protected +by a <a href="/doc/go1compat.html">compatibility promise</a> that prevents +changes that break existing programs, at least at the source code level +(programs may need to be recompiled occasionally to stay current). +If your proposal violates the Go 1 specification we cannot even entertain the +idea, regardless of its merit. +A future major release of Go may be incompatible with Go 1, but discussions +on that topic have only just begun and one thing is certain: +there will be very few such incompatibilities introduced in the process. +Moreover, the compatibility promise encourages us to provide an automatic path +forward for old programs to adapt should that situation arise. +</p> + +<p> +Even if your proposal is compatible with the Go 1 spec, it might +not be in the spirit of Go's design goals. +The article <i><a href="//talks.golang.org/2012/splash.article">Go +at Google: Language Design in the Service of Software Engineering</a></i> +explains Go's origins and the motivation behind its design. +</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 a 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 +needing to modify existing code. It enables a kind of +<a href="https://en.wikipedia.org/wiki/Structural_type_system">structural typing</a> 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 using the zero value for +<code>T</code> or pointer to <code>T</code>, as appropriate: +</p> + +<pre> +type T struct{} +var _ I = T{} // Verify that T implements I. +var _ I = (*T)(nil) // Verify that *T implements I. +</pre> + +<p> +If <code>T</code> (or <code>*T</code>, accordingly) 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() 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 polymorphic +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. +It is disallowed by the language specification because the two types +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="convert_slice_with_same_underlying_type"> +Can I convert []T1 to []T2 if T1 and T2 have the same underlying type?</h3> + +This last line of this code sample does not compile. + +<pre> +type T1 int +type T2 int +var t1 T1 +var x = T2(t1) // OK +var st1 []T1 +var sx = ([]T2)(st1) // NOT OK +</pre> + +<p> +In Go, types are closely tied to methods, in that every named type has +a (possibly empty) method set. +The general rule is that you can change the name of the type being +converted (and thus possibly change its method set) but you can't +change the name (and method set) of elements of a composite type. +Go requires you to be explicit about type conversions. +</p> + +<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 <code>T</code> +and a value <code>V</code>. +<code>V</code> is a concrete value such as an <code>int</code>, +<code>struct</code> or pointer, never an interface itself, and has +type <code>T</code>. +For instance, if we store the <code>int</code> value 3 in an interface, +the resulting interface value has, schematically, +(<code>T=int</code>, <code>V=3</code>). +The value <code>V</code> is also known as the interface's +<em>dynamic</em> value, +since a given interface variable might hold different values <code>V</code> +(and corresponding types <code>T</code>) +during the execution of the program. +</p> + +<p> +An interface value is <code>nil</code> only if the <code>V</code> and <code>T</code> +are both unset, (<code>T=nil</code>, <code>V</code> is not set), +In particular, a <code>nil</code> interface will always hold a <code>nil</code> type. +If we store a <code>nil</code> 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>T=*int</code>, <code>V=nil</code>). +Such an interface value will therefore be non-<code>nil</code> +<em>even when the pointer value <code>V</code> inside is</em> <code>nil</code>. +</p> + +<p> +This situation can be confusing, and 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>T=*MyError</code>, <code>V=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> + +<h3 id="covariant_types"> +Why does Go not have covariant result types?</h3> + +<p> +Covariant result types would mean that an interface like +</p> + +<pre> +type Copyable interface { + Copy() interface{} +} +</pre> + +<p> +would be satisfied by the method +</p> + +<pre> +func (v Value) Copy() Value +</pre> + +<p>because <code>Value</code> implements the empty interface. +In Go method types must match exactly, so <code>Value</code> does not +implement <code>Copyable</code>. +Go separates the notion of what a +type does—its methods—from the type's implementation. +If two methods return different types, they are not doing the same thing. +Programmers who want covariant result types are often trying to +express a type hierarchy through interfaces. +In Go it's more natural to have a clean separation between interface +and implementation. +</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="constants"> +How do constants work in Go?</h3> + +<p> +Although Go is strict about conversion between variables of different +numeric types, constants in the language are much more flexible. +Literal constants such as <code>23</code>, <code>3.14159</code> +and <a href="/pkg/math/#pkg-constants"><code>math.Pi</code></a> +occupy a sort of ideal number space, with arbitrary precision and +no overflow or underflow. +For instance, the value of <code>math.Pi</code> is specified to 63 places +in the source code, and constant expressions involving the value keep +precision beyond what a <code>float64</code> could hold. +Only when the constant or constant expression is assigned to a +variable—a memory location in the program—does +it become a "computer" number with +the usual floating-point properties and precision. +</p> + +<p> +Also, +because they are just numbers, not typed values, constants in Go can be +used more freely than variables, thereby softening some of the awkwardness +around the strict conversion rules. +One can write expressions such as +</p> + +<pre> +sqrt2 := math.Sqrt(2) +</pre> + +<p> +without complaint from the compiler because the ideal number <code>2</code> +can be converted safely and accurately +to a <code>float64</code> for the call to <code>math.Sqrt</code>. +</p> + +<p> +A blog post titled <a href="https://blog.golang.org/constants">Constants</a> +explores this topic in more detail. +</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. Changing these +types to act as references to the associated, shared data structures resolved +these issues. This change added some regrettable complexity to the +language but had a large effect on usability: Go became a more +productive, comfortable language when it was 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 and serves it as a web +page with links to declarations, files, and so on. +An instance is running at +<a href="/pkg/">golang.org/pkg/</a>. +In fact, <code>godoc</code> implements the full site at +<a href="/">golang.org/</a>. +</p> + +<p> +A <code>godoc</code> instance may be configured to provide rich, +interactive static analyses of symbols in the programs it displays; details are +listed <a href="https://golang.org/lib/godoc/analysis/help.html">here</a>. +</p> + +<p> +For access to documentation from the command line, the +<a href="https://golang.org/pkg/cmd/go/">go</a> tool has a +<a href="https://golang.org/pkg/cmd/go/#hdr-Show_documentation_for_package_or_symbol">doc</a> +subcommand that provides a textual interface to the same information. +</p> + +<h3 id="Is_there_a_Go_programming_style_guide"> +Is there a Go programming style guide?</h3> + +<p> +There is no explicit style guide, although there is certainly +a recognizable "Go style". +</p> + +<p> +Go has established conventions to guide decisions around +naming, layout, and file organization. +The document <a href="effective_go.html">Effective Go</a> +contains some advice on these topics. +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, and the vast majority in the +open source world, has been run through <code>gofmt</code>. +</p> + +<p> +The document titled +<a href="//golang.org/s/comments">Go Code Review Comments</a> +is a collection of very short essays about details of Go idiom that are often +missed by programmers. +It is a handy reference for people doing code reviews for Go projects. +</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 the <code>src</code> directory of the repository. +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="git_https"> +Why does "go get" use HTTPS when cloning a repository?</h3> + +<p> +Companies often permit outgoing traffic only on the standard TCP ports 80 (HTTP) +and 443 (HTTPS), blocking outgoing traffic on other ports, including TCP port 9418 +(git) and TCP port 22 (SSH). +When using HTTPS instead of HTTP, <code>git</code> enforces certificate validation by +default, providing protection against man-in-the-middle, eavesdropping and tampering attacks. +The <code>go get</code> command therefore uses HTTPS for safety. +</p> + +<p> +<code>Git</code> can be configured to authenticate over HTTPS or to use SSH in place of HTTPS. +To authenticate over HTTPS, you can add a line +to the <code>$HOME/.netrc</code> file that git consults: +</p> +<pre> +machine github.com login <i>USERNAME</i> password <i>APIKEY</i> +</pre> +<p> +For GitHub accounts, the password can be a +<a href="https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line/">personal access token</a>. +</p> + +<p> +<code>Git</code> can also be configured to use SSH in place of HTTPS for URLs matching a given prefix. +For example, to use SSH for all GitHub access, +add these lines to your <code>~/.gitconfig</code>: +</p> +<pre> +[url "ssh://git@github.com/"] + insteadOf = https://github.com/ +</pre> + +<h3 id="get_version"> +How should I manage package versions using "go get"?</h3> + +<p> +Since the inception of the project, Go has had no explicit concept of package versions, +but that is changing. +Versioning is a source of significant complexity, especially in large code bases, +and it has taken some time to develop an +approach that works well at scale in a large enough +variety of situations to be appropriate to supply to all Go users. +</p> + +<p> +The Go 1.11 release adds new, experimental support +for package versioning to the <code>go</code> command, +in the form of Go modules. +For more information, see the <a href="/doc/go1.11#modules">Go 1.11 release notes</a> +and the <a href="/cmd/go#hdr-Modules__module_versions__and_more"><code>go</code> command documentation</a>. +</p> + +<p> +Regardless of the actual package management technology, +"go get" and the larger Go toolchain does provide isolation of +packages with different import paths. +For example, the standard library's <code>html/template</code> and <code>text/template</code> +coexist even though both are "package template". +This observation leads to some advice for package authors and package users. +</p> + +<p> +Packages intended for public use should try to maintain backwards compatibility as they evolve. +The <a href="/doc/go1compat.html">Go 1 compatibility guidelines</a> are a good reference here: +don't remove exported names, encourage tagged composite literals, and so on. +If different functionality is required, add a new name instead of changing an old one. +If a complete break is required, create a new package with a new import path. +</p> + +<p> +If you're using an externally supplied package and worry that it might change in +unexpected ways, but are not yet using Go modules, +the simplest solution is to copy it to your local repository. +This is the approach Google takes internally and is supported by the +<code>go</code> command through a technique called "vendoring". +This involves +storing a copy of the dependency under a new import path that identifies it as a local copy. +See the <a href="https://golang.org/s/go15vendor">design +document</a> for details. +</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 a <a href="/doc/faq#methods_on_values_or_pointers">later +section</a> 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> + +<p> +Note that this discussion is about the semantics of the operations. +Actual implementations may apply optimizations to avoid copying +as long as the optimizations do not change the semantics. +</p> + +<h3 id="pointer_to_interface"> +When should I use a pointer to an interface?</h3> + +<p> +Almost never. Pointers to interface values arise only in rare, tricky situations involving +disguising an interface value's type for delayed evaluation. +</p> + +<p> +It is a common mistake to pass a pointer to an interface value +to a function expecting an interface. The compiler will complain about this +error but the situation can still be confusing, because sometimes a +<a href="#different_method_sets">pointer +is necessary to satisfy an interface</a>. +The insight is that although a pointer to a concrete type can satisfy +an interface, with one exception <em>a pointer to an interface can never satisfy an interface</em>. +</p> + +<p> +Consider the variable declaration, +</p> + +<pre> +var w io.Writer +</pre> + +<p> +The printing function <code>fmt.Fprintf</code> takes as its first argument +a value that satisfies <code>io.Writer</code>—something that implements +the canonical <code>Write</code> method. Thus we can write +</p> + +<pre> +fmt.Fprintf(w, "hello, world\n") +</pre> + +<p> +If however we pass the address of <code>w</code>, the program will not compile. +</p> + +<pre> +fmt.Fprintf(&w, "hello, world\n") // Compile-time error. +</pre> + +<p> +The one exception is that any value, even a pointer to an interface, can be assigned to +a variable of empty interface type (<code>interface{}</code>). +Even so, it's almost certainly a mistake if the value is a pointer to an interface; +the result can be confusing. +</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 act as references, 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, in Java method receivers are always pointers, +although their pointer nature is somewhat disguised +(and there is a proposal to add value receivers to the language). +It is the value receivers in Go 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, while <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"> +What is the size of an <code>int</code> on a 64 bit machine?</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. +For portability, code that relies on a particular +size of value should use an explicitly sized type, like <code>int64</code>. +On 32-bit machines the compilers use 32-bit integers by default, +while on 64-bit machines integers have 64 bits. +(Historically, this was not always true.) +</p> + +<p> +On the other hand, floating-point scalars and complex +types are always sized (there are no <code>float</code> or <code>complex</code> basic types), +because programmers should be aware of precision when using floating-point numbers. +The default type used for an (untyped) floating-point constant is <code>float64</code>. +Thus <code>foo</code> <code>:=</code> <code>3.0</code> declares a variable <code>foo</code> +of type <code>float64</code>. +For a <code>float32</code> variable initialized by an (untyped) constant, the variable type +must be specified explicitly in the variable declaration: +</p> + +<pre> +var foo float32 = 3.0 +</pre> + +<p> +Alternatively, the constant must be given a type with a conversion as in +<code>foo := float32(3.0)</code>. +</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> + +<h3 id="Why_does_my_Go_process_use_so_much_virtual_memory"> +Why does my Go process use so much virtual memory?</h3> + +<p> +The Go memory allocator reserves a large region of virtual memory as an arena +for allocations. This virtual memory is local to the specific Go process; the +reservation does not deprive other processes of memory. +</p> + +<p> +To find the amount of actual memory allocated to a Go process, use the Unix +<code>top</code> command and consult the <code>RES</code> (Linux) or +<code>RSIZE</code> (macOS) columns. +<!-- TODO(adg): find out how this works on Windows --> +</p> + +<h2 id="Concurrency">Concurrency</h2> + +<h3 id="What_operations_are_atomic_What_about_mutexes"> +What operations are atomic? What about mutexes?</h3> + +<p> +A description of the atomicity of operations in Go can be found in +the <a href="/ref/mem">Go Memory Model</a> document. +</p> + +<p> +Low-level synchronization and atomic primitives are available in the +<a href="/pkg/sync">sync</a> and +<a href="/pkg/sync/atomic">sync/atomic</a> +packages. +These packages are good for simple tasks such as incrementing +reference counts or guaranteeing small-scale mutual exclusion. +</p> + +<p> +For higher-level operations, such as coordination among +concurrent servers, higher-level techniques can lead +to nicer programs, and Go supports this approach through +its goroutines and channels. +For instance, you can structure your program so that only one +goroutine at a time is ever responsible for a particular piece of data. +That approach is summarized by the original +<a href="https://www.youtube.com/watch?v=PAAkCSZUG1c">Go proverb</a>, +</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="https://blog.golang.org/2010/07/share-memory-by-communicating.html"> +associated article</a> for a detailed discussion of this concept. +</p> + +<p> +Large concurrent programs are likely to borrow from both these toolkits. +</p> + +<h3 id="parallel_slow"> +Why doesn't my program run faster with more CPUs?</h3> + +<p> +Whether a program runs faster with more CPUs depends on the problem +it is solving. +The Go language provides concurrency primitives, such as goroutines +and channels, but concurrency only enables parallelism +when the underlying problem is intrinsically parallel. +Problems that are intrinsically sequential cannot be sped up by adding +more CPUs, while those that can be broken into pieces that can +execute in parallel can be sped up, sometimes dramatically. +</p> + +<p> +Sometimes adding more CPUs can slow a program down. +In practical terms, programs that spend more time +synchronizing or communicating than doing useful computation +may experience performance degradation when using +multiple OS threads. +This is because passing data between threads involves switching +contexts, which has significant cost, and that cost can increase +with more CPUs. +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 the number of threads (CPUs) is more likely to slow it down than +to speed it up. +</p> + +<p> +For more detail on this topic see the talk entitled +<a href="//blog.golang.org/2013/01/concurrency-is-not-parallelism.html">Concurrency +is not Parallelism</a>. + +<h3 id="number_cpus"> +How can I control the number of CPUs?</h3> + +<p> +The number of CPUs available simultaneously to executing goroutines is +controlled by the <code>GOMAXPROCS</code> shell environment variable, +whose default value is the number of CPU cores available. +Programs with the potential for parallel execution should therefore +achieve it by default on a multiple-CPU machine. +To change the number of parallel CPUs to use, +set the environment variable or use the similarly-named +<a href="/pkg/runtime/#GOMAXPROCS">function</a> +of the runtime package to configure the +run-time support to utilize a different number of threads. +Setting it to 1 eliminates the possibility of true parallelism, +forcing independent goroutines to take turns executing. +</p> + +<p> +The runtime can allocate more threads than the value +of <code>GOMAXPROCS</code> to service multiple outstanding +I/O requests. +<code>GOMAXPROCS</code> only affects how many goroutines +can actually execute at once; arbitrarily more may be blocked +in system calls. +</p> + +<p> +Go's goroutine scheduler is not as good as it needs to be, although it +has improved over time. +In the future, it may better optimize its use of OS threads. +For now, if there are performance issues, +setting <code>GOMAXPROCS</code> on a per-application basis may help. +</p> + + +<h3 id="no_goroutine_id"> +Why is there no goroutine ID?</h3> + +<p> +Goroutines do not have names; they are just anonymous workers. +They expose no unique identifier, name, or data structure to the programmer. +Some people are surprised by this, expecting the <code>go</code> +statement to return some item that can be used to access and control +the goroutine later. +</p> + +<p> +The fundamental reason goroutines are anonymous is so that +the full Go language is available when programming concurrent code. +By contrast, the usage patterns that develop when threads and goroutines are +named can restrict what a library using them can do. +</p> + +<p> +Here is an illustration of the difficulties. +Once one names a goroutine and constructs a model around +it, it becomes special, and one is tempted to associate all computation +with that goroutine, ignoring the possibility +of using multiple, possibly shared goroutines for the processing. +If the <code>net/http</code> package associated per-request +state with a goroutine, +clients would be unable to use more goroutines +when serving a request. +</p> + +<p> +Moreover, experience with libraries such as those for graphics systems +that require all processing to occur on the "main thread" +has shown how awkward and limiting the approach can be when +deployed in a concurrent language. +The very existence of a special thread or goroutine forces +the programmer to distort the program to avoid crashes +and other problems caused by inadvertently operating +on the wrong thread. +</p> + +<p> +For those cases where a particular goroutine is truly special, +the language provides features such as channels that can be +used in flexible ways to interact with it. +</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> +As the <a href="/ref/spec#Types">Go specification</a> says, +the method set of a type <code>T</code> consists of all methods +with receiver type <code>T</code>, +while that of the corresponding pointer +type <code>*T</code> consists of all methods with receiver <code>*T</code> or +<code>T</code>. +That means the method set of <code>*T</code> +includes that of <code>T</code>), +but not the reverse. +</p> + +<p> +This distinction arises because +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 safe way for a method call to obtain a pointer. +(Doing so would allow a method to modify the contents of +the value inside the interface, which is not permitted by +the language specification.) +</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 an example, if the <code>Write</code> method of +<a href="/pkg/bytes/#Buffer"><code>bytes.Buffer</code></a> +used a value receiver rather than a pointer, +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. +To help detect this and other problems before they happen, run +<a href="/cmd/go/#hdr-Run_go_tool_vet_on_packages"><code>go vet</code></a>. +</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> + +<p> +This behavior of the language, not defining a new variable for +each iteration, may have been a mistake in retrospect. +It may be addressed in a later version but, for compatibility, +cannot change in Go version 1. +</p> + +<h2 id="Control_flow">Control flow</h2> + +<h3 id="Does_Go_have_a_ternary_form"> +Why does Go not have the <code>?:</code> operator?</h3> + +<p> +There is no ternary testing operation in Go. +You may use the following to achieve the same +result: +</p> + +<pre> +if expr { + n = trueVal +} else { + n = falseVal +} +</pre> + +<p> +The reason <code>?:</code> is absent from Go is that the language's designers +had seen the operation used too often to create impenetrably complex expressions. +The <code>if-else</code> form, although longer, +is unquestionably clearer. +A language needs only one conditional control flow construct. +</p> + +<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/#hdr-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/fmt/fmt_test.go">the formatting tests for the <code>fmt</code> package</a>. +</p> + +<h3 id="x_in_std"> +Why isn't <i>X</i> in the standard library?</h3> + +<p> +The standard library's purpose is to support the runtime, connect to +the operating system, and provide key functionality that many Go +programs require, such as formatted I/O and networking. +It also contains elements important for web programming, including +cryptography and support for standards like HTTP, JSON, and XML. +</p> + +<p> +There is no clear criterion that defines what is included because for +a long time, this was the <i>only</i> Go library. +There are criteria that define what gets added today, however. +</p> + +<p> +New additions to the standard library are rare and the bar for +inclusion is high. +Code included in the standard library bears a large ongoing maintenance cost +(often borne by those other than the original author), +is subject to the <a href="/doc/go1compat.html">Go 1 compatibility promise</a> +(blocking fixes to any flaws in the API), +and is subject to the Go +<a href="https://golang.org/s/releasesched">release schedule</a>, +preventing bug fixes from being available to users quickly. +</p> + +<p> +Most new code should live outside of the standard library and be accessible +via the <a href="/cmd/go/"><code>go</code> tool</a>'s +<code>go get</code> command. +Such code can have its own maintainers, release cycle, +and compatibility guarantees. +Users can find packages and read their documentation at +<a href="https://godoc.org/">godoc.org</a>. +</p> + +<p> +Although there are pieces in the standard library that don't really belong, +such as <code>log/syslog</code>, we continue to maintain everything in the +library because of the Go 1 compatibility promise. +But we encourage most new code to live elsewhere. +</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> +There are several production compilers for Go, and a number of others +in development for various platforms. +</p> + +<p> +The default compiler, <code>gc</code>, is included with the +Go distribution as part of the support for the <code>go</code> +command. +<code>Gc</code> was originally written in C +because of the difficulties of bootstrapping—you'd need a Go compiler to +set up a Go environment. +But things have advanced and since the Go 1.5 release the compiler has been +a Go program. +The compiler was converted from C to Go using automatic translation tools, as +described in this <a href="/s/go13compiler">design document</a> +and <a href="https://talks.golang.org/2015/gogo.slide#1">talk</a>. +Thus the compiler is now "self-hosting", which means we needed to face +the bootstrapping problem. +The solution is to have a working Go installation already in place, +just as one normally has with a working C installation. +The story of how to bring up a new Go environment from source +is described <a href="/s/go15bootstrap">here</a> and +<a href="/doc/install/source">here</a>. +</p> + +<p> +<code>Gc</code> is written in Go with a recursive descent parser +and uses a custom loader, also written in Go but +based on the Plan 9 loader, to generate ELF/Mach-O/PE binaries. +</p> + +<p> +At the beginning of the project we considered using LLVM for +<code>gc</code> but decided it was too large and slow to meet +our performance goals. +More important in retrospect, starting with LLVM would have made it +harder to introduce some of the ABI and related changes, such as +stack management, that Go requires but not are not part of the +standard C setup. +A new <a href="https://go.googlesource.com/gollvm/">LLVM implementation</a> +is starting to come together now, however. +</p> + +<p> +The <code>Gccgo</code> compiler is a front end written in C++ +with a recursive descent parser coupled to the +standard GCC back end. +</p> + +<p> +Go turned out to be a fine language in which to implement a Go compiler, +although that was not its original goal. +Not being self-hosting from the beginning allowed Go's design to +concentrate on its original use case, which was networked servers. +Had we decided Go should compile itself early on, we might have +ended up with a language targeted more for compiler construction, +which is a worthy goal but not the one we had initially. +</p> + +<p> +Although <code>gc</code> does not use them (yet?), a native lexer and +parser are available in the <a href="/pkg/go/"><code>go</code></a> package +and there is also a native <a href="/pkg/go/types">type checker</a>. +</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 was originally written mostly in C (with a +tiny bit of assembler) but it has since been translated to Go +(except for some assembler bits). +<code>Gccgo</code>'s run-time support uses <code>glibc</code>. +The <code>gccgo</code> compiler implements goroutines using +a technique called segmented stacks, +supported by recent modifications to the gold linker. +<code>Gollvm</code> similarly is built on the corresponding +LLVM infrastructure. +</p> + +<h3 id="Why_is_my_trivial_program_such_a_large_binary"> +Why is my trivial program such a large binary?</h3> + +<p> +The linker in the <code>gc</code> toolchain +creates statically-linked binaries by default. +All Go binaries therefore include the Go +runtime, 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> weighs a couple of megabytes, but that includes +more powerful run-time support and type and debugging information. +</p> + +<p> +A Go program compiled with <code>gc</code> can be linked with +the <code>-ldflags=-w</code> flag to disable DWARF generation, +removing debugging information from the binary but with no +other loss of functionality. +This can reduce the binary size substantially. +</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, +an effect that can become substantial as a program accumulates +code and programmers over time. +For these reasons, Go refuses to compile programs with unused +variables or imports, +trading short-term convenience for long-term build speed and +program clarity. +</p> + +<p> +Still, 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> + +<p> +Nowadays, most Go programmers use a tool, +<a href="https://godoc.org/golang.org/x/tools/cmd/goimports">goimports</a>, +which automatically rewrites a Go source file to have the correct imports, +eliminating the unused imports issue in practice. +This program is easily connected to most editors to run automatically when a Go source file is written. +</p> + +<h3 id="virus"> +Why does my virus-scanning software think my Go distribution or compiled binary is infected?</h3> + +<p> +This is a common occurrence, especially on Windows machines, and is almost always a false positive. +Commercial virus scanning programs are often confused by the structure of Go binaries, which +they don't see as often as those compiled from other languages. +</p> + +<p> +If you've just installed the Go distribution and the system reports it is infected, that's certainly a mistake. +To be really thorough, you can verify the download by comparing the checksum with those on the +<a href="https://golang.org/dl/">downloads page</a>. +</p> + +<p> +In any case, if you believe the report is in error, please report a bug to the supplier of your virus scanner. +Maybe in time virus scanners can learn to understand Go programs. +</p> + +<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="https://go.googlesource.com/exp/+/master/shootout/">golang.org/x/exp/shootout</a>. +The slowest depend on libraries for which versions of comparable performance +are not available in Go. +For instance, <a href="https://go.googlesource.com/exp/+/master/shootout/pidigits.go">pidigits.go</a> +depends on a multi-precision math package, and the C +versions, unlike Go's, use <a href="https://gmplib.org/">GMP</a> (which is +written in optimized assembler). +Benchmarks that depend on regular expressions +(<a href="https://go.googlesource.com/exp/+/master/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="https://go.googlesource.com/exp/+/master/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="//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 different 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 +managing the lifetimes of allocated objects. +In languages such as C in which it is done manually, +it can consume a significant amount of programmer time and is +often the cause of pernicious bugs. +Even in languages like C++ or Rust that provide mechanisms +to assist, those mechanisms can have a significant effect on the +design of the software, often adding programming overhead +of its own. +We felt it was critical to eliminate such +programmer overheads, and advances in garbage collection +technology in the last few years gave us confidence that it +could be implemented cheaply enough, and with low enough +latency, that it could be a viable approach for networked +systems. +</p> + +<p> +Much of the difficulty of concurrent programming +has its roots in the object lifetime problem: +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> +This is not to say that the recent work in languages +like Rust that bring new ideas to the problem of managing +resources is misguided; we encourage this work and are excited to see +how it evolves. +But Go takes a more traditional approach by addressing +object lifetimes through +garbage collection, and garbage collection alone. +</p> + +<p> +The current implementation is a mark-and-sweep collector. +If the machine is a multiprocessor, the collector runs on a separate CPU +core in parallel with the main program. +Major work on the collector in recent years has reduced pause times +often to the sub-millisecond range, even for large heaps, +all but eliminating one of the major objections to garbage collection +in networked servers. +Work continues to refine the algorithm, reduce overhead and +latency further, and to explore new approaches. +The 2018 +<a href="https://talks.golang.org/2018/ismmkeynote">ISMM keynote</a> +by Rick Hudson of the Go team +describes the progress so far and suggests some future approaches. +</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="//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> |