diff options
Diffstat (limited to 'doc/go_faq.html')
| -rw-r--r-- | doc/go_faq.html | 162 |
1 files changed, 146 insertions, 16 deletions
diff --git a/doc/go_faq.html b/doc/go_faq.html index 5c68aa7e5..62a564b6b 100644 --- a/doc/go_faq.html +++ b/doc/go_faq.html @@ -157,6 +157,12 @@ and so on. These cannot be addressed well by libraries or tools; a new language was called for. </p> +<p> +The article <a href="http://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> @@ -216,6 +222,13 @@ document server running in a production configuration on <a href="https://developers.google.com/appengine/">Google App Engine</a>. </p> +<p> +Other examples include the <a href="https://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. +</p> + <h3 id="Do_Go_programs_link_with_Cpp_programs"> Do Go programs link with C/C++ programs?</h3> @@ -394,6 +407,8 @@ 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"> @@ -439,6 +454,34 @@ as when hosting an untrusted program, the implementation could interlock map access. </p> +<h3 id="language_changes"> +Will you accept my language change?</h3> + +<p> +People often suggest improvements to the language—the +<a href="http://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. +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 we're not ready +to start talking about what that might be. +</p> + +<p> +Even if your proposal is compatible with the Go 1 spec, it may be +not be in the spirit of Go's design goals. +The article <i><a href="http://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"> @@ -874,11 +917,11 @@ 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. Introducing reference types, -including slices to handle the reference form of arrays, resolved -these issues. Reference types add some regrettable complexity to the -language but they have a large effect on usability: Go became a more -productive, comfortable language when they were introduced. +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> @@ -949,6 +992,38 @@ 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> + +<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> +If you use <code>git</code> and prefer to push changes through SSH using your existing key +it's easy to work around this. For GitHub, try one of these solutions: +</p> +<ul> +<li>Manually clone the repository in the expected package directory: +<pre> +$ cd $GOPATH/src/github.com/username +$ git clone git@github.com:username/package.git +</pre> +</li> +<li>Force <code>git push</code> to use the <code>SSH</code> protocol by appending +these two lines to <code>~/.gitconfig</code>: +<pre> +[url "git@github.com:"] + pushInsteadOf = https://github.com/ +</pre> +</li> +</ul> + <h2 id="Pointers">Pointers and Allocation</h2> <h3 id="pass_by_value"> @@ -974,6 +1049,57 @@ 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> +<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 however 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 a 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> @@ -997,7 +1123,7 @@ There are several considerations. 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 are reference types, so their story is a little +(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 @@ -1048,7 +1174,7 @@ of Effective Go</a> for more details. </p> <h3 id="q_int_sizes"> -Why is <code>int</code> 32 bits on 64 bit machines?</h3> +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 @@ -1065,12 +1191,6 @@ floating-point numbers. The default size of a floating-point constant is <code>float64</code>. </p> -<p> -At the moment, all implementations use 32-bit ints, an essentially arbitrary decision. -However, we expect that <code>int</code> will be increased to 64 bits on 64-bit -architectures in a future release of Go. -</p> - <h3 id="stack_or_heap"> How do I know whether a variable is allocated on the heap or the stack?</h3> @@ -1154,6 +1274,9 @@ run-time support to utilize more than one OS thread. <p> Programs that perform parallel computation should benefit from an increase in <code>GOMAXPROCS</code>. +However, be aware that +<a href="http://blog.golang.org/2013/01/concurrency-is-not-parallelism.html">concurrency +is not parallelism</a>. </p> <h3 id="Why_GOMAXPROCS"> @@ -1187,6 +1310,11 @@ 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> +<p> +For more detail on this topic see the talk entitled, +<a href="http://blog.golang.org/2013/01/concurrency-is-not-parallelism.html">Concurrency +is not Parallelism</a>. + <h2 id="Functions_methods">Functions and Methods</h2> <h3 id="different_method_sets"> @@ -1407,7 +1535,7 @@ test cases. The standard Go library is full of illustrative examples, such as in What compiler technology is used to build the compilers?</h3> <p> -<code>Gccgo</code> has a C++ front-end 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 <code>yacc</code>/<code>bison</code> for the parser. Although it's a new program, it fits in the Plan 9 C compiler suite @@ -1420,9 +1548,11 @@ We considered writing <code>gc</code>, the original Go compiler, in Go itself bu 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 +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.) +parser are already available in the <a href="/pkg/go/"><code>go</code></a> package +and a type checker is in the works.) </p> <p> |