diff options
Diffstat (limited to 'doc/go_faq.html')
| -rw-r--r-- | doc/go_faq.html | 100 |
1 files changed, 50 insertions, 50 deletions
diff --git a/doc/go_faq.html b/doc/go_faq.html index f2082ef5b..6b77f1c1e 100644 --- a/doc/go_faq.html +++ b/doc/go_faq.html @@ -228,7 +228,7 @@ document server running in a production configuration on </p> <p> -Other examples include the <a href="https://code.google.com/p/vitess/">Vitess</a> +Other examples include the <a href="//code.google.com/p/vitess/">Vitess</a> system for large-scale SQL installations and Google's download server, <code>dl.google.com</code>, which delivers Chrome binaries and other large installables such as <code>apt-get</code> packages. @@ -889,6 +889,11 @@ type is generic; if you care about how many bits an integer holds, Go encourages you to be explicit. </p> +<p> +A blog post, title <a href="http://blog.golang.org/constants">Constants</a>, +explores this topic in more detail. +</p> + <h3 id="builtin_maps"> Why are maps built in?</h3> <p> @@ -971,7 +976,7 @@ It is a handy reference for people doing code reviews for Go projects. How do I submit patches to the Go libraries?</h3> <p> -The library sources are in <code>go/src/pkg</code>. +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> @@ -981,32 +986,6 @@ See the document for more information about how to proceed. </p> -<h3 id="Why_does_the_project_use_Mercurial_and_not_git"> -Why does the project use Mercurial and not git?</h3> - -<p> -The Go project, hosted by Google Code at -<a href="//code.google.com/p/go">code.google.com/p/go</a>, -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 -<a href="//codereview.appspot.com">codereview.appspot.com</a>. -</p> - -<p> -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. -</p> - <h3 id="git_https"> Why does "go get" use HTTPS when cloning a repository?</h3> @@ -1110,7 +1089,7 @@ 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 a interface</em>. +an interface, with one exception <em>a pointer to an interface can never satisfy an interface</em>. </p> <p> @@ -1351,7 +1330,7 @@ to speed it up. </p> <p> -Go's goroutine scheduler is not as good as it needs to be. In future, it +Go's goroutine scheduler is not as good as it needs to be. In the future, it should recognize such cases and optimize its use of OS threads. For now, <code>GOMAXPROCS</code> should be set on a per-application basis. </p> @@ -1571,7 +1550,7 @@ 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/pkg/fmt/fmt_test.go">the formatting tests for the <code>fmt</code> package</a>. +<a href="/src/fmt/fmt_test.go">the formatting tests for the <code>fmt</code> package</a>. </p> @@ -1590,30 +1569,40 @@ and uses a variant of the Plan 9 loader to generate ELF/Mach-O/PE binaries. </p> <p> -We considered writing <code>gc</code>, the original Go compiler, in Go itself but +We considered using LLVM for <code>gc</code> but we felt it was too large and +slow to meet our performance goals. +</p> + +<p> +We also considered writing <code>gc</code>, the original Go compiler, in Go itself but elected not to do so because of the difficulties of bootstrapping and especially of open source distribution—you'd need a Go compiler to set up a Go environment. <code>Gccgo</code>, which came later, makes it possible to -consider writing a compiler in Go, which might well happen. -(Go would be a -fine language in which to implement a compiler; a native lexer and -parser are already available in the <a href="/pkg/go/"><code>go</code></a> package -and a type checker is in the works.) +consider writing a compiler in Go. +A plan to do that by machine translation of the existing compiler is under development. +<a href="http://golang.org/s/go13compiler">A separate document</a> +explains the reason for this approach. </p> <p> -We also considered using LLVM for <code>gc</code> but we felt it was too large and -slow to meet our performance goals. +That plan aside, +Go is a +fine language in which to implement a self-hosting compiler: a native lexer and +parser are already available in the <a href="/pkg/go/"><code>go</code></a> package +and a separate type checking +<a href="http://godoc.org/golang.org/x/tools/go/types">package</a> +has also been written. </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 is mostly in C (with a -tiny bit of assembler) although Go is capable of implementing most of -it now. <code>Gccgo</code>'s run-time support uses <code>glibc</code>. -<code>Gc</code> uses a custom library to keep the footprint under +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 +and one day all of it might be (except for the assembler bits). +<code>Gccgo</code>'s run-time support uses <code>glibc</code>. +<code>Gc</code> uses a custom C library to keep the footprint under control; it is compiled with a version of the Plan 9 C compiler that supports resizable stacks for goroutines. @@ -1637,8 +1626,8 @@ 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> -is around 1.2 MB, but -that includes more powerful run-time support. +is around 1.9 MB, but +that includes more powerful run-time support and type information. </p> <h3 id="unused_variables_and_imports"> @@ -1646,14 +1635,17 @@ 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. -Accumulate enough unused imports in your code tree and -things can get very slow. -For these reasons, Go allows neither. +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> -When developing code, it's common to create these situations +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> @@ -1695,6 +1687,14 @@ func main() { } </pre> +<p> +Nowadays, most Go programmers use a tool, +<a href="http://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> + <h2 id="Performance">Performance</h2> <h3 id="Why_does_Go_perform_badly_on_benchmark_x"> |