mirror of
https://github.com/golang/go
synced 2024-09-04 23:44:16 +00:00
![James Craig Burley](/assets/img/avatar_default.png)
Change-Id: I956d6d1dbf8516cb65eb3a0686a3b0584b4a6840
GitHub-Last-Rev: 1c928f3c67
GitHub-Pull-Request: golang/go#28991
Reviewed-on: https://go-review.googlesource.com/c/151324
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2476 lines
88 KiB
HTML
2476 lines
88 KiB
HTML
<!--{
|
|
"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>
|
|
Generics may well be added at some point. We don't feel an urgency for
|
|
them, although we understand some programmers do.
|
|
</p>
|
|
|
|
<p>
|
|
Go was intended as a language for writing server programs that would be
|
|
easy to maintain over time.
|
|
(See <a href="https://talks.golang.org/2012/splash.article">this
|
|
article</a> for more background.)
|
|
The design concentrated on things like scalability, readability, and
|
|
concurrency.
|
|
Polymorphic programming did not seem essential to the language's
|
|
goals at the time, and so was left out for simplicity.
|
|
</p>
|
|
|
|
<p>
|
|
The language is more mature now, and there is scope to consider
|
|
some form of generic programming.
|
|
However, there remain some caveats.
|
|
</p>
|
|
|
|
<p>
|
|
Generics are convenient but they come at a cost in
|
|
complexity in the type system and run-time. We haven't yet found a
|
|
design that gives value proportionate to the complexity, although we
|
|
continue to think about it. Meanwhile, Go's built-in maps and slices,
|
|
plus the ability to use the empty interface to construct containers
|
|
(with explicit unboxing) mean in many cases it is possible to write
|
|
code that does what generics would enable, if less smoothly.
|
|
</p>
|
|
|
|
<p>
|
|
The topic remains open.
|
|
For a look at several previous unsuccessful attempts to
|
|
design a good generics solution for Go, see
|
|
<a href="https://golang.org/issue/15292">this proposal</a>.
|
|
</p>
|
|
|
|
<h3 id="exceptions">
|
|
Why does Go not have exceptions?</h3>
|
|
<p>
|
|
We believe that coupling exceptions to a control
|
|
structure, as in the <code>try-catch-finally</code> idiom, results in
|
|
convoluted code. It also tends to encourage programmers to label
|
|
too many ordinary errors, such as failing to open a file, as
|
|
exceptional.
|
|
</p>
|
|
|
|
<p>
|
|
Go takes a different approach. For plain error handling, Go's multi-value
|
|
returns make it easy to report an error without overloading the return value.
|
|
<a href="/doc/articles/error_handling.html">A canonical error type, coupled
|
|
with Go's other features</a>, makes error handling pleasant but quite different
|
|
from that in other languages.
|
|
</p>
|
|
|
|
<p>
|
|
Go also has a couple
|
|
of built-in functions to signal and recover from truly exceptional
|
|
conditions. The recovery mechanism is executed only as part of a
|
|
function's state being torn down after an error, which is sufficient
|
|
to handle catastrophe but requires no extra control structures and,
|
|
when used well, can result in clean error-handling code.
|
|
</p>
|
|
|
|
<p>
|
|
See the <a href="/doc/articles/defer_panic_recover.html">Defer, Panic, and Recover</a> article for details.
|
|
Also, the <a href="https://blog.golang.org/errors-are-values">Errors are values</a> blog post
|
|
describes one approach to handling errors cleanly in Go by demonstrating that,
|
|
since errors are just values, the full power of Go can deployed in error handling.
|
|
</p>
|
|
|
|
<h3 id="assertions">
|
|
Why does Go not have assertions?</h3>
|
|
|
|
<p>
|
|
Go doesn't provide assertions. They are undeniably convenient, but our
|
|
experience has been that programmers use them as a crutch to avoid thinking
|
|
about proper error handling and reporting. Proper error handling means that
|
|
servers continue to operate instead of crashing after a non-fatal error.
|
|
Proper error reporting means that errors are direct and to the point,
|
|
saving the programmer from interpreting a large crash trace. Precise
|
|
errors are particularly important when the programmer seeing the errors is
|
|
not familiar with the code.
|
|
</p>
|
|
|
|
<p>
|
|
We understand that this is a point of contention. There are many things in
|
|
the Go language and libraries that differ from modern practices, simply
|
|
because we feel it's sometimes worth trying a different approach.
|
|
</p>
|
|
|
|
<h3 id="csp">
|
|
Why build concurrency on the ideas of CSP?</h3>
|
|
<p>
|
|
Concurrency and multi-threaded programming have over time
|
|
developed a reputation for difficulty. We believe this is due partly to complex
|
|
designs such as
|
|
<a href="https://en.wikipedia.org/wiki/POSIX_Threads">pthreads</a>
|
|
and partly to overemphasis on low-level details
|
|
such as mutexes, condition variables, and memory barriers.
|
|
Higher-level interfaces enable much simpler code, even if there are still
|
|
mutexes and such under the covers.
|
|
</p>
|
|
|
|
<p>
|
|
One of the most successful models for providing high-level linguistic support
|
|
for concurrency comes from Hoare's Communicating Sequential Processes, or CSP.
|
|
Occam and Erlang are two well known languages that stem from CSP.
|
|
Go's concurrency primitives derive from a different part of the family tree
|
|
whose main contribution is the powerful notion of channels as first class objects.
|
|
Experience with several earlier languages has shown that the CSP model
|
|
fits well into a procedural language framework.
|
|
</p>
|
|
|
|
<h3 id="goroutines">
|
|
Why goroutines instead of threads?</h3>
|
|
<p>
|
|
Goroutines are part of making concurrency easy to use. The idea, which has
|
|
been around for a while, is to multiplex independently executing
|
|
functions—coroutines—onto a set of threads.
|
|
When a coroutine blocks, such as by calling a blocking system call,
|
|
the run-time automatically moves other coroutines on the same operating
|
|
system thread to a different, runnable thread so they won't be blocked.
|
|
The programmer sees none of this, which is the point.
|
|
The result, which we call goroutines, can be very cheap: they have little
|
|
overhead beyond the memory for the stack, which is just a few kilobytes.
|
|
</p>
|
|
|
|
<p>
|
|
To make the stacks small, Go's run-time uses resizable, bounded stacks. A newly
|
|
minted goroutine is given a few kilobytes, which is almost always enough.
|
|
When it isn't, the run-time grows (and shrinks) the memory for storing
|
|
the stack automatically, allowing many goroutines to live in a modest
|
|
amount of memory.
|
|
The CPU overhead averages about three cheap instructions per function call.
|
|
It is practical to create hundreds of thousands of goroutines in the same
|
|
address space.
|
|
If goroutines were just threads, system resources would
|
|
run out at a much smaller number.
|
|
</p>
|
|
|
|
<h3 id="atomic_maps">
|
|
Why are map operations not defined to be atomic?</h3>
|
|
|
|
<p>
|
|
After long discussion it was decided that the typical use of maps did not require
|
|
safe access from multiple goroutines, and in those cases where it did, the map was
|
|
probably part of some larger data structure or computation that was already
|
|
synchronized. Therefore requiring that all map operations grab a mutex would slow
|
|
down most programs and add safety to few. This was not an easy decision,
|
|
however, since it means uncontrolled map access can crash the program.
|
|
</p>
|
|
|
|
<p>
|
|
The language does not preclude atomic map updates. When required, such
|
|
as when hosting an untrusted program, the implementation could interlock
|
|
map access.
|
|
</p>
|
|
|
|
<p>
|
|
Map access is unsafe only when updates are occurring.
|
|
As long as all goroutines are only reading—looking up elements in the map,
|
|
including iterating through it using a
|
|
<code>for</code> <code>range</code> loop—and not changing the map
|
|
by assigning to elements or doing deletions,
|
|
it is safe for them to access the map concurrently without synchronization.
|
|
</p>
|
|
|
|
<p>
|
|
As an aid to correct map use, some implementations of the language
|
|
contain a special check that automatically reports at run time when a map is modified
|
|
unsafely by concurrent execution.
|
|
</p>
|
|
|
|
<h3 id="language_changes">
|
|
Will you accept my language change?</h3>
|
|
|
|
<p>
|
|
People often suggest improvements to the language—the
|
|
<a href="//groups.google.com/group/golang-nuts">mailing list</a>
|
|
contains a rich history of such discussions—but very few of these changes have
|
|
been accepted.
|
|
</p>
|
|
|
|
<p>
|
|
Although Go is an open source project, the language and libraries are protected
|
|
by a <a href="/doc/go1compat.html">compatibility promise</a> that prevents
|
|
changes that break existing programs, at least at the source code level
|
|
(programs may need to be recompiled occasionally to stay current).
|
|
If your proposal violates the Go 1 specification we cannot even entertain the
|
|
idea, regardless of its merit.
|
|
A future major release of Go may be incompatible with Go 1, but discussions
|
|
on that topic have only just begun and one thing is certain:
|
|
there will be very few such incompatibilities introduced in the process.
|
|
Moreover, the compatibility promise encourages us to provide an automatic path
|
|
forward for old programs to adapt should that situation arise.
|
|
</p>
|
|
|
|
<p>
|
|
Even if your proposal is compatible with the Go 1 spec, it might
|
|
not be in the spirit of Go's design goals.
|
|
The article <i><a href="//talks.golang.org/2012/splash.article">Go
|
|
at Google: Language Design in the Service of Software Engineering</a></i>
|
|
explains Go's origins and the motivation behind its design.
|
|
</p>
|
|
|
|
<h2 id="types">Types</h2>
|
|
|
|
<h3 id="Is_Go_an_object-oriented_language">
|
|
Is Go an object-oriented language?</h3>
|
|
|
|
<p>
|
|
Yes and no. Although Go has types and methods and allows an
|
|
object-oriented style of programming, there is no type hierarchy.
|
|
The concept of “interface” in Go provides a different approach that
|
|
we believe is easy to use and in some ways more general. There are
|
|
also ways to embed types in other types to provide something
|
|
analogous—but not identical—to subclassing.
|
|
Moreover, methods in Go are more general than in C++ or Java:
|
|
they can be defined for any sort of data, even built-in types such
|
|
as plain, “unboxed” integers.
|
|
They are not restricted to structs (classes).
|
|
</p>
|
|
|
|
<p>
|
|
Also, the lack of a type hierarchy makes “objects” in Go feel much more
|
|
lightweight than in languages such as C++ or Java.
|
|
</p>
|
|
|
|
<h3 id="How_do_I_get_dynamic_dispatch_of_methods">
|
|
How do I get dynamic dispatch of methods?</h3>
|
|
|
|
<p>
|
|
The only way to have dynamically dispatched methods is through an
|
|
interface. Methods on a struct or any other concrete type are always resolved statically.
|
|
</p>
|
|
|
|
<h3 id="inheritance">
|
|
Why is there no type inheritance?</h3>
|
|
<p>
|
|
Object-oriented programming, at least in the best-known languages,
|
|
involves too much discussion of the relationships between types,
|
|
relationships that often could be derived automatically. Go takes a
|
|
different approach.
|
|
</p>
|
|
|
|
<p>
|
|
Rather than requiring the programmer to declare ahead of time that two
|
|
types are related, in Go a type automatically satisfies any interface
|
|
that specifies a subset of its methods. Besides reducing the
|
|
bookkeeping, this approach has real advantages. Types can satisfy
|
|
many interfaces at once, without the complexities of traditional
|
|
multiple inheritance.
|
|
Interfaces can be very lightweight—an interface with
|
|
one or even zero methods can express a useful concept.
|
|
Interfaces can be added after the fact if a new idea comes along
|
|
or for testing—without annotating the original types.
|
|
Because there are no explicit relationships between types
|
|
and interfaces, there is no type hierarchy to manage or discuss.
|
|
</p>
|
|
|
|
<p>
|
|
It's possible to use these ideas to construct something analogous to
|
|
type-safe Unix pipes. For instance, see how <code>fmt.Fprintf</code>
|
|
enables formatted printing to any output, not just a file, or how the
|
|
<code>bufio</code> package can be completely separate from file I/O,
|
|
or how the <code>image</code> packages generate compressed
|
|
image files. All these ideas stem from a single interface
|
|
(<code>io.Writer</code>) representing a single method
|
|
(<code>Write</code>). And that's only scratching the surface.
|
|
Go's interfaces have a profound influence on how programs are structured.
|
|
</p>
|
|
|
|
<p>
|
|
It takes some getting used to but this implicit style of type
|
|
dependency is one of the most productive things about Go.
|
|
</p>
|
|
|
|
<h3 id="methods_on_basics">
|
|
Why is <code>len</code> a function and not a method?</h3>
|
|
<p>
|
|
We debated this issue but decided
|
|
implementing <code>len</code> and friends as functions was fine in practice and
|
|
didn't complicate questions about the interface (in the Go type sense)
|
|
of basic types.
|
|
</p>
|
|
|
|
<h3 id="overloading">
|
|
Why does Go not support overloading of methods and operators?</h3>
|
|
<p>
|
|
Method dispatch is simplified if it doesn't need to do type matching as well.
|
|
Experience with other languages told us that having a variety of
|
|
methods with the same name but different signatures was occasionally useful
|
|
but that it could also be confusing and fragile in practice. Matching only by name
|
|
and requiring consistency in the types was a major simplifying decision
|
|
in Go's type system.
|
|
</p>
|
|
|
|
<p>
|
|
Regarding operator overloading, it seems more a convenience than an absolute
|
|
requirement. Again, things are simpler without it.
|
|
</p>
|
|
|
|
<h3 id="implements_interface">
|
|
Why doesn't Go have "implements" declarations?</h3>
|
|
|
|
<p>
|
|
A Go type satisfies an interface by implementing the methods of that interface,
|
|
nothing more. This property allows interfaces to be defined and used without
|
|
needing to modify existing code. It enables a kind of
|
|
<a href="https://en.wikipedia.org/wiki/Structural_type_system">structural typing</a> that
|
|
promotes separation of concerns and improves code re-use, and makes it easier
|
|
to build on patterns that emerge as the code develops.
|
|
The semantics of interfaces is one of the main reasons for Go's nimble,
|
|
lightweight feel.
|
|
</p>
|
|
|
|
<p>
|
|
See the <a href="#inheritance">question on type inheritance</a> for more detail.
|
|
</p>
|
|
|
|
<h3 id="guarantee_satisfies_interface">
|
|
How can I guarantee my type satisfies an interface?</h3>
|
|
|
|
<p>
|
|
You can ask the compiler to check that the type <code>T</code> implements the
|
|
interface <code>I</code> by attempting an assignment using the zero value for
|
|
<code>T</code> or pointer to <code>T</code>, as appropriate:
|
|
</p>
|
|
|
|
<pre>
|
|
type T struct{}
|
|
var _ I = T{} // Verify that T implements I.
|
|
var _ I = (*T)(nil) // Verify that *T implements I.
|
|
</pre>
|
|
|
|
<p>
|
|
If <code>T</code> (or <code>*T</code>, accordingly) doesn't implement
|
|
<code>I</code>, the mistake will be caught at compile time.
|
|
</p>
|
|
|
|
<p>
|
|
If you wish the users of an interface to explicitly declare that they implement
|
|
it, you can add a method with a descriptive name to the interface's method set.
|
|
For example:
|
|
</p>
|
|
|
|
<pre>
|
|
type Fooer interface {
|
|
Foo()
|
|
ImplementsFooer()
|
|
}
|
|
</pre>
|
|
|
|
<p>
|
|
A type must then implement the <code>ImplementsFooer</code> method to be a
|
|
<code>Fooer</code>, clearly documenting the fact and announcing it in
|
|
<a href="/cmd/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 not are not part of the
|
|
standard C setup.
|
|
A new <a href="https://go.googlesource.com/gollvm/">LLVM implementation</a>
|
|
is starting to come together now, however.
|
|
</p>
|
|
|
|
<p>
|
|
The <code>Gccgo</code> compiler is a front end written in C++
|
|
with a recursive descent parser coupled to the
|
|
standard GCC back end.
|
|
</p>
|
|
|
|
<p>
|
|
Go turned out to be a fine language in which to implement a Go compiler,
|
|
although that was not its original goal.
|
|
Not being self-hosting from the beginning allowed Go's design to
|
|
concentrate on its original use case, which was networked servers.
|
|
Had we decided Go should compile itself early on, we might have
|
|
ended up with a language targeted more for compiler construction,
|
|
which is a worthy goal but not the one we had initially.
|
|
</p>
|
|
|
|
<p>
|
|
Although <code>gc</code> does not use them (yet?), a native lexer and
|
|
parser are available in the <a href="/pkg/go/"><code>go</code></a> package
|
|
and there is also a native <a href="/pkg/go/types">type checker</a>.
|
|
</p>
|
|
|
|
<h3 id="How_is_the_run_time_support_implemented">
|
|
How is the run-time support implemented?</h3>
|
|
|
|
<p>
|
|
Again due to bootstrapping issues, the run-time code was originally written mostly in C (with a
|
|
tiny bit of assembler) but it has since been translated to Go
|
|
(except for some assembler bits).
|
|
<code>Gccgo</code>'s run-time support uses <code>glibc</code>.
|
|
The <code>gccgo</code> compiler implements goroutines using
|
|
a technique called segmented stacks,
|
|
supported by recent modifications to the gold linker.
|
|
<code>Gollvm</code> similarly is built on the corresponding
|
|
LLVM infrastructure.
|
|
</p>
|
|
|
|
<h3 id="Why_is_my_trivial_program_such_a_large_binary">
|
|
Why is my trivial program such a large binary?</h3>
|
|
|
|
<p>
|
|
The linker in the <code>gc</code> toolchain
|
|
creates statically-linked binaries by default.
|
|
All Go binaries therefore include the Go
|
|
runtime, along with the run-time type information necessary to support dynamic
|
|
type checks, reflection, and even panic-time stack traces.
|
|
</p>
|
|
|
|
<p>
|
|
A simple C "hello, world" program compiled and linked statically using
|
|
gcc on Linux is around 750 kB, including an implementation of
|
|
<code>printf</code>.
|
|
An equivalent Go program using
|
|
<code>fmt.Printf</code> weighs a couple of megabytes, but that includes
|
|
more powerful run-time support and type and debugging information.
|
|
</p>
|
|
|
|
<p>
|
|
A Go program compiled with <code>gc</code> can be linked with
|
|
the <code>-ldflags=-w</code> flag to disable DWARF generation,
|
|
removing debugging information from the binary but with no
|
|
other loss of functionality.
|
|
This can reduce the binary size substantially.
|
|
</p>
|
|
|
|
<h3 id="unused_variables_and_imports">
|
|
Can I stop these complaints about my unused variable/import?</h3>
|
|
|
|
<p>
|
|
The presence of an unused variable may indicate a bug, while
|
|
unused imports just slow down compilation,
|
|
an effect that can become substantial as a program accumulates
|
|
code and programmers over time.
|
|
For these reasons, Go refuses to compile programs with unused
|
|
variables or imports,
|
|
trading short-term convenience for long-term build speed and
|
|
program clarity.
|
|
</p>
|
|
|
|
<p>
|
|
Still, when developing code, it's common to create these situations
|
|
temporarily and it can be annoying to have to edit them out before the
|
|
program will compile.
|
|
</p>
|
|
|
|
<p>
|
|
Some have asked for a compiler option to turn those checks off
|
|
or at least reduce them to warnings.
|
|
Such an option has not been added, though,
|
|
because compiler options should not affect the semantics of the
|
|
language and because the Go compiler does not report warnings, only
|
|
errors that prevent compilation.
|
|
</p>
|
|
|
|
<p>
|
|
There are two reasons for having no warnings. First, if it's worth
|
|
complaining about, it's worth fixing in the code. (And if it's not
|
|
worth fixing, it's not worth mentioning.) Second, having the compiler
|
|
generate warnings encourages the implementation to warn about weak
|
|
cases that can make compilation noisy, masking real errors that
|
|
<em>should</em> be fixed.
|
|
</p>
|
|
|
|
<p>
|
|
It's easy to address the situation, though. Use the blank identifier
|
|
to let unused things persist while you're developing.
|
|
</p>
|
|
|
|
<pre>
|
|
import "unused"
|
|
|
|
// This declaration marks the import as used by referencing an
|
|
// item from the package.
|
|
var _ = unused.Item // TODO: Delete before committing!
|
|
|
|
func main() {
|
|
debugData := debug.Profile()
|
|
_ = debugData // Used only during debugging.
|
|
....
|
|
}
|
|
</pre>
|
|
|
|
<p>
|
|
Nowadays, most Go programmers use a tool,
|
|
<a href="https://godoc.org/golang.org/x/tools/cmd/goimports">goimports</a>,
|
|
which automatically rewrites a Go source file to have the correct imports,
|
|
eliminating the unused imports issue in practice.
|
|
This program is easily connected to most editors to run automatically when a Go source file is written.
|
|
</p>
|
|
|
|
<h3 id="virus">
|
|
Why does my virus-scanning software think my Go distribution or compiled binary is infected?</h3>
|
|
|
|
<p>
|
|
This is a common occurrence, especially on Windows machines, and is almost always a false positive.
|
|
Commercial virus scanning programs are often confused by the structure of Go binaries, which
|
|
they don't see as often as those compiled from other languages.
|
|
</p>
|
|
|
|
<p>
|
|
If you've just installed the Go distribution and the system reports it is infected, that's certainly a mistake.
|
|
To be really thorough, you can verify the download by comparing the checksum with those on the
|
|
<a href="https://golang.org/dl/">downloads page</a>.
|
|
</p>
|
|
|
|
<p>
|
|
In any case, if you believe the report is in error, please report a bug to the supplier of your virus scanner.
|
|
Maybe in time virus scanners can learn to understand Go programs.
|
|
</p>
|
|
|
|
<h2 id="Performance">Performance</h2>
|
|
|
|
<h3 id="Why_does_Go_perform_badly_on_benchmark_x">
|
|
Why does Go perform badly on benchmark X?</h3>
|
|
|
|
<p>
|
|
One of Go's design goals is to approach the performance of C for comparable
|
|
programs, yet on some benchmarks it does quite poorly, including several
|
|
in <a href="https://go.googlesource.com/exp/+/master/shootout/">golang.org/x/exp/shootout</a>.
|
|
The slowest depend on libraries for which versions of comparable performance
|
|
are not available in Go.
|
|
For instance, <a href="https://go.googlesource.com/exp/+/master/shootout/pidigits.go">pidigits.go</a>
|
|
depends on a multi-precision math package, and the C
|
|
versions, unlike Go's, use <a href="https://gmplib.org/">GMP</a> (which is
|
|
written in optimized assembler).
|
|
Benchmarks that depend on regular expressions
|
|
(<a href="https://go.googlesource.com/exp/+/master/shootout/regex-dna.go">regex-dna.go</a>,
|
|
for instance) are essentially comparing Go's native <a href="/pkg/regexp">regexp package</a> to
|
|
mature, highly optimized regular expression libraries like PCRE.
|
|
</p>
|
|
|
|
<p>
|
|
Benchmark games are won by extensive tuning and the Go versions of most
|
|
of the benchmarks need attention. If you measure comparable C
|
|
and Go programs
|
|
(<a href="https://go.googlesource.com/exp/+/master/shootout/reverse-complement.go">reverse-complement.go</a>
|
|
is one example), you'll see the two languages are much closer in raw performance
|
|
than this suite would indicate.
|
|
</p>
|
|
|
|
<p>
|
|
Still, there is room for improvement. The compilers are good but could be
|
|
better, many libraries need major performance work, and the garbage collector
|
|
isn't fast enough yet. (Even if it were, taking care not to generate unnecessary
|
|
garbage can have a huge effect.)
|
|
</p>
|
|
|
|
<p>
|
|
In any case, Go can often be very competitive.
|
|
There has been significant improvement in the performance of many programs
|
|
as the language and tools have developed.
|
|
See the blog post about
|
|
<a href="//blog.golang.org/2011/06/profiling-go-programs.html">profiling
|
|
Go programs</a> for an informative example.
|
|
|
|
<h2 id="change_from_c">Changes from C</h2>
|
|
|
|
<h3 id="different_syntax">
|
|
Why is the syntax so different from C?</h3>
|
|
<p>
|
|
Other than declaration syntax, the differences are not major and stem
|
|
from two desires. First, the syntax should feel light, without too
|
|
many mandatory keywords, repetition, or arcana. Second, the language
|
|
has been designed to be easy to analyze
|
|
and can be parsed without a symbol table. This makes it much easier
|
|
to build tools such as debuggers, dependency analyzers, automated
|
|
documentation extractors, IDE plug-ins, and so on. C and its
|
|
descendants are notoriously difficult in this regard.
|
|
</p>
|
|
|
|
<h3 id="declarations_backwards">
|
|
Why are declarations backwards?</h3>
|
|
<p>
|
|
They're only backwards if you're used to C. In C, the notion is that a
|
|
variable is declared like an expression denoting its type, which is a
|
|
nice idea, but the type and expression grammars don't mix very well and
|
|
the results can be confusing; consider function pointers. Go mostly
|
|
separates expression and type syntax and that simplifies things (using
|
|
prefix <code>*</code> for pointers is an exception that proves the rule). In C,
|
|
the declaration
|
|
</p>
|
|
<pre>
|
|
int* a, b;
|
|
</pre>
|
|
<p>
|
|
declares <code>a</code> to be a pointer but not <code>b</code>; in Go
|
|
</p>
|
|
<pre>
|
|
var a, b *int
|
|
</pre>
|
|
<p>
|
|
declares both to be pointers. This is clearer and more regular.
|
|
Also, the <code>:=</code> short declaration form argues that a full variable
|
|
declaration should present the same order as <code>:=</code> so
|
|
</p>
|
|
<pre>
|
|
var a uint64 = 1
|
|
</pre>
|
|
<p>
|
|
has the same effect as
|
|
</p>
|
|
<pre>
|
|
a := uint64(1)
|
|
</pre>
|
|
<p>
|
|
Parsing is also simplified by having a distinct grammar for types that
|
|
is not just the expression grammar; keywords such as <code>func</code>
|
|
and <code>chan</code> keep things clear.
|
|
</p>
|
|
|
|
<p>
|
|
See the article about
|
|
<a href="/doc/articles/gos_declaration_syntax.html">Go's Declaration Syntax</a>
|
|
for more details.
|
|
</p>
|
|
|
|
<h3 id="no_pointer_arithmetic">
|
|
Why is there no pointer arithmetic?</h3>
|
|
<p>
|
|
Safety. Without pointer arithmetic it's possible to create a
|
|
language that can never derive an illegal address that succeeds
|
|
incorrectly. Compiler and hardware technology have advanced to the
|
|
point where a loop using array indices can be as efficient as a loop
|
|
using pointer arithmetic. Also, the lack of pointer arithmetic can
|
|
simplify the implementation of the garbage collector.
|
|
</p>
|
|
|
|
<h3 id="inc_dec">
|
|
Why are <code>++</code> and <code>--</code> statements and not expressions? And why postfix, not prefix?</h3>
|
|
<p>
|
|
Without pointer arithmetic, the convenience value of pre- and postfix
|
|
increment operators drops. By removing them from the expression
|
|
hierarchy altogether, expression syntax is simplified and the messy
|
|
issues around order of evaluation of <code>++</code> and <code>--</code>
|
|
(consider <code>f(i++)</code> and <code>p[i] = q[++i]</code>)
|
|
are eliminated as well. The simplification is
|
|
significant. As for postfix vs. prefix, either would work fine but
|
|
the postfix version is more traditional; insistence on prefix arose
|
|
with the STL, a library for a language whose name contains, ironically, a
|
|
postfix increment.
|
|
</p>
|
|
|
|
<h3 id="semicolons">
|
|
Why are there braces but no semicolons? And why can't I put the opening
|
|
brace on the next line?</h3>
|
|
<p>
|
|
Go uses brace brackets for statement grouping, a syntax familiar to
|
|
programmers who have worked with any language in the C family.
|
|
Semicolons, however, are for parsers, not for people, and we wanted to
|
|
eliminate them as much as possible. To achieve this goal, Go borrows
|
|
a trick from BCPL: the semicolons that separate statements are in the
|
|
formal grammar but are injected automatically, without lookahead, by
|
|
the lexer at the end of any line that could be the end of a statement.
|
|
This works very well in practice but has the effect that it forces a
|
|
brace style. For instance, the opening brace of a function cannot
|
|
appear on a line by itself.
|
|
</p>
|
|
|
|
<p>
|
|
Some have argued that the lexer should do lookahead to permit the
|
|
brace to live on the next line. We disagree. Since Go code is meant
|
|
to be formatted automatically by
|
|
<a href="/cmd/gofmt/"><code>gofmt</code></a>,
|
|
<i>some</i> style must be chosen. That style may differ from what
|
|
you've used in C or Java, but Go is a different language and
|
|
<code>gofmt</code>'s style is as good as any other. More
|
|
important—much more important—the advantages of a single,
|
|
programmatically mandated format for all Go programs greatly outweigh
|
|
any perceived disadvantages of the particular style.
|
|
Note too that Go's style means that an interactive implementation of
|
|
Go can use the standard syntax one line at a time without special rules.
|
|
</p>
|
|
|
|
<h3 id="garbage_collection">
|
|
Why do garbage collection? Won't it be too expensive?</h3>
|
|
<p>
|
|
One of the biggest sources of bookkeeping in systems programs is
|
|
managing the lifetimes of allocated objects.
|
|
In languages such as C in which it is done manually,
|
|
it can consume a significant amount of programmer time and is
|
|
often the cause of pernicious bugs.
|
|
Even in languages like C++ or Rust that provide mechanisms
|
|
to assist, those mechanisms can have a significant effect on the
|
|
design of the software, often adding programming overhead
|
|
of its own.
|
|
We felt it was critical to eliminate such
|
|
programmer overheads, and advances in garbage collection
|
|
technology in the last few years gave us confidence that it
|
|
could be implemented cheaply enough, and with low enough
|
|
latency, that it could be a viable approach for networked
|
|
systems.
|
|
</p>
|
|
|
|
<p>
|
|
Much of the difficulty of concurrent programming
|
|
has its roots in the object lifetime problem:
|
|
as objects get passed among threads it becomes cumbersome
|
|
to guarantee they become freed safely.
|
|
Automatic garbage collection makes concurrent code far easier to write.
|
|
Of course, implementing garbage collection in a concurrent environment is
|
|
itself a challenge, but meeting it once rather than in every
|
|
program helps everyone.
|
|
</p>
|
|
|
|
<p>
|
|
Finally, concurrency aside, garbage collection makes interfaces
|
|
simpler because they don't need to specify how memory is managed across them.
|
|
</p>
|
|
|
|
<p>
|
|
This is not to say that the recent work in languages
|
|
like Rust that bring new ideas to the problem of managing
|
|
resources is misguided; we encourage this work and are excited to see
|
|
how it evolves.
|
|
But Go takes a more traditional approach by addressing
|
|
object lifetimes through
|
|
garbage collection, and garbage collection alone.
|
|
</p>
|
|
|
|
<p>
|
|
The current implementation is a mark-and-sweep collector.
|
|
If the machine is a multiprocessor, the collector runs on a separate CPU
|
|
core in parallel with the main program.
|
|
Major work on the collector in recent years has reduced pause times
|
|
often to the sub-millisecond range, even for large heaps,
|
|
all but eliminating one of the major objections to garbage collection
|
|
in networked servers.
|
|
Work continues to refine the algorithm, reduce overhead and
|
|
latency further, and to explore new approaches.
|
|
The 2018
|
|
<a href="https://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>
|