diff options
Diffstat (limited to 'doc/go_faq.html')
| -rw-r--r-- | doc/go_faq.html | 2477 |
1 files changed, 0 insertions, 2477 deletions
diff --git a/doc/go_faq.html b/doc/go_faq.html deleted file mode 100644 index 67dc0b9bd4..0000000000 --- a/doc/go_faq.html +++ /dev/null @@ -1,2477 +0,0 @@ -<!--{ - "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="go_or_golang"> -Is the language called Go or Golang?</h3> - -<p> -The language is called Go. -The "golang" moniker arose because the web site is -<a href="https://golang.org">golang.org</a>, not -go.org, which was not available to us. -Many use the golang name, though, and it is handy as -a label. -For instance, the Twitter tag for the language is "#golang". -The language's name is just plain Go, regardless. -</p> - -<p> -A side note: Although the -<a href="https://blog.golang.org/go-brand">official logo</a> -has two capital letters, the language name is written Go, not GO. -</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> -A <a href="https://golang.org/issue/43651">language proposal -implementing a form of generic types</a> has been accepted for -inclusion in the language. -If all goes well it will be available in the Go 1.18 release. -</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 be 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/go/#hdr-Show_documentation_for_package_or_symbol">go doc</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 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://blog.golang.org/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> |