mirror of
https://github.com/golang/go
synced 2024-09-24 07:10:12 -06:00
doc: update FAQ for Go 1.5
Change-Id: I4befb21d0811819ce0a5721421a2f6df7a9b62fa Reviewed-on: https://go-review.googlesource.com/11605 Reviewed-by: Russ Cox <rsc@golang.org> Reviewed-by: Andrew Gerrand <adg@golang.org>
This commit is contained in:
parent
1bab3a16db
commit
694b244e1d
153
doc/go_faq.html
153
doc/go_faq.html
@ -107,7 +107,8 @@ The mascot and logo were designed by
|
|||||||
<a href="http://reneefrench.blogspot.com">Renée French</a>, who also designed
|
<a href="http://reneefrench.blogspot.com">Renée French</a>, who also designed
|
||||||
<a href="http://plan9.bell-labs.com/plan9/glenda.html">Glenda</a>,
|
<a href="http://plan9.bell-labs.com/plan9/glenda.html">Glenda</a>,
|
||||||
the Plan 9 bunny.
|
the Plan 9 bunny.
|
||||||
The gopher is derived from one she used for an <a href="http://wfmu.org/">WFMU</a>
|
The <a href="https://blog.golang.org/gopher">gopher</a>
|
||||||
|
is derived from one she used for an <a href="http://wfmu.org/">WFMU</a>
|
||||||
T-shirt design some years ago.
|
T-shirt design some years ago.
|
||||||
The logo and mascot are covered by the
|
The logo and mascot are covered by the
|
||||||
<a href="http://creativecommons.org/licenses/by/3.0/">Creative Commons Attribution 3.0</a>
|
<a href="http://creativecommons.org/licenses/by/3.0/">Creative Commons Attribution 3.0</a>
|
||||||
@ -153,7 +154,7 @@ Go is an attempt to combine the ease of programming of an interpreted,
|
|||||||
dynamically typed
|
dynamically typed
|
||||||
language with the efficiency and safety of a statically typed, compiled language.
|
language with the efficiency and safety of a statically typed, compiled language.
|
||||||
It also aims to be modern, with support for networked and multicore
|
It also aims to be modern, with support for networked and multicore
|
||||||
computing. Finally, it is intended to be <i>fast</i>: it should take
|
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.
|
at most a few seconds to build a large executable on a single computer.
|
||||||
To meet these goals required addressing a number of
|
To meet these goals required addressing a number of
|
||||||
linguistic issues: an expressive but lightweight type system;
|
linguistic issues: an expressive but lightweight type system;
|
||||||
@ -508,7 +509,7 @@ They are not restricted to structs (classes).
|
|||||||
</p>
|
</p>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
Also, the lack of type hierarchy makes “objects” in Go feel much more
|
Also, the lack of a type hierarchy makes “objects” in Go feel much more
|
||||||
lightweight than in languages such as C++ or Java.
|
lightweight than in languages such as C++ or Java.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
@ -608,17 +609,19 @@ How can I guarantee my type satisfies an interface?</h3>
|
|||||||
|
|
||||||
<p>
|
<p>
|
||||||
You can ask the compiler to check that the type <code>T</code> implements the
|
You can ask the compiler to check that the type <code>T</code> implements the
|
||||||
interface <code>I</code> by attempting an assignment:
|
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>
|
</p>
|
||||||
|
|
||||||
<pre>
|
<pre>
|
||||||
type T struct{}
|
type T struct{}
|
||||||
var _ I = T{} // Verify that T implements I.
|
var _ I = T{} // Verify that T implements I.
|
||||||
|
var _ I = (*T)(nil) // Verify that *T implements I.
|
||||||
</pre>
|
</pre>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
If <code>T</code> doesn't implement <code>I</code>, the mistake will be caught
|
If <code>T</code> (or <code>*T</code>, accordingly) doesn't implement
|
||||||
at compile time.
|
<code>I</code>, the mistake will be caught at compile time.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
@ -726,7 +729,7 @@ interface satisfaction very easy to state: are the function's names
|
|||||||
and signatures exactly those of the interface?
|
and signatures exactly those of the interface?
|
||||||
Go's rule is also easy to implement efficiently.
|
Go's rule is also easy to implement efficiently.
|
||||||
We feel these benefits offset the lack of
|
We feel these benefits offset the lack of
|
||||||
automatic type promotion. Should Go one day adopt some form of generic
|
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
|
typing, we expect there would be a way to express the idea of these
|
||||||
examples and also have them be statically checked.
|
examples and also have them be statically checked.
|
||||||
</p>
|
</p>
|
||||||
@ -765,7 +768,7 @@ schematically, (<code>int</code>, <code>3</code>).
|
|||||||
An interface value is <code>nil</code> only if the inner value and type are both unset,
|
An interface value is <code>nil</code> only if the inner value and type are both unset,
|
||||||
(<code>nil</code>, <code>nil</code>).
|
(<code>nil</code>, <code>nil</code>).
|
||||||
In particular, a <code>nil</code> interface will always hold a <code>nil</code> type.
|
In particular, a <code>nil</code> interface will always hold a <code>nil</code> type.
|
||||||
If we store a pointer of type <code>*int</code> inside
|
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:
|
an interface value, the inner type will be <code>*int</code> regardless of the value of the pointer:
|
||||||
(<code>*int</code>, <code>nil</code>).
|
(<code>*int</code>, <code>nil</code>).
|
||||||
Such an interface value will therefore be non-<code>nil</code>
|
Such an interface value will therefore be non-<code>nil</code>
|
||||||
@ -773,7 +776,7 @@ Such an interface value will therefore be non-<code>nil</code>
|
|||||||
</p>
|
</p>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
This situation can be confusing, and often arises when a <code>nil</code> value is
|
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:
|
stored inside an interface value such as an <code>error</code> return:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
@ -890,7 +893,7 @@ encourages you to be explicit.
|
|||||||
</p>
|
</p>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
A blog post, title <a href="http://blog.golang.org/constants">Constants</a>,
|
A blog post titled <a href="http://blog.golang.org/constants">Constants</a>
|
||||||
explores this topic in more detail.
|
explores this topic in more detail.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
@ -950,6 +953,19 @@ In fact, <code>godoc</code> implements the full site at
|
|||||||
<a href="/">golang.org/</a>.
|
<a href="/">golang.org/</a>.
|
||||||
</p>
|
</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">
|
<h3 id="Is_there_a_Go_programming_style_guide">
|
||||||
Is there a Go programming style guide?</h3>
|
Is there a Go programming style guide?</h3>
|
||||||
|
|
||||||
@ -1046,7 +1062,17 @@ unexpected ways, the simplest solution is to copy it to your local repository.
|
|||||||
(This is the approach Google takes internally.)
|
(This is the approach Google takes internally.)
|
||||||
Store the copy under a new import path that identifies it as a local copy.
|
Store the copy under a new import path that identifies it as a local copy.
|
||||||
For example, you might copy "original.com/pkg" to "you.com/external/original.com/pkg".
|
For example, you might copy "original.com/pkg" to "you.com/external/original.com/pkg".
|
||||||
<a href="https://godoc.org/golang.org/x/tools/cmd/gomvpkg">gomvpkg</a> is one tool to help automate this process.
|
The <a href="https://godoc.org/golang.org/x/tools/cmd/gomvpkg">gomvpkg</a>
|
||||||
|
program is one tool to help automate this process.
|
||||||
|
</p>
|
||||||
|
|
||||||
|
<p>
|
||||||
|
The Go 1.5 release includes an experimental facility to the
|
||||||
|
<a href="https://golang.org/cmd/go">go</a> command
|
||||||
|
that makes it easier to manage external dependencies by "vendoring"
|
||||||
|
them into a special directory near the package that depends upon them.
|
||||||
|
See the <a href="https://golang.org/s/go15vendor">design
|
||||||
|
document</a> for details.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<h2 id="Pointers">Pointers and Allocation</h2>
|
<h2 id="Pointers">Pointers and Allocation</h2>
|
||||||
@ -1061,7 +1087,8 @@ thing being passed, as if there were an assignment statement assigning the
|
|||||||
value to the parameter. For instance, passing an <code>int</code> value
|
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
|
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.
|
value makes a copy of the pointer, but not the data it points to.
|
||||||
(See the next section for a discussion of how this affects method receivers.)
|
(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>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
@ -1290,14 +1317,20 @@ See the <a href="/doc/codewalk/sharemem/">Share Memory By Communicating</a> code
|
|||||||
Why doesn't my multi-goroutine program use multiple CPUs?</h3>
|
Why doesn't my multi-goroutine program use multiple CPUs?</h3>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
You must set the <code>GOMAXPROCS</code> shell environment variable
|
The number of CPUs available simultaneously to executing goroutines is
|
||||||
or use the similarly-named <a href="/pkg/runtime/#GOMAXPROCS"><code>function</code></a>
|
controlled by the <code>GOMAXPROCS</code> shell environment variable.
|
||||||
of the runtime package to allow the
|
In earlier releases of Go, the default value was 1, but as of Go 1.5 the default
|
||||||
run-time support to utilize more than one OS thread.
|
value is the number of cores available.
|
||||||
|
Therefore programs compiled afer 1.5 should demonstrate parallel execution
|
||||||
|
of multiple goroutines.
|
||||||
|
To change the behavior, 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.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
Programs that perform parallel computation should benefit from an increase in
|
Programs that perform parallel computation might benefit from a further increase in
|
||||||
<code>GOMAXPROCS</code>.
|
<code>GOMAXPROCS</code>.
|
||||||
However, be aware that
|
However, be aware that
|
||||||
<a href="//blog.golang.org/2013/01/concurrency-is-not-parallelism.html">concurrency
|
<a href="//blog.golang.org/2013/01/concurrency-is-not-parallelism.html">concurrency
|
||||||
@ -1319,7 +1352,7 @@ intrinsically parallel.
|
|||||||
<p>
|
<p>
|
||||||
In practical terms, programs that spend more time
|
In practical terms, programs that spend more time
|
||||||
communicating on channels than doing computation
|
communicating on channels than doing computation
|
||||||
will experience performance degradation when using
|
may experience performance degradation when using
|
||||||
multiple OS threads.
|
multiple OS threads.
|
||||||
This is because sending data between threads involves switching
|
This is because sending data between threads involves switching
|
||||||
contexts, which has significant cost.
|
contexts, which has significant cost.
|
||||||
@ -1330,9 +1363,11 @@ to speed it up.
|
|||||||
</p>
|
</p>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
Go's goroutine scheduler is not as good as it needs to be. In the future, it
|
Go's goroutine scheduler is not as good as it needs to be, although it
|
||||||
should recognize such cases and optimize its use of OS threads. For now,
|
has improved in recent releases.
|
||||||
<code>GOMAXPROCS</code> should be set on a per-application basis.
|
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>
|
</p>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
@ -1367,7 +1402,10 @@ there is no useful way for a method call to obtain a pointer.
|
|||||||
Even in cases where the compiler could take the address of a value
|
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
|
to pass to the method, if the method modifies the value the changes
|
||||||
will be lost in the caller.
|
will be lost in the caller.
|
||||||
As a common example, this code:
|
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>
|
</p>
|
||||||
|
|
||||||
<pre>
|
<pre>
|
||||||
@ -1461,7 +1499,7 @@ seem odd but works fine in Go:
|
|||||||
Does Go have the <code>?:</code> operator?</h3>
|
Does Go have the <code>?:</code> operator?</h3>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
There is no ternary form in Go. You may use the following to achieve the same
|
There is no ternary testing operation in Go. You may use the following to achieve the same
|
||||||
result:
|
result:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
@ -1561,11 +1599,10 @@ What compiler technology is used to build the compilers?</h3>
|
|||||||
|
|
||||||
<p>
|
<p>
|
||||||
<code>Gccgo</code> has a front end written in C++, with a recursive descent parser coupled to the
|
<code>Gccgo</code> has a front end written in C++, with a recursive descent parser coupled to the
|
||||||
standard GCC back end. <code>Gc</code> is written in C using
|
standard GCC back end. <code>Gc</code> is written in Go using
|
||||||
<code>yacc</code>/<code>bison</code> for the parser.
|
<code>yacc</code>/<code>bison</code> for the parser
|
||||||
Although it's a new program, it fits in the Plan 9 C compiler suite
|
and uses a custom loader, also written in Go but
|
||||||
(<a href="http://plan9.bell-labs.com/sys/doc/compiler.html">http://plan9.bell-labs.com/sys/doc/compiler.html</a>)
|
based on the Plan 9 loader, to generate ELF/Mach-O/PE binaries.
|
||||||
and uses a variant of the Plan 9 loader to generate ELF/Mach-O/PE binaries.
|
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
@ -1574,24 +1611,26 @@ slow to meet our performance goals.
|
|||||||
</p>
|
</p>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
We also considered writing <code>gc</code>, the original Go compiler, in Go itself but
|
The original <code>gc</code>, the Go compiler, was written in C
|
||||||
elected not to do so because of the difficulties of bootstrapping and
|
because of the difficulties of bootstrapping—you'd need a Go compiler to
|
||||||
especially of open source distribution—you'd need a Go compiler to
|
set up a Go environment.
|
||||||
set up a Go environment. <code>Gccgo</code>, which came later, makes it possible to
|
But things have advanced and as of Go 1.5 the compiler is written in Go.
|
||||||
consider writing a compiler in Go.
|
It was converted from C to Go using automatic translation tools, as
|
||||||
A plan to do that by machine translation of the existing compiler is under development.
|
described in <a href="/s/go13compiler">this design document</a>
|
||||||
<a href="http://golang.org/s/go13compiler">A separate document</a>
|
and <a href="https://talks.golang.org/2015/gogo.slide#1">a recent talk</a>.
|
||||||
explains the reason for this approach.
|
Thus the compiler is now "self-hosting", which means we must face
|
||||||
|
the bootstrapping problem.
|
||||||
|
The solution, naturally, is to have a working Go installation already,
|
||||||
|
just as one normally has a working C installation in place.
|
||||||
|
The story of how to bring up a new Go installation from source
|
||||||
|
is described <a href="/s/go15bootstrap">separately</a>.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
That plan aside,
|
Go is a fine language in which to implement a Go compiler.
|
||||||
Go is a
|
Although <code>gc</code> does not use them (yet?), a native lexer and
|
||||||
fine language in which to implement a self-hosting compiler: a native lexer and
|
parser are available in the <a href="/pkg/go/"><code>go</code></a> package
|
||||||
parser are already available in the <a href="/pkg/go/"><code>go</code></a> package
|
and there is also a <a href="/pkg/go/types">type checker</a>.
|
||||||
and a separate type checking
|
|
||||||
<a href="http://godoc.org/golang.org/x/tools/go/types">package</a>
|
|
||||||
has also been written.
|
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<h3 id="How_is_the_run_time_support_implemented">
|
<h3 id="How_is_the_run_time_support_implemented">
|
||||||
@ -1599,15 +1638,11 @@ How is the run-time support implemented?</h3>
|
|||||||
|
|
||||||
<p>
|
<p>
|
||||||
Again due to bootstrapping issues, the run-time code was originally written mostly in C (with a
|
Again due to bootstrapping issues, the run-time code was originally written mostly in C (with a
|
||||||
tiny bit of assembler) although much of it has been translated to Go since then
|
tiny bit of assembler) but it has since been translated to Go
|
||||||
and one day all of it might be (except for the assembler bits).
|
(except for some assembler bits).
|
||||||
<code>Gccgo</code>'s run-time support uses <code>glibc</code>.
|
<code>Gccgo</code>'s run-time support uses <code>glibc</code>.
|
||||||
<code>Gc</code> uses a custom C library to keep the footprint under
|
The <code>gccgo</code> compiler implements goroutines using
|
||||||
control; it is
|
a technique called segmented stacks,
|
||||||
compiled with a version of the Plan 9 C compiler that supports
|
|
||||||
resizable stacks for goroutines.
|
|
||||||
The <code>gccgo</code> compiler implements these on Linux only,
|
|
||||||
using a technique called segmented stacks,
|
|
||||||
supported by recent modifications to the gold linker.
|
supported by recent modifications to the gold linker.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
@ -1615,8 +1650,8 @@ supported by recent modifications to the gold linker.
|
|||||||
Why is my trivial program such a large binary?</h3>
|
Why is my trivial program such a large binary?</h3>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
The linkers in the gc tool chain (<code>5l</code>, <code>6l</code>, and <code>8l</code>)
|
The linker in the <code>gc</code> tool chain
|
||||||
do static linking. All Go binaries therefore include the Go
|
creates statically-linked binaries by default. All Go binaries therefore include the Go
|
||||||
run-time, along with the run-time type information necessary to support dynamic
|
run-time, along with the run-time type information necessary to support dynamic
|
||||||
type checks, reflection, and even panic-time stack traces.
|
type checks, reflection, and even panic-time stack traces.
|
||||||
</p>
|
</p>
|
||||||
@ -1626,7 +1661,7 @@ A simple C "hello, world" program compiled and linked statically using gcc
|
|||||||
on Linux is around 750 kB,
|
on Linux is around 750 kB,
|
||||||
including an implementation of <code>printf</code>.
|
including an implementation of <code>printf</code>.
|
||||||
An equivalent Go program using <code>fmt.Printf</code>
|
An equivalent Go program using <code>fmt.Printf</code>
|
||||||
is around 1.9 MB, but
|
is around 2.3 MB, but
|
||||||
that includes more powerful run-time support and type information.
|
that includes more powerful run-time support and type information.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
@ -1885,8 +1920,12 @@ simpler because they don't need to specify how memory is managed across them.
|
|||||||
</p>
|
</p>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
The current implementation is a parallel mark-and-sweep
|
The current implementation is a parallel mark-and-sweep collector.
|
||||||
collector but a future version might take a different approach.
|
Recent improvements, documented in
|
||||||
|
<a href="/s/go14gc">this design document</a>,
|
||||||
|
have introduced bounded pause times and improved the
|
||||||
|
parallelism.
|
||||||
|
Future versions might attempt new approaches.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
Loading…
Reference in New Issue
Block a user