From 04b08da9af0c450d645ab7389d1467308cfc2db8 Mon Sep 17 00:00:00 2001 From: Michael Stapelberg Date: Mon, 4 Mar 2013 21:27:36 +0100 Subject: Imported Upstream version 1.1~hg20130304 --- doc/go_faq.html | 155 +++++++++++++++++++++++++++++++++++++++++++++----------- 1 file changed, 125 insertions(+), 30 deletions(-) (limited to 'doc/go_faq.html') diff --git a/doc/go_faq.html b/doc/go_faq.html index b5b7cc656..5c68aa7e5 100644 --- a/doc/go_faq.html +++ b/doc/go_faq.html @@ -1,5 +1,6 @@

Origins

@@ -54,6 +55,38 @@ By its design, Go proposes an approach for the construction of system software on multicore machines. +

+What is the status of the project?

+ +

+Go became a public open source project on November 10, 2009. +After a couple of years of very active design and development, stability was called for and +Go 1 was released +on March 28, 2012. +Go 1, which includes a language specification, +standard libraries, +and custom tools, +provides a stable foundation for creating reliable products, projects, and publications. +

+ +

+With that stability established, we are using Go to develop programs, products, and tools rather than +actively changing the language and libraries. +In fact, the purpose of Go 1 is to provide long-term stability. +Backwards-incompatible changes will not be made to any Go 1 point release. +We want to use what we have to learn how a future version of Go might look, rather than to play with +the language underfoot. +

+ +

+Of course, development will continue on Go itself, but the focus will be on performance, reliability, +portability and the addition of new functionality such as improved support for internationalization. +

+ +

+There may well be a Go 2 one day, but not for a few years and it will be influenced by what we learn using Go 1 as it is today. +

+

What is the origin of the name?

@@ -175,12 +208,12 @@ easier to understand what happens when things combine.

Is Google using Go internally?

-Yes. There are now several Go programs deployed in +Yes. There are now several Go programs deployed in production inside Google. A public example is the server behind http://golang.org. It's just the godoc document server running in a production configuration on -Google App Engine. +Google App Engine.

A Go type satisfies an interface by implementing the methods of that interface, nothing more. This property allows interfaces to be defined and used without -having to modify existing code. It enables a kind of "duck typing" that +having to modify existing code. It enables a kind of structural typing that promotes separation of concerns and improves code re-use, and makes it easier to build on patterns that emerge as the code develops. The semantics of interfaces is one of the main reasons for Go's nimble, @@ -564,7 +597,7 @@ func (b Bar) Foo() {}

-Most code doesn't make use of such constraints, since they limit the utility of +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.

@@ -890,6 +923,32 @@ See the document for more information about how to proceed.

+

+Why does the project use Mercurial and not git?

+ +

+The Go project, hosted by Google Code at +code.google.com/p/go, +uses Mercurial as its version control system. +When the project launched, +Google Code supported only Subversion and Mercurial. +Mercurial was a better choice because of its plugin mechanism +that allowed us to create the "codereview" plugin to connect +the project to the excellent code review tools at +codereview.appspot.com. +

+ +

+Programmers who work +with the Go project's source rather than release downloads sometimes +ask for the project to switch to git. +That would be possible, but it would be a lot of work and +would also require reimplementing the codereview plugin. +Given that Mercurial works today, with code review support, +combined with the Go project's mostly linear, non-branching use of +version control, a switch to git doesn't seem worthwhile. +

+

Pointers and Allocation

@@ -912,7 +971,7 @@ 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. +makes a copy of the pointer, but again not the data it points to.

@@ -994,9 +1053,11 @@ Why is int 32 bits on 64 bit machines?

The sizes of int and uint are implementation-specific but the same as each other on a given platform. -The 64 bit Go compilers (both gc and gccgo) use a 32 bit representation for -int. Code that relies on a particular +For portability, code that relies on a particular size of value should use an explicitly sized type, like int64. +Prior to Go 1.1, the 64-bit Go compilers (both gc and gccgo) used +a 32-bit representation for int. As of Go 1.1 they use +a 64-bit representation. On the other hand, floating-point scalars and complex numbers are always sized: float32, complex64, etc., because programmers should be aware of precision when using @@ -1038,6 +1099,22 @@ analysis recognizes some cases when such variables will not live past the return from the function and can reside on the stack.

+

+Why does my Go process use so much virtual memory?

+ +

+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. +

+ +

+To find the amount of actual memory allocated to a Go process, use the Unix +top command and consult the RES (Linux) or +RSIZE (Mac OS X) columns. + +

+

Concurrency

@@ -1071,7 +1148,7 @@ Why doesn't my multi-goroutine program use multiple CPUs?

You must set the GOMAXPROCS shell environment variable or use the similarly-named function of the runtime package to allow the -run-time support to utilize more than one OS thread. +run-time support to utilize more than one OS thread.

@@ -1084,7 +1161,7 @@ Why does using GOMAXPROCS > 1 sometimes make my program slower?

-It depends on the nature of your program. +It depends on the nature of your program. Problems that are intrinsically sequential cannot be sped up by adding more goroutines. Concurrency only becomes parallelism when the problem is @@ -1173,23 +1250,26 @@ func main() { // wait for all goroutines to complete before exiting for _ = range values { - <-done + <-done } }

-One might mistakenly expect to see a, b, c as the output. -What you'll probably see instead is c, c, c. This is because +One might mistakenly expect to see a, b, c as the output. +What you'll probably see instead is c, c, c. This is because each iteration of the loop uses the same instance of the variable v, so -each closure shares that single variable. When the closure runs, it prints the +each closure shares that single variable. When the closure runs, it prints the value of v at the time fmt.Println is executed, -but v may have been modified since the goroutine was launched. +but v may have been modified since the goroutine was launched. +To help detect this and other problems before they happen, run +go vet.

-To bind the value of v to each closure as they are launched, one -could modify the inner loop to read: +To bind the current value of v 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: 

@@ -1202,11 +1282,26 @@ could modify the inner loop to read:

-In this example, the value of v is passed as an argument to the +In this example, the value of v is passed as an argument to the anonymous function. That value is then accessible inside the function as the variable u.

+

+Even easier is just to create a new variable, using a declaration style that may +seem odd but works fine in Go: +

+ +
+    for _, v := range values {
+        v := v // create a new 'v'.
+        go func() {
+            fmt.Println(v)
+            done <- true
+        }()
+    }
+
+

Control flow

@@ -1264,7 +1359,7 @@ builds a test binary, and runs it.

See the How to Write Go Code document, the testing package -and the go test subcommand for more details. +and the go test subcommand for more details.

@@ -1383,7 +1478,7 @@ For these reasons, Go allows neither.

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. +program will compile.

@@ -1430,13 +1525,13 @@ Why does Go perform badly on benchmark X?

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 test/bench/shootout. The slowest depend on libraries -for which versions of comparable performance are not available in Go. +programs, yet on some benchmarks it does quite poorly, including several +in test/bench/shootout. The slowest depend on libraries +for which versions of comparable performance are not available in Go. For instance, pidigits.go depends on a multi-precision math package, and the C versions, unlike Go's, use GMP (which is -written in optimized assembler). +written in optimized assembler). Benchmarks that depend on regular expressions (regex-dna.go, for instance) are essentially comparing Go's native regexp package to @@ -1455,7 +1550,7 @@ indicate.

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 +isn't fast enough yet. (Even if it were, taking care not to generate unnecessary garbage can have a huge effect.)

-- cgit v1.2.3