github.com/razvanm/vanadium-go-1.3@v0.0.0-20160721203343-4a65068e5915/doc/go_faq.html (about)

     1  <!--{
     2  	"Title": "Frequently Asked Questions (FAQ)",
     3  	"Path": "/doc/faq"
     4  }-->
     5  
     6  <h2 id="Origins">Origins</h2>
     7  
     8  <h3 id="What_is_the_purpose_of_the_project">
     9  What is the purpose of the project?</h3>
    10  
    11  <p>
    12  No major systems language has emerged in over a decade, but over that time
    13  the computing landscape has changed tremendously. There are several trends:
    14  </p>
    15  
    16  <ul>
    17  <li>
    18  Computers are enormously quicker but software development is not faster.
    19  <li>
    20  Dependency management is a big part of software development today but the
    21  &ldquo;header files&rdquo; of languages in the C tradition are antithetical to clean
    22  dependency analysis&mdash;and fast compilation.
    23  <li>
    24  There is a growing rebellion against cumbersome type systems like those of
    25  Java and C++, pushing people towards dynamically typed languages such as
    26  Python and JavaScript.
    27  <li>
    28  Some fundamental concepts such as garbage collection and parallel computation
    29  are not well supported by popular systems languages.
    30  <li>
    31  The emergence of multicore computers has generated worry and confusion.
    32  </ul>
    33  
    34  <p>
    35  We believe it's worth trying again with a new language, a concurrent,
    36  garbage-collected language with fast compilation. Regarding the points above:
    37  </p>
    38  
    39  <ul>
    40  <li>
    41  It is possible to compile a large Go program in a few seconds on a single computer.
    42  <li>
    43  Go provides a model for software construction that makes dependency
    44  analysis easy and avoids much of the overhead of C-style include files and
    45  libraries.
    46  <li>
    47  Go's type system has no hierarchy, so no time is spent defining the
    48  relationships between types. Also, although Go has static types the language
    49  attempts to make types feel lighter weight than in typical OO languages.
    50  <li>
    51  Go is fully garbage-collected and provides fundamental support for
    52  concurrent execution and communication.
    53  <li>
    54  By its design, Go proposes an approach for the construction of system
    55  software on multicore machines.
    56  </ul>
    57  
    58  <p>
    59  A much more expansive answer to this question is available in the article,
    60  <a href="//talks.golang.org/2012/splash.article">Go at Google:
    61  Language Design in the Service of Software Engineering</a>.
    62  
    63  <h3 id="What_is_the_status_of_the_project">
    64  What is the status of the project?</h3>
    65  
    66  <p>
    67  Go became a public open source project on November 10, 2009.
    68  After a couple of years of very active design and development, stability was called for and
    69  Go 1 was <a href="//blog.golang.org/2012/03/go-version-1-is-released.html">released</a>
    70  on March 28, 2012.
    71  Go 1, which includes a <a href="/ref/spec">language specification</a>,
    72  <a href="/pkg/">standard libraries</a>,
    73  and <a href="/cmd/go/">custom tools</a>,
    74  provides a stable foundation for creating reliable products, projects, and publications.
    75  </p>
    76  
    77  <p>
    78  With that stability established, we are using Go to develop programs, products, and tools rather than
    79  actively changing the language and libraries.
    80  In fact, the purpose of Go 1 is to provide <a href="/doc/go1compat.html">long-term stability</a>.
    81  Backwards-incompatible changes will not be made to any Go 1 point release.
    82  We want to use what we have to learn how a future version of Go might look, rather than to play with
    83  the language underfoot.
    84  </p>
    85  
    86  <p>
    87  Of course, development will continue on Go itself, but the focus will be on performance, reliability,
    88  portability and the addition of new functionality such as improved support for internationalization.
    89  </p>
    90  
    91  <p>
    92  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.
    93  </p>
    94  
    95  <h3 id="What_is_the_origin_of_the_name">
    96  What is the origin of the name?</h3>
    97  
    98  <p>
    99  &ldquo;Ogle&rdquo; would be a good name for a Go debugger.
   100  </p>
   101  
   102  <h3 id="Whats_the_origin_of_the_mascot">
   103  What's the origin of the mascot?</h3>
   104  
   105  <p>
   106  The mascot and logo were designed by
   107  <a href="http://reneefrench.blogspot.com">Renée French</a>, who also designed
   108  <a href="http://plan9.bell-labs.com/plan9/glenda.html">Glenda</a>,
   109  the Plan 9 bunny.
   110  The gopher is derived from one she used for an <a href="http://wfmu.org/">WFMU</a>
   111  T-shirt design some years ago.
   112  The logo and mascot are covered by the
   113  <a href="http://creativecommons.org/licenses/by/3.0/">Creative Commons Attribution 3.0</a>
   114  license.
   115  </p>
   116  
   117  <h3 id="history">
   118  What is the history of the project?</h3>
   119  <p>
   120  Robert Griesemer, Rob Pike and Ken Thompson started sketching the
   121  goals for a new language on the white board on September 21, 2007.
   122  Within a few days the goals had settled into a plan to do something
   123  and a fair idea of what it would be.  Design continued part-time in
   124  parallel with unrelated work.  By January 2008, Ken had started work
   125  on a compiler with which to explore ideas; it generated C code as its
   126  output.  By mid-year the language had become a full-time project and
   127  had settled enough to attempt a production compiler.  In May 2008,
   128  Ian Taylor independently started on a GCC front end for Go using the
   129  draft specification.  Russ Cox joined in late 2008 and helped move the language
   130  and libraries from prototype to reality.
   131  </p>
   132  
   133  <p>
   134  Go became a public open source project on November 10, 2009.
   135  Many people from the community have contributed ideas, discussions, and code.
   136  </p>
   137  
   138  <h3 id="creating_a_new_language">
   139  Why are you creating a new language?</h3>
   140  <p>
   141  Go was born out of frustration with existing languages and
   142  environments for systems programming.  Programming had become too
   143  difficult and the choice of languages was partly to blame.  One had to
   144  choose either efficient compilation, efficient execution, or ease of
   145  programming; all three were not available in the same mainstream
   146  language.  Programmers who could were choosing ease over
   147  safety and efficiency by moving to dynamically typed languages such as
   148  Python and JavaScript rather than C++ or, to a lesser extent, Java.
   149  </p>
   150  
   151  <p>
   152  Go is an attempt to combine the ease of programming of an interpreted,
   153  dynamically typed
   154  language with the efficiency and safety of a statically typed, compiled language.
   155  It also aims to be modern, with support for networked and multicore
   156  computing.  Finally, it is intended to be <i>fast</i>: it should take
   157  at most a few seconds to build a large executable on a single computer.
   158  To meet these goals required addressing a number of
   159  linguistic issues: an expressive but lightweight type system;
   160  concurrency and garbage collection; rigid dependency specification;
   161  and so on.  These cannot be addressed well by libraries or tools; a new
   162  language was called for.
   163  </p>
   164  
   165  <p>
   166  The article <a href="//talks.golang.org/2012/splash.article">Go at Google</a>
   167  discusses the background and motivation behind the design of the Go language,
   168  as well as providing more detail about many of the answers presented in this FAQ.
   169  </p>
   170  
   171  <h3 id="ancestors">
   172  What are Go's ancestors?</h3>
   173  <p>
   174  Go is mostly in the C family (basic syntax),
   175  with significant input from the Pascal/Modula/Oberon
   176  family (declarations, packages),
   177  plus some ideas from languages
   178  inspired by Tony Hoare's CSP,
   179  such as Newsqueak and Limbo (concurrency).
   180  However, it is a new language across the board.
   181  In every respect the language was designed by thinking
   182  about what programmers do and how to make programming, at least the
   183  kind of programming we do, more effective, which means more fun.
   184  </p>
   185  
   186  <h3 id="principles">
   187  What are the guiding principles in the design?</h3>
   188  <p>
   189  Programming today involves too much bookkeeping, repetition, and
   190  clerical work.  As Dick Gabriel says, &ldquo;Old programs read
   191  like quiet conversations between a well-spoken research worker and a
   192  well-studied mechanical colleague, not as a debate with a compiler.
   193  Who'd have guessed sophistication bought such noise?&rdquo;
   194  The sophistication is worthwhile&mdash;no one wants to go back to
   195  the old languages&mdash;but can it be more quietly achieved?
   196  </p>
   197  <p>
   198  Go attempts to reduce the amount of typing in both senses of the word.
   199  Throughout its design, we have tried to reduce clutter and
   200  complexity.  There are no forward declarations and no header files;
   201  everything is declared exactly once.  Initialization is expressive,
   202  automatic, and easy to use.  Syntax is clean and light on keywords.
   203  Stuttering (<code>foo.Foo* myFoo = new(foo.Foo)</code>) is reduced by
   204  simple type derivation using the <code>:=</code>
   205  declare-and-initialize construct.  And perhaps most radically, there
   206  is no type hierarchy: types just <i>are</i>, they don't have to
   207  announce their relationships.  These simplifications allow Go to be
   208  expressive yet comprehensible without sacrificing, well, sophistication.
   209  </p>
   210  <p>
   211  Another important principle is to keep the concepts orthogonal.
   212  Methods can be implemented for any type; structures represent data while
   213  interfaces represent abstraction; and so on.  Orthogonality makes it
   214  easier to understand what happens when things combine.
   215  </p>
   216  
   217  <h2 id="Usage">Usage</h2>
   218  
   219  <h3 id="Is_Google_using_go_internally"> Is Google using Go internally?</h3>
   220  
   221  <p>
   222  Yes. There are now several Go programs deployed in
   223  production inside Google.  A public example is the server behind
   224  <a href="//golang.org">golang.org</a>.
   225  It's just the <a href="/cmd/godoc"><code>godoc</code></a>
   226  document server running in a production configuration on
   227  <a href="https://developers.google.com/appengine/">Google App Engine</a>.
   228  </p>
   229  
   230  <p>
   231  Other examples include the <a href="https://code.google.com/p/vitess/">Vitess</a>
   232  system for large-scale SQL installations and Google's download server, <code>dl.google.com</code>,
   233  which delivers Chrome binaries and other large installables such as <code>apt-get</code>
   234  packages.
   235  </p>
   236  
   237  <h3 id="Do_Go_programs_link_with_Cpp_programs">
   238  Do Go programs link with C/C++ programs?</h3>
   239  
   240  <p>
   241  There are two Go compiler implementations, <code>gc</code>
   242  (the <code>6g</code> program and friends) and <code>gccgo</code>.
   243  <code>Gc</code> uses a different calling convention and linker and can
   244  therefore only be linked with C programs using the same convention.
   245  There is such a C compiler but no C++ compiler.
   246  <code>Gccgo</code> is a GCC front-end that can, with care, be linked with
   247  GCC-compiled C or C++ programs.
   248  </p>
   249  
   250  <p>
   251  The <a href="/cmd/cgo/">cgo</a> program provides the mechanism for a
   252  &ldquo;foreign function interface&rdquo; to allow safe calling of
   253  C libraries from Go code. SWIG extends this capability to C++ libraries.
   254  </p>
   255  
   256  
   257  <h3 id="Does_Go_support_Google_protocol_buffers">
   258  Does Go support Google's protocol buffers?</h3>
   259  
   260  <p>
   261  A separate open source project provides the necessary compiler plugin and library.
   262  It is available at
   263  <a href="//code.google.com/p/goprotobuf/">code.google.com/p/goprotobuf/</a>
   264  </p>
   265  
   266  
   267  <h3 id="Can_I_translate_the_Go_home_page">
   268  Can I translate the Go home page into another language?</h3>
   269  
   270  <p>
   271  Absolutely. We encourage developers to make Go Language sites in their own languages.
   272  However, if you choose to add the Google logo or branding to your site
   273  (it does not appear on <a href="//golang.org/">golang.org</a>),
   274  you will need to abide by the guidelines at
   275  <a href="//www.google.com/permissions/guidelines.html">www.google.com/permissions/guidelines.html</a>
   276  </p>
   277  
   278  <h2 id="Design">Design</h2>
   279  
   280  <h3 id="unicode_identifiers">
   281  What's up with Unicode identifiers?</h3>
   282  
   283  <p>
   284  It was important to us to extend the space of identifiers from the
   285  confines of ASCII.  Go's rule&mdash;identifier characters must be
   286  letters or digits as defined by Unicode&mdash;is simple to understand
   287  and to implement but has restrictions.  Combining characters are
   288  excluded by design, for instance.
   289  Until there
   290  is an agreed external definition of what an identifier might be,
   291  plus a definition of canonicalization of identifiers that guarantees
   292  no ambiguity, it seemed better to keep combining characters out of
   293  the mix.  Thus we have a simple rule that can be expanded later
   294  without breaking programs, one that avoids bugs that would surely arise
   295  from a rule that admits ambiguous identifiers.
   296  </p>
   297  
   298  <p>
   299  On a related note, since an exported identifier must begin with an
   300  upper-case letter, identifiers created from &ldquo;letters&rdquo;
   301  in some languages can, by definition, not be exported.  For now the
   302  only solution is to use something like <code>X日本語</code>, which
   303  is clearly unsatisfactory; we are considering other options.  The
   304  case-for-visibility rule is unlikely to change however; it's one
   305  of our favorite features of Go.
   306  </p>
   307  
   308  <h3 id="Why_doesnt_Go_have_feature_X">Why does Go not have feature X?</h3>
   309  
   310  <p>
   311  Every language contains novel features and omits someone's favorite
   312  feature. Go was designed with an eye on felicity of programming, speed of
   313  compilation, orthogonality of concepts, and the need to support features
   314  such as concurrency and garbage collection. Your favorite feature may be
   315  missing because it doesn't fit, because it affects compilation speed or
   316  clarity of design, or because it would make the fundamental system model
   317  too difficult.
   318  </p>
   319  
   320  <p>
   321  If it bothers you that Go is missing feature <var>X</var>,
   322  please forgive us and investigate the features that Go does have. You might find that
   323  they compensate in interesting ways for the lack of <var>X</var>.
   324  </p>
   325  
   326  <h3 id="generics">
   327  Why does Go not have generic types?</h3>
   328  <p>
   329  Generics may well be added at some point.  We don't feel an urgency for
   330  them, although we understand some programmers do.
   331  </p>
   332  
   333  <p>
   334  Generics are convenient but they come at a cost in
   335  complexity in the type system and run-time.  We haven't yet found a
   336  design that gives value proportionate to the complexity, although we
   337  continue to think about it.  Meanwhile, Go's built-in maps and slices,
   338  plus the ability to use the empty interface to construct containers
   339  (with explicit unboxing) mean in many cases it is possible to write
   340  code that does what generics would enable, if less smoothly.
   341  </p>
   342  
   343  <p>
   344  This remains an open issue.
   345  </p>
   346  
   347  <h3 id="exceptions">
   348  Why does Go not have exceptions?</h3>
   349  <p>
   350  We believe that coupling exceptions to a control
   351  structure, as in the <code>try-catch-finally</code> idiom, results in
   352  convoluted code.  It also tends to encourage programmers to label
   353  too many ordinary errors, such as failing to open a file, as
   354  exceptional.
   355  </p>
   356  
   357  <p>
   358  Go takes a different approach.  For plain error handling, Go's multi-value
   359  returns make it easy to report an error without overloading the return value.
   360  <a href="/doc/articles/error_handling.html">A canonical error type, coupled
   361  with Go's other features</a>, makes error handling pleasant but quite different
   362  from that in other languages.
   363  </p>
   364  
   365  <p>
   366  Go also has a couple
   367  of built-in functions to signal and recover from truly exceptional
   368  conditions.  The recovery mechanism is executed only as part of a
   369  function's state being torn down after an error, which is sufficient
   370  to handle catastrophe but requires no extra control structures and,
   371  when used well, can result in clean error-handling code.
   372  </p>
   373  
   374  <p>
   375  See the <a href="/doc/articles/defer_panic_recover.html">Defer, Panic, and Recover</a> article for details.
   376  </p>
   377  
   378  <h3 id="assertions">
   379  Why does Go not have assertions?</h3>
   380  
   381  <p>
   382  Go doesn't provide assertions. They are undeniably convenient, but our
   383  experience has been that programmers use them as a crutch to avoid thinking
   384  about proper error handling and reporting. Proper error handling means that
   385  servers continue operation after non-fatal errors instead of crashing.
   386  Proper error reporting means that errors are direct and to the point,
   387  saving the programmer from interpreting a large crash trace. Precise
   388  errors are particularly important when the programmer seeing the errors is
   389  not familiar with the code.
   390  </p>
   391  
   392  <p>
   393  We understand that this is a point of contention. There are many things in
   394  the Go language and libraries that differ from modern practices, simply
   395  because we feel it's sometimes worth trying a different approach.
   396  </p>
   397  
   398  <h3 id="csp">
   399  Why build concurrency on the ideas of CSP?</h3>
   400  <p>
   401  Concurrency and multi-threaded programming have a reputation
   402  for difficulty.  We believe this is due partly to complex
   403  designs such as pthreads and partly to overemphasis on low-level details
   404  such as mutexes, condition variables, and memory barriers.
   405  Higher-level interfaces enable much simpler code, even if there are still
   406  mutexes and such under the covers.
   407  </p>
   408  
   409  <p>
   410  One of the most successful models for providing high-level linguistic support
   411  for concurrency comes from Hoare's Communicating Sequential Processes, or CSP.
   412  Occam and Erlang are two well known languages that stem from CSP.
   413  Go's concurrency primitives derive from a different part of the family tree
   414  whose main contribution is the powerful notion of channels as first class objects.
   415  Experience with several earlier languages has shown that the CSP model
   416  fits well into a procedural language framework.
   417  </p>
   418  
   419  <h3 id="goroutines">
   420  Why goroutines instead of threads?</h3>
   421  <p>
   422  Goroutines are part of making concurrency easy to use.  The idea, which has
   423  been around for a while, is to multiplex independently executing
   424  functions&mdash;coroutines&mdash;onto a set of threads.
   425  When a coroutine blocks, such as by calling a blocking system call,
   426  the run-time automatically moves other coroutines on the same operating
   427  system thread to a different, runnable thread so they won't be blocked.
   428  The programmer sees none of this, which is the point.
   429  The result, which we call goroutines, can be very cheap: they have little
   430  overhead beyond the memory for the stack, which is just a few kilobytes.
   431  </p>
   432  
   433  <p>
   434  To make the stacks small, Go's run-time uses resizable, bounded stacks.  A newly
   435  minted goroutine is given a few kilobytes, which is almost always enough.
   436  When it isn't, the run-time grows (and shrinks) the memory for storing
   437  the stack automatically, allowing many goroutines to live in a modest
   438  amount of memory.
   439  The CPU overhead averages about three cheap instructions per function call.
   440  It is practical to create hundreds of thousands of goroutines in the same
   441  address space.
   442  If goroutines were just threads, system resources would
   443  run out at a much smaller number.
   444  </p>
   445  
   446  <h3 id="atomic_maps">
   447  Why are map operations not defined to be atomic?</h3>
   448  
   449  <p>
   450  After long discussion it was decided that the typical use of maps did not require
   451  safe access from multiple goroutines, and in those cases where it did, the map was
   452  probably part of some larger data structure or computation that was already
   453  synchronized.  Therefore requiring that all map operations grab a mutex would slow
   454  down most programs and add safety to few.  This was not an easy decision,
   455  however, since it means uncontrolled map access can crash the program.
   456  </p>
   457  
   458  <p>
   459  The language does not preclude atomic map updates.  When required, such
   460  as when hosting an untrusted program, the implementation could interlock
   461  map access.
   462  </p>
   463  
   464  <h3 id="language_changes">
   465  Will you accept my language change?</h3>
   466  
   467  <p>
   468  People often suggest improvements to the language—the
   469  <a href="//groups.google.com/group/golang-nuts">mailing list</a>
   470  contains a rich history of such discussions—but very few of these changes have
   471  been accepted.
   472  </p>
   473  
   474  <p>
   475  Although Go is an open source project, the language and libraries are protected
   476  by a <a href="/doc/go1compat.html">compatibility promise</a> that prevents
   477  changes that break existing programs.
   478  If your proposal violates the Go 1 specification we cannot even entertain the
   479  idea, regardless of its merit.
   480  A future major release of Go may be incompatible with Go 1, but we're not ready
   481  to start talking about what that might be.
   482  </p>
   483  
   484  <p>
   485  Even if your proposal is compatible with the Go 1 spec, it might
   486  not be in the spirit of Go's design goals.
   487  The article <i><a href="//talks.golang.org/2012/splash.article">Go
   488  at Google: Language Design in the Service of Software Engineering</a></i>
   489  explains Go's origins and the motivation behind its design.
   490  </p>
   491  
   492  <h2 id="types">Types</h2>
   493  
   494  <h3 id="Is_Go_an_object-oriented_language">
   495  Is Go an object-oriented language?</h3>
   496  
   497  <p>
   498  Yes and no. Although Go has types and methods and allows an
   499  object-oriented style of programming, there is no type hierarchy.
   500  The concept of &ldquo;interface&rdquo; in Go provides a different approach that
   501  we believe is easy to use and in some ways more general. There are
   502  also ways to embed types in other types to provide something
   503  analogous&mdash;but not identical&mdash;to subclassing.
   504  Moreover, methods in Go are more general than in C++ or Java:
   505  they can be defined for any sort of data, even built-in types such
   506  as plain, &ldquo;unboxed&rdquo; integers.
   507  They are not restricted to structs (classes).
   508  </p>
   509  
   510  <p>
   511  Also, the lack of type hierarchy makes &ldquo;objects&rdquo; in Go feel much more
   512  lightweight than in languages such as C++ or Java.
   513  </p>
   514  
   515  <h3 id="How_do_I_get_dynamic_dispatch_of_methods">
   516  How do I get dynamic dispatch of methods?</h3>
   517  
   518  <p>
   519  The only way to have dynamically dispatched methods is through an
   520  interface. Methods on a struct or any other concrete type are always resolved statically.
   521  </p>
   522  
   523  <h3 id="inheritance">
   524  Why is there no type inheritance?</h3>
   525  <p>
   526  Object-oriented programming, at least in the best-known languages,
   527  involves too much discussion of the relationships between types,
   528  relationships that often could be derived automatically.  Go takes a
   529  different approach.
   530  </p>
   531  
   532  <p>
   533  Rather than requiring the programmer to declare ahead of time that two
   534  types are related, in Go a type automatically satisfies any interface
   535  that specifies a subset of its methods.  Besides reducing the
   536  bookkeeping, this approach has real advantages.  Types can satisfy
   537  many interfaces at once, without the complexities of traditional
   538  multiple inheritance.
   539  Interfaces can be very lightweight&mdash;an interface with
   540  one or even zero methods can express a useful concept.
   541  Interfaces can be added after the fact if a new idea comes along
   542  or for testing&mdash;without annotating the original types.
   543  Because there are no explicit relationships between types
   544  and interfaces, there is no type hierarchy to manage or discuss.
   545  </p>
   546  
   547  <p>
   548  It's possible to use these ideas to construct something analogous to
   549  type-safe Unix pipes.  For instance, see how <code>fmt.Fprintf</code>
   550  enables formatted printing to any output, not just a file, or how the
   551  <code>bufio</code> package can be completely separate from file I/O,
   552  or how the <code>image</code> packages generate compressed
   553  image files.  All these ideas stem from a single interface
   554  (<code>io.Writer</code>) representing a single method
   555  (<code>Write</code>).  And that's only scratching the surface.
   556  Go's interfaces have a profound influence on how programs are structured.
   557  </p>
   558  
   559  <p>
   560  It takes some getting used to but this implicit style of type
   561  dependency is one of the most productive things about Go.
   562  </p>
   563  
   564  <h3 id="methods_on_basics">
   565  Why is <code>len</code> a function and not a method?</h3>
   566  <p>
   567  We debated this issue but decided
   568  implementing <code>len</code> and friends as functions was fine in practice and
   569  didn't complicate questions about the interface (in the Go type sense)
   570  of basic types.
   571  </p>
   572  
   573  <h3 id="overloading">
   574  Why does Go not support overloading of methods and operators?</h3>
   575  <p>
   576  Method dispatch is simplified if it doesn't need to do type matching as well.
   577  Experience with other languages told us that having a variety of
   578  methods with the same name but different signatures was occasionally useful
   579  but that it could also be confusing and fragile in practice.  Matching only by name
   580  and requiring consistency in the types was a major simplifying decision
   581  in Go's type system.
   582  </p>
   583  
   584  <p>
   585  Regarding operator overloading, it seems more a convenience than an absolute
   586  requirement.  Again, things are simpler without it.
   587  </p>
   588  
   589  <h3 id="implements_interface">
   590  Why doesn't Go have "implements" declarations?</h3>
   591  
   592  <p>
   593  A Go type satisfies an interface by implementing the methods of that interface,
   594  nothing more.  This property allows interfaces to be defined and used without
   595  having to modify existing code.  It enables a kind of structural typing that
   596  promotes separation of concerns and improves code re-use, and makes it easier
   597  to build on patterns that emerge as the code develops.
   598  The semantics of interfaces is one of the main reasons for Go's nimble,
   599  lightweight feel.
   600  </p>
   601  
   602  <p>
   603  See the <a href="#inheritance">question on type inheritance</a> for more detail.
   604  </p>
   605  
   606  <h3 id="guarantee_satisfies_interface">
   607  How can I guarantee my type satisfies an interface?</h3>
   608  
   609  <p>
   610  You can ask the compiler to check that the type <code>T</code> implements the
   611  interface <code>I</code> by attempting an assignment:
   612  </p>
   613  
   614  <pre>
   615  type T struct{}
   616  var _ I = T{}   // Verify that T implements I.
   617  </pre>
   618  
   619  <p>
   620  If <code>T</code> doesn't implement <code>I</code>, the mistake will be caught
   621  at compile time.
   622  </p>
   623  
   624  <p>
   625  If you wish the users of an interface to explicitly declare that they implement
   626  it, you can add a method with a descriptive name to the interface's method set.
   627  For example:
   628  </p>
   629  
   630  <pre>
   631  type Fooer interface {
   632      Foo()
   633      ImplementsFooer()
   634  }
   635  </pre>
   636  
   637  <p>
   638  A type must then implement the <code>ImplementsFooer</code> method to be a
   639  <code>Fooer</code>, clearly documenting the fact and announcing it in
   640  <a href="/cmd/godoc/">godoc</a>'s output.
   641  </p>
   642  
   643  <pre>
   644  type Bar struct{}
   645  func (b Bar) ImplementsFooer() {}
   646  func (b Bar) Foo() {}
   647  </pre>
   648  
   649  <p>
   650  Most code doesn't make use of such constraints, since they limit the utility of
   651  the interface idea. Sometimes, though, they're necessary to resolve ambiguities
   652  among similar interfaces.
   653  </p>
   654  
   655  <h3 id="t_and_equal_interface">
   656  Why doesn't type T satisfy the Equal interface?</h3>
   657  
   658  <p>
   659  Consider this simple interface to represent an object that can compare
   660  itself with another value:
   661  </p>
   662  
   663  <pre>
   664  type Equaler interface {
   665      Equal(Equaler) bool
   666  }
   667  </pre>
   668  
   669  <p>
   670  and this type, <code>T</code>:
   671  </p>
   672  
   673  <pre>
   674  type T int
   675  func (t T) Equal(u T) bool { return t == u } // does not satisfy Equaler
   676  </pre>
   677  
   678  <p>
   679  Unlike the analogous situation in some polymorphic type systems,
   680  <code>T</code> does not implement <code>Equaler</code>.
   681  The argument type of <code>T.Equal</code> is <code>T</code>,
   682  not literally the required type <code>Equaler</code>.
   683  </p>
   684  
   685  <p>
   686  In Go, the type system does not promote the argument of
   687  <code>Equal</code>; that is the programmer's responsibility, as
   688  illustrated by the type <code>T2</code>, which does implement
   689  <code>Equaler</code>:
   690  </p>
   691  
   692  <pre>
   693  type T2 int
   694  func (t T2) Equal(u Equaler) bool { return t == u.(T2) }  // satisfies Equaler
   695  </pre>
   696  
   697  <p>
   698  Even this isn't like other type systems, though, because in Go <em>any</em>
   699  type that satisfies <code>Equaler</code> could be passed as the
   700  argument to <code>T2.Equal</code>, and at run time we must
   701  check that the argument is of type <code>T2</code>.
   702  Some languages arrange to make that guarantee at compile time.
   703  </p>
   704  
   705  <p>
   706  A related example goes the other way:
   707  </p>
   708  
   709  <pre>
   710  type Opener interface {
   711     Open() Reader
   712  }
   713  
   714  func (t T3) Open() *os.File
   715  </pre>
   716  
   717  <p>
   718  In Go, <code>T3</code> does not satisfy <code>Opener</code>,
   719  although it might in another language.
   720  </p>
   721  
   722  <p>
   723  While it is true that Go's type system does less for the programmer
   724  in such cases, the lack of subtyping makes the rules about
   725  interface satisfaction very easy to state: are the function's names
   726  and signatures exactly those of the interface?
   727  Go's rule is also easy to implement efficiently.
   728  We feel these benefits offset the lack of
   729  automatic type promotion. Should Go one day adopt some form of generic
   730  typing, we expect there would be a way to express the idea of these
   731  examples and also have them be statically checked.
   732  </p>
   733  
   734  <h3 id="convert_slice_of_interface">
   735  Can I convert a []T to an []interface{}?</h3>
   736  
   737  <p>
   738  Not directly, because they do not have the same representation in memory.
   739  It is necessary to copy the elements individually to the destination
   740  slice. This example converts a slice of <code>int</code> to a slice of
   741  <code>interface{}</code>:
   742  </p>
   743  
   744  <pre>
   745  t := []int{1, 2, 3, 4}
   746  s := make([]interface{}, len(t))
   747  for i, v := range t {
   748      s[i] = v
   749  }
   750  </pre>
   751  
   752  <h3 id="nil_error">
   753  Why is my nil error value not equal to nil?
   754  </h3>
   755  
   756  <p>
   757  Under the covers, interfaces are implemented as two elements, a type and a value.
   758  The value, called the interface's dynamic value,
   759  is an arbitrary concrete value and the type is that of the value.
   760  For the <code>int</code> value 3, an interface value contains,
   761  schematically, (<code>int</code>, <code>3</code>).
   762  </p>
   763  
   764  <p>
   765  An interface value is <code>nil</code> only if the inner value and type are both unset,
   766  (<code>nil</code>, <code>nil</code>).
   767  In particular, a <code>nil</code> interface will always hold a <code>nil</code> type.
   768  If we store a pointer of type <code>*int</code> inside
   769  an interface value, the inner type will be <code>*int</code> regardless of the value of the pointer:
   770  (<code>*int</code>, <code>nil</code>).
   771  Such an interface value will therefore be non-<code>nil</code>
   772  <em>even when the pointer inside is</em> <code>nil</code>.
   773  </p>
   774  
   775  <p>
   776  This situation can be confusing, and often arises when a <code>nil</code> value is
   777  stored inside an interface value such as an <code>error</code> return:
   778  </p>
   779  
   780  <pre>
   781  func returnsError() error {
   782  	var p *MyError = nil
   783  	if bad() {
   784  		p = ErrBad
   785  	}
   786  	return p // Will always return a non-nil error.
   787  }
   788  </pre>
   789  
   790  <p>
   791  If all goes well, the function returns a <code>nil</code> <code>p</code>,
   792  so the return value is an <code>error</code> interface
   793  value holding (<code>*MyError</code>, <code>nil</code>).
   794  This means that if the caller compares the returned error to <code>nil</code>,
   795  it will always look as if there was an error even if nothing bad happened.
   796  To return a proper <code>nil</code> <code>error</code> to the caller,
   797  the function must return an explicit <code>nil</code>:
   798  </p>
   799  
   800  
   801  <pre>
   802  func returnsError() error {
   803  	if bad() {
   804  		return ErrBad
   805  	}
   806  	return nil
   807  }
   808  </pre>
   809  
   810  <p>
   811  It's a good idea for functions
   812  that return errors always to use the <code>error</code> type in
   813  their signature (as we did above) rather than a concrete type such
   814  as <code>*MyError</code>, to help guarantee the error is
   815  created correctly. As an example,
   816  <a href="/pkg/os/#Open"><code>os.Open</code></a>
   817  returns an <code>error</code> even though, if not <code>nil</code>,
   818  it's always of concrete type
   819  <a href="/pkg/os/#PathError"><code>*os.PathError</code></a>.
   820  </p>
   821  
   822  <p>
   823  Similar situations to those described here can arise whenever interfaces are used.
   824  Just keep in mind that if any concrete value
   825  has been stored in the interface, the interface will not be <code>nil</code>.
   826  For more information, see
   827  <a href="/doc/articles/laws_of_reflection.html">The Laws of Reflection</a>.
   828  </p>
   829  
   830  
   831  <h3 id="unions">
   832  Why are there no untagged unions, as in C?</h3>
   833  
   834  <p>
   835  Untagged unions would violate Go's memory safety
   836  guarantees.
   837  </p>
   838  
   839  <h3 id="variant_types">
   840  Why does Go not have variant types?</h3>
   841  
   842  <p>
   843  Variant types, also known as algebraic types, provide a way to specify
   844  that a value might take one of a set of other types, but only those
   845  types. A common example in systems programming would specify that an
   846  error is, say, a network error, a security error or an application
   847  error and allow the caller to discriminate the source of the problem
   848  by examining the type of the error. Another example is a syntax tree
   849  in which each node can be a different type: declaration, statement,
   850  assignment and so on.
   851  </p>
   852  
   853  <p>
   854  We considered adding variant types to Go, but after discussion
   855  decided to leave them out because they overlap in confusing ways
   856  with interfaces. What would happen if the elements of a variant type
   857  were themselves interfaces?
   858  </p>
   859  
   860  <p>
   861  Also, some of what variant types address is already covered by the
   862  language. The error example is easy to express using an interface
   863  value to hold the error and a type switch to discriminate cases.  The
   864  syntax tree example is also doable, although not as elegantly.
   865  </p>
   866  
   867  <h2 id="values">Values</h2>
   868  
   869  <h3 id="conversions">
   870  Why does Go not provide implicit numeric conversions?</h3>
   871  <p>
   872  The convenience of automatic conversion between numeric types in C is
   873  outweighed by the confusion it causes.  When is an expression unsigned?
   874  How big is the value?  Does it overflow?  Is the result portable, independent
   875  of the machine on which it executes?
   876  It also complicates the compiler; &ldquo;the usual arithmetic conversions&rdquo;
   877  are not easy to implement and inconsistent across architectures.
   878  For reasons of portability, we decided to make things clear and straightforward
   879  at the cost of some explicit conversions in the code.
   880  The definition of constants in Go&mdash;arbitrary precision values free
   881  of signedness and size annotations&mdash;ameliorates matters considerably,
   882  though.
   883  </p>
   884  
   885  <p>
   886  A related detail is that, unlike in C, <code>int</code> and <code>int64</code>
   887  are distinct types even if <code>int</code> is a 64-bit type.  The <code>int</code>
   888  type is generic; if you care about how many bits an integer holds, Go
   889  encourages you to be explicit.
   890  </p>
   891  
   892  <p>
   893  A blog post, title <a href="http://blog.golang.org/constants">Constants</a>,
   894  explores this topic in more detail.
   895  </p>
   896  
   897  <h3 id="builtin_maps">
   898  Why are maps built in?</h3>
   899  <p>
   900  The same reason strings are: they are such a powerful and important data
   901  structure that providing one excellent implementation with syntactic support
   902  makes programming more pleasant.  We believe that Go's implementation of maps
   903  is strong enough that it will serve for the vast majority of uses.
   904  If a specific application can benefit from a custom implementation, it's possible
   905  to write one but it will not be as convenient syntactically; this seems a reasonable tradeoff.
   906  </p>
   907  
   908  <h3 id="map_keys">
   909  Why don't maps allow slices as keys?</h3>
   910  <p>
   911  Map lookup requires an equality operator, which slices do not implement.
   912  They don't implement equality because equality is not well defined on such types;
   913  there are multiple considerations involving shallow vs. deep comparison, pointer vs.
   914  value comparison, how to deal with recursive types, and so on.
   915  We may revisit this issue&mdash;and implementing equality for slices
   916  will not invalidate any existing programs&mdash;but without a clear idea of what
   917  equality of slices should mean, it was simpler to leave it out for now.
   918  </p>
   919  
   920  <p>
   921  In Go 1, unlike prior releases, equality is defined for structs and arrays, so such
   922  types can be used as map keys. Slices still do not have a definition of equality, though.
   923  </p>
   924  
   925  <h3 id="references">
   926  Why are maps, slices, and channels references while arrays are values?</h3>
   927  <p>
   928  There's a lot of history on that topic.  Early on, maps and channels
   929  were syntactically pointers and it was impossible to declare or use a
   930  non-pointer instance.  Also, we struggled with how arrays should work.
   931  Eventually we decided that the strict separation of pointers and
   932  values made the language harder to use.  Changing these
   933  types to act as references to the associated, shared data structures resolved
   934  these issues. This change added some regrettable complexity to the
   935  language but had a large effect on usability: Go became a more
   936  productive, comfortable language when it was introduced.
   937  </p>
   938  
   939  <h2 id="Writing_Code">Writing Code</h2>
   940  
   941  <h3 id="How_are_libraries_documented">
   942  How are libraries documented?</h3>
   943  
   944  <p>
   945  There is a program, <code>godoc</code>, written in Go, that extracts
   946  package documentation from the source code. It can be used on the
   947  command line or on the web. An instance is running at
   948  <a href="/pkg/">golang.org/pkg/</a>.
   949  In fact, <code>godoc</code> implements the full site at
   950  <a href="/">golang.org/</a>.
   951  </p>
   952  
   953  <h3 id="Is_there_a_Go_programming_style_guide">
   954  Is there a Go programming style guide?</h3>
   955  
   956  <p>
   957  Eventually, there may be a small number of rules to guide things
   958  like naming, layout, and file organization.
   959  The document <a href="effective_go.html">Effective Go</a>
   960  contains some style advice.
   961  More directly, the program <code>gofmt</code> is a pretty-printer
   962  whose purpose is to enforce layout rules; it replaces the usual
   963  compendium of do's and don'ts that allows interpretation.
   964  All the Go code in the repository has been run through <code>gofmt</code>.
   965  </p>
   966  
   967  <p>
   968  The document titled
   969  <a href="//golang.org/s/comments">Go Code Review Comments</a>
   970  is a collection of very short essays about details of Go idiom that are often
   971  missed by programmers.
   972  It is a handy reference for people doing code reviews for Go projects.
   973  </p>
   974  
   975  <h3 id="How_do_I_submit_patches_to_the_Go_libraries">
   976  How do I submit patches to the Go libraries?</h3>
   977  
   978  <p>
   979  The library sources are in the <code>src</code> directory of the repository.
   980  If you want to make a significant change, please discuss on the mailing list before embarking.
   981  </p>
   982  
   983  <p>
   984  See the document
   985  <a href="contribute.html">Contributing to the Go project</a>
   986  for more information about how to proceed.
   987  </p>
   988  
   989  <h3 id="Why_does_the_project_use_Mercurial_and_not_git">
   990  Why does the project use Mercurial and not git?</h3>
   991  
   992  <p>
   993  The Go project, hosted by Google Code at
   994  <a href="//code.google.com/p/go">code.google.com/p/go</a>,
   995  uses Mercurial as its version control system.
   996  When the project launched,
   997  Google Code supported only Subversion and Mercurial.
   998  Mercurial was a better choice because of its plugin mechanism
   999  that allowed us to create the "codereview" plugin to connect
  1000  the project to the excellent code review tools at
  1001  <a href="//codereview.appspot.com">codereview.appspot.com</a>.
  1002  </p>
  1003  
  1004  <p>
  1005  Programmers who work
  1006  with the Go project's source rather than release downloads sometimes
  1007  ask for the project to switch to git.
  1008  That would be possible, but it would be a lot of work and
  1009  would also require reimplementing the codereview plugin.
  1010  Given that Mercurial works today, with code review support,
  1011  combined with the Go project's mostly linear, non-branching use of
  1012  version control, a switch to git doesn't seem worthwhile.
  1013  </p>
  1014  
  1015  <h3 id="git_https">
  1016  Why does "go get" use HTTPS when cloning a repository?</h3>
  1017  
  1018  <p>
  1019  Companies often permit outgoing traffic only on the standard TCP ports 80 (HTTP)
  1020  and 443 (HTTPS), blocking outgoing traffic on other ports, including TCP port 9418 
  1021  (git) and TCP port 22 (SSH).
  1022  When using HTTPS instead of HTTP, <code>git</code> enforces certificate validation by
  1023  default, providing protection against man-in-the-middle, eavesdropping and tampering attacks.
  1024  The <code>go get</code> command therefore uses HTTPS for safety.
  1025  </p>
  1026  
  1027  <p>
  1028  If you use <code>git</code> and prefer to push changes through SSH using your existing key 
  1029  it's easy to work around this. For GitHub, try one of these solutions:
  1030  </p>
  1031  <ul>
  1032  <li>Manually clone the repository in the expected package directory:
  1033  <pre>
  1034  $ cd $GOPATH/src/github.com/username
  1035  $ git clone git@github.com:username/package.git
  1036  </pre>
  1037  </li>
  1038  <li>Force <code>git push</code> to use the <code>SSH</code> protocol by appending
  1039  these two lines to <code>~/.gitconfig</code>:
  1040  <pre>
  1041  [url "git@github.com:"]
  1042  	pushInsteadOf = https://github.com/
  1043  </pre>
  1044  </li>
  1045  </ul>
  1046  
  1047  <h3 id="get_version">
  1048  How should I manage package versions using "go get"?</h3>
  1049  
  1050  <p>
  1051  "Go get" does not have any explicit concept of package versions.
  1052  Versioning is a source of significant complexity, especially in large code bases,
  1053  and we are unaware of any approach that works well at scale in a large enough
  1054  variety of situations to be appropriate to force on all Go users.
  1055  What "go get" and the larger Go toolchain do provide is isolation of
  1056  packages with different import paths.
  1057  For example, the standard library's <code>html/template</code> and <code>text/template</code>
  1058  coexist even though both are "package template".
  1059  This observation leads to some advice for package authors and package users.
  1060  </p>
  1061  
  1062  <p>
  1063  Packages intended for public use should try to maintain backwards compatibility as they evolve.
  1064  The <a href="/doc/go1compat.html">Go 1 compatibility guidelines</a> are a good reference here:
  1065  don't remove exported names, encourage tagged composite literals, and so on.
  1066  If different functionality is required, add a new name instead of changing an old one.
  1067  If a complete break is required, create a new package with a new import path.</p>
  1068  
  1069  <p>
  1070  If you're using an externally supplied package and worry that it might change in
  1071  unexpected ways, the simplest solution is to copy it to your local repository.
  1072  (This is the approach Google takes internally.)
  1073  Store the copy under a new import path that identifies it as a local copy.
  1074  For example, you might copy "original.com/pkg" to "you.com/external/original.com/pkg".
  1075  Keith Rarick's <a href="https://github.com/kr/goven">goven</a> is one tool to help automate this process.
  1076  </p>
  1077  
  1078  <h2 id="Pointers">Pointers and Allocation</h2>
  1079  
  1080  <h3 id="pass_by_value">
  1081  When are function parameters passed by value?</h3>
  1082  
  1083  <p>
  1084  As in all languages in the C family, everything in Go is passed by value.
  1085  That is, a function always gets a copy of the
  1086  thing being passed, as if there were an assignment statement assigning the
  1087  value to the parameter.  For instance, passing an <code>int</code> value
  1088  to a function makes a copy of the <code>int</code>, and passing a pointer
  1089  value makes a copy of the pointer, but not the data it points to.
  1090  (See the next section for a discussion of how this affects method receivers.)
  1091  </p>
  1092  
  1093  <p>
  1094  Map and slice values behave like pointers: they are descriptors that
  1095  contain pointers to the underlying map or slice data.  Copying a map or
  1096  slice value doesn't copy the data it points to.  Copying an interface value
  1097  makes a copy of the thing stored in the interface value.  If the interface
  1098  value holds a struct, copying the interface value makes a copy of the
  1099  struct.  If the interface value holds a pointer, copying the interface value
  1100  makes a copy of the pointer, but again not the data it points to.
  1101  </p>
  1102  
  1103  <h3 id="pointer_to_interface">
  1104  When should I use a pointer to an interface?</h3>
  1105  
  1106  <p>
  1107  Almost never. Pointers to interface values arise only in rare, tricky situations involving
  1108  disguising an interface value's type for delayed evaluation.
  1109  </p>
  1110  
  1111  <p>
  1112  It is however a common mistake to pass a pointer to an interface value
  1113  to a function expecting an interface. The compiler will complain about this
  1114  error but the situation can still be confusing, because sometimes a
  1115  <a href="#different_method_sets">pointer
  1116  is necessary to satisfy an interface</a>.
  1117  The insight is that although a pointer to a concrete type can satisfy
  1118  an interface, with one exception <em>a pointer to an interface can never satisfy an interface</em>.
  1119  </p>
  1120  
  1121  <p>
  1122  Consider the variable declaration,
  1123  </p>
  1124  
  1125  <pre>
  1126  var w io.Writer
  1127  </pre>
  1128  
  1129  <p>
  1130  The printing function <code>fmt.Fprintf</code> takes as its first argument
  1131  a value that satisfies <code>io.Writer</code>—something that implements
  1132  the canonical <code>Write</code> method. Thus we can write
  1133  </p>
  1134  
  1135  <pre>
  1136  fmt.Fprintf(w, "hello, world\n")
  1137  </pre>
  1138  
  1139  <p>
  1140  If however we pass the address of <code>w</code>, the program will not compile.
  1141  </p>
  1142  
  1143  <pre>
  1144  fmt.Fprintf(&amp;w, "hello, world\n") // Compile-time error.
  1145  </pre>
  1146  
  1147  <p>
  1148  The one exception is that any value, even a pointer to an interface, can be assigned to
  1149  a variable of empty interface type (<code>interface{}</code>).
  1150  Even so, it's almost certainly a mistake if the value is a pointer to an interface;
  1151  the result can be confusing.
  1152  </p>
  1153  
  1154  <h3 id="methods_on_values_or_pointers">
  1155  Should I define methods on values or pointers?</h3>
  1156  
  1157  <pre>
  1158  func (s *MyStruct) pointerMethod() { } // method on pointer
  1159  func (s MyStruct)  valueMethod()   { } // method on value
  1160  </pre>
  1161  
  1162  <p>
  1163  For programmers unaccustomed to pointers, the distinction between these
  1164  two examples can be confusing, but the situation is actually very simple.
  1165  When defining a method on a type, the receiver (<code>s</code> in the above
  1166  examples) behaves exactly as if it were an argument to the method.
  1167  Whether to define the receiver as a value or as a pointer is the same
  1168  question, then, as whether a function argument should be a value or
  1169  a pointer.
  1170  There are several considerations.
  1171  </p>
  1172  
  1173  <p>
  1174  First, and most important, does the method need to modify the
  1175  receiver?
  1176  If it does, the receiver <em>must</em> be a pointer.
  1177  (Slices and maps act as references, so their story is a little
  1178  more subtle, but for instance to change the length of a slice
  1179  in a method the receiver must still be a pointer.)
  1180  In the examples above, if <code>pointerMethod</code> modifies
  1181  the fields of <code>s</code>,
  1182  the caller will see those changes, but <code>valueMethod</code>
  1183  is called with a copy of the caller's argument (that's the definition
  1184  of passing a value), so changes it makes will be invisible to the caller.
  1185  </p>
  1186  
  1187  <p>
  1188  By the way, pointer receivers are identical to the situation in Java,
  1189  although in Java the pointers are hidden under the covers; it's Go's
  1190  value receivers that are unusual.
  1191  </p>
  1192  
  1193  <p>
  1194  Second is the consideration of efficiency. If the receiver is large,
  1195  a big <code>struct</code> for instance, it will be much cheaper to
  1196  use a pointer receiver.
  1197  </p>
  1198  
  1199  <p>
  1200  Next is consistency. If some of the methods of the type must have
  1201  pointer receivers, the rest should too, so the method set is
  1202  consistent regardless of how the type is used.
  1203  See the section on <a href="#different_method_sets">method sets</a>
  1204  for details.
  1205  </p>
  1206  
  1207  <p>
  1208  For types such as basic types, slices, and small <code>structs</code>,
  1209  a value receiver is very cheap so unless the semantics of the method
  1210  requires a pointer, a value receiver is efficient and clear.
  1211  </p>
  1212  
  1213  
  1214  <h3 id="new_and_make">
  1215  What's the difference between new and make?</h3>
  1216  
  1217  <p>
  1218  In short: <code>new</code> allocates memory, <code>make</code> initializes
  1219  the slice, map, and channel types.
  1220  </p>
  1221  
  1222  <p>
  1223  See the <a href="/doc/effective_go.html#allocation_new">relevant section
  1224  of Effective Go</a> for more details.
  1225  </p>
  1226  
  1227  <h3 id="q_int_sizes">
  1228  What is the size of an <code>int</code> on a 64 bit machine?</h3>
  1229  
  1230  <p>
  1231  The sizes of <code>int</code> and <code>uint</code> are implementation-specific
  1232  but the same as each other on a given platform.
  1233  For portability, code that relies on a particular
  1234  size of value should use an explicitly sized type, like <code>int64</code>.
  1235  Prior to Go 1.1, the 64-bit Go compilers (both gc and gccgo) used
  1236  a 32-bit representation for <code>int</code>. As of Go 1.1 they use
  1237  a 64-bit representation.
  1238  On the other hand, floating-point scalars and complex
  1239  numbers are always sized: <code>float32</code>, <code>complex64</code>,
  1240  etc., because programmers should be aware of precision when using
  1241  floating-point numbers.
  1242  The default size of a floating-point constant is <code>float64</code>.
  1243  </p>
  1244  
  1245  <h3 id="stack_or_heap">
  1246  How do I know whether a variable is allocated on the heap or the stack?</h3>
  1247  
  1248  <p>
  1249  From a correctness standpoint, you don't need to know.
  1250  Each variable in Go exists as long as there are references to it.
  1251  The storage location chosen by the implementation is irrelevant to the
  1252  semantics of the language.
  1253  </p>
  1254  
  1255  <p>
  1256  The storage location does have an effect on writing efficient programs.
  1257  When possible, the Go compilers will allocate variables that are
  1258  local to a function in that function's stack frame.  However, if the
  1259  compiler cannot prove that the variable is not referenced after the
  1260  function returns, then the compiler must allocate the variable on the
  1261  garbage-collected heap to avoid dangling pointer errors.
  1262  Also, if a local variable is very large, it might make more sense
  1263  to store it on the heap rather than the stack.
  1264  </p>
  1265  
  1266  <p>
  1267  In the current compilers, if a variable has its address taken, that variable
  1268  is a candidate for allocation on the heap. However, a basic <em>escape
  1269  analysis</em> recognizes some cases when such variables will not
  1270  live past the return from the function and can reside on the stack.
  1271  </p>
  1272  
  1273  <h3 id="Why_does_my_Go_process_use_so_much_virtual_memory">
  1274  Why does my Go process use so much virtual memory?</h3>
  1275  
  1276  <p>
  1277  The Go memory allocator reserves a large region of virtual memory as an arena
  1278  for allocations. This virtual memory is local to the specific Go process; the
  1279  reservation does not deprive other processes of memory.
  1280  </p>
  1281  
  1282  <p>
  1283  To find the amount of actual memory allocated to a Go process, use the Unix
  1284  <code>top</code> command and consult the <code>RES</code> (Linux) or
  1285  <code>RSIZE</code> (Mac OS X) columns.
  1286  <!-- TODO(adg): find out how this works on Windows -->
  1287  </p>
  1288  
  1289  <h2 id="Concurrency">Concurrency</h2>
  1290  
  1291  <h3 id="What_operations_are_atomic_What_about_mutexes">
  1292  What operations are atomic? What about mutexes?</h3>
  1293  
  1294  <p>
  1295  We haven't fully defined it all yet, but some details about atomicity are
  1296  available in the <a href="/ref/mem">Go Memory Model specification</a>.
  1297  </p>
  1298  
  1299  <p>
  1300  Regarding mutexes, the <a href="/pkg/sync">sync</a>
  1301  package implements them, but we hope Go programming style will
  1302  encourage people to try higher-level techniques. In particular, consider
  1303  structuring your program so that only one goroutine at a time is ever
  1304  responsible for a particular piece of data.
  1305  </p>
  1306  
  1307  <p>
  1308  Do not communicate by sharing memory. Instead, share memory by communicating.
  1309  </p>
  1310  
  1311  <p>
  1312  See the <a href="/doc/codewalk/sharemem/">Share Memory By Communicating</a> code walk and its <a href="//blog.golang.org/2010/07/share-memory-by-communicating.html">associated article</a> for a detailed discussion of this concept.
  1313  </p>
  1314  
  1315  <h3 id="Why_no_multi_CPU">
  1316  Why doesn't my multi-goroutine program use multiple CPUs?</h3>
  1317  
  1318  <p>
  1319  You must set the <code>GOMAXPROCS</code> shell environment variable
  1320  or use the similarly-named <a href="/pkg/runtime/#GOMAXPROCS"><code>function</code></a>
  1321  of the runtime package to allow the
  1322  run-time support to utilize more than one OS thread.
  1323  </p>
  1324  
  1325  <p>
  1326  Programs that perform parallel computation should benefit from an increase in
  1327  <code>GOMAXPROCS</code>.
  1328  However, be aware that
  1329  <a href="//blog.golang.org/2013/01/concurrency-is-not-parallelism.html">concurrency
  1330  is not parallelism</a>.
  1331  </p>
  1332  
  1333  <h3 id="Why_GOMAXPROCS">
  1334  Why does using <code>GOMAXPROCS</code> &gt; 1 sometimes make my program
  1335  slower?</h3>
  1336  
  1337  <p>
  1338  It depends on the nature of your program.
  1339  Problems that are intrinsically sequential cannot be sped up by adding
  1340  more goroutines.
  1341  Concurrency only becomes parallelism when the problem is
  1342  intrinsically parallel.
  1343  </p>
  1344  
  1345  <p>
  1346  In practical terms, programs that spend more time
  1347  communicating on channels than doing computation
  1348  will experience performance degradation when using
  1349  multiple OS threads.
  1350  This is because sending data between threads involves switching
  1351  contexts, which has significant cost.
  1352  For instance, the <a href="/ref/spec#An_example_package">prime sieve example</a>
  1353  from the Go specification has no significant parallelism although it launches many
  1354  goroutines; increasing <code>GOMAXPROCS</code> is more likely to slow it down than
  1355  to speed it up.
  1356  </p>
  1357  
  1358  <p>
  1359  Go's goroutine scheduler is not as good as it needs to be. In the future, it
  1360  should recognize such cases and optimize its use of OS threads. For now,
  1361  <code>GOMAXPROCS</code> should be set on a per-application basis.
  1362  </p>
  1363  
  1364  <p>
  1365  For more detail on this topic see the talk entitled,
  1366  <a href="//blog.golang.org/2013/01/concurrency-is-not-parallelism.html">Concurrency
  1367  is not Parallelism</a>.
  1368  
  1369  <h2 id="Functions_methods">Functions and Methods</h2>
  1370  
  1371  <h3 id="different_method_sets">
  1372  Why do T and *T have different method sets?</h3>
  1373  
  1374  <p>
  1375  From the <a href="/ref/spec#Types">Go Spec</a>:
  1376  </p>
  1377  
  1378  <blockquote>
  1379  The method set of any other named type <code>T</code> consists of all methods
  1380  with receiver type <code>T</code>. The method set of the corresponding pointer
  1381  type <code>*T</code> is the set of all methods with receiver <code>*T</code> or
  1382  <code>T</code> (that is, it also contains the method set of <code>T</code>).
  1383  </blockquote>
  1384  
  1385  <p>
  1386  If an interface value contains a pointer <code>*T</code>,
  1387  a method call can obtain a value by dereferencing the pointer,
  1388  but if an interface value contains a value <code>T</code>,
  1389  there is no useful way for a method call to obtain a pointer.
  1390  </p>
  1391  
  1392  <p>
  1393  Even in cases where the compiler could take the address of a value
  1394  to pass to the method, if the method modifies the value the changes
  1395  will be lost in the caller.
  1396  As a common example, this code:
  1397  </p>
  1398  
  1399  <pre>
  1400  var buf bytes.Buffer
  1401  io.Copy(buf, os.Stdin)
  1402  </pre>
  1403  
  1404  <p>
  1405  would copy standard input into a <i>copy</i> of <code>buf</code>,
  1406  not into <code>buf</code> itself.
  1407  This is almost never the desired behavior.
  1408  </p>
  1409  
  1410  <h3 id="closures_and_goroutines">
  1411  What happens with closures running as goroutines?</h3>
  1412  
  1413  <p>
  1414  Some confusion may arise when using closures with concurrency.
  1415  Consider the following program:
  1416  </p>
  1417  
  1418  <pre>
  1419  func main() {
  1420      done := make(chan bool)
  1421  
  1422      values := []string{"a", "b", "c"}
  1423      for _, v := range values {
  1424          go func() {
  1425              fmt.Println(v)
  1426              done &lt;- true
  1427          }()
  1428      }
  1429  
  1430      // wait for all goroutines to complete before exiting
  1431      for _ = range values {
  1432          &lt;-done
  1433      }
  1434  }
  1435  </pre>
  1436  
  1437  <p>
  1438  One might mistakenly expect to see <code>a, b, c</code> as the output.
  1439  What you'll probably see instead is <code>c, c, c</code>.  This is because
  1440  each iteration of the loop uses the same instance of the variable <code>v</code>, so
  1441  each closure shares that single variable. When the closure runs, it prints the
  1442  value of <code>v</code> at the time <code>fmt.Println</code> is executed,
  1443  but <code>v</code> may have been modified since the goroutine was launched.
  1444  To help detect this and other problems before they happen, run
  1445  <a href="/cmd/go/#hdr-Run_go_tool_vet_on_packages"><code>go vet</code></a>.
  1446  </p>
  1447  
  1448  <p>
  1449  To bind the current value of <code>v</code> to each closure as it is launched, one
  1450  must modify the inner loop to create a new variable each iteration.
  1451  One way is to pass the variable as an argument to the closure:
  1452  </p>
  1453  
  1454  <pre>
  1455      for _, v := range values {
  1456          go func(<b>u</b> string) {
  1457              fmt.Println(<b>u</b>)
  1458              done &lt;- true
  1459          }(<b>v</b>)
  1460      }
  1461  </pre>
  1462  
  1463  <p>
  1464  In this example, the value of <code>v</code> is passed as an argument to the
  1465  anonymous function. That value is then accessible inside the function as
  1466  the variable <code>u</code>.
  1467  </p>
  1468  
  1469  <p>
  1470  Even easier is just to create a new variable, using a declaration style that may
  1471  seem odd but works fine in Go:
  1472  </p>
  1473  
  1474  <pre>
  1475      for _, v := range values {
  1476          <b>v := v</b> // create a new 'v'.
  1477          go func() {
  1478              fmt.Println(<b>v</b>)
  1479              done &lt;- true
  1480          }()
  1481      }
  1482  </pre>
  1483  
  1484  <h2 id="Control_flow">Control flow</h2>
  1485  
  1486  <h3 id="Does_Go_have_a_ternary_form">
  1487  Does Go have the <code>?:</code> operator?</h3>
  1488  
  1489  <p>
  1490  There is no ternary form in Go. You may use the following to achieve the same
  1491  result:
  1492  </p>
  1493  
  1494  <pre>
  1495  if expr {
  1496      n = trueVal
  1497  } else {
  1498      n = falseVal
  1499  }
  1500  </pre>
  1501  
  1502  <h2 id="Packages_Testing">Packages and Testing</h2>
  1503  
  1504  <h3 id="How_do_I_create_a_multifile_package">
  1505  How do I create a multifile package?</h3>
  1506  
  1507  <p>
  1508  Put all the source files for the package in a directory by themselves.
  1509  Source files can refer to items from different files at will; there is
  1510  no need for forward declarations or a header file.
  1511  </p>
  1512  
  1513  <p>
  1514  Other than being split into multiple files, the package will compile and test
  1515  just like a single-file package.
  1516  </p>
  1517  
  1518  <h3 id="How_do_I_write_a_unit_test">
  1519  How do I write a unit test?</h3>
  1520  
  1521  <p>
  1522  Create a new file ending in <code>_test.go</code> in the same directory
  1523  as your package sources. Inside that file, <code>import "testing"</code>
  1524  and write functions of the form
  1525  </p>
  1526  
  1527  <pre>
  1528  func TestFoo(t *testing.T) {
  1529      ...
  1530  }
  1531  </pre>
  1532  
  1533  <p>
  1534  Run <code>go test</code> in that directory.
  1535  That script finds the <code>Test</code> functions,
  1536  builds a test binary, and runs it.
  1537  </p>
  1538  
  1539  <p>See the <a href="/doc/code.html">How to Write Go Code</a> document,
  1540  the <a href="/pkg/testing/"><code>testing</code></a> package
  1541  and the <a href="/cmd/go/#hdr-Test_packages"><code>go test</code></a> subcommand for more details.
  1542  </p>
  1543  
  1544  <h3 id="testing_framework">
  1545  Where is my favorite helper function for testing?</h3>
  1546  
  1547  <p>
  1548  Go's standard <a href="/pkg/testing/"><code>testing</code></a> package makes it easy to write unit tests, but it lacks
  1549  features provided in other language's testing frameworks such as assertion functions.
  1550  An <a href="#assertions">earlier section</a> of this document explained why Go
  1551  doesn't have assertions, and
  1552  the same arguments apply to the use of <code>assert</code> in tests.
  1553  Proper error handling means letting other tests run after one has failed, so
  1554  that the person debugging the failure gets a complete picture of what is
  1555  wrong. It is more useful for a test to report that
  1556  <code>isPrime</code> gives the wrong answer for 2, 3, 5, and 7 (or for
  1557  2, 4, 8, and 16) than to report that <code>isPrime</code> gives the wrong
  1558  answer for 2 and therefore no more tests were run. The programmer who
  1559  triggers the test failure may not be familiar with the code that fails.
  1560  Time invested writing a good error message now pays off later when the
  1561  test breaks.
  1562  </p>
  1563  
  1564  <p>
  1565  A related point is that testing frameworks tend to develop into mini-languages
  1566  of their own, with conditionals and controls and printing mechanisms,
  1567  but Go already has all those capabilities; why recreate them?
  1568  We'd rather write tests in Go; it's one fewer language to learn and the
  1569  approach keeps the tests straightforward and easy to understand.
  1570  </p>
  1571  
  1572  <p>
  1573  If the amount of extra code required to write
  1574  good errors seems repetitive and overwhelming, the test might work better if
  1575  table-driven, iterating over a list of inputs and outputs defined
  1576  in a data structure (Go has excellent support for data structure literals).
  1577  The work to write a good test and good error messages will then be amortized over many
  1578  test cases. The standard Go library is full of illustrative examples, such as in
  1579  <a href="/src/fmt/fmt_test.go">the formatting tests for the <code>fmt</code> package</a>.
  1580  </p>
  1581  
  1582  
  1583  <h2 id="Implementation">Implementation</h2>
  1584  
  1585  <h3 id="What_compiler_technology_is_used_to_build_the_compilers">
  1586  What compiler technology is used to build the compilers?</h3>
  1587  
  1588  <p>
  1589  <code>Gccgo</code> has a front end written in C++, with a recursive descent parser coupled to the
  1590  standard GCC back end. <code>Gc</code> is written in C using
  1591  <code>yacc</code>/<code>bison</code> for the parser.
  1592  Although it's a new program, it fits in the Plan 9 C compiler suite
  1593  (<a href="http://plan9.bell-labs.com/sys/doc/compiler.html">http://plan9.bell-labs.com/sys/doc/compiler.html</a>)
  1594  and uses a variant of the Plan 9 loader to generate ELF/Mach-O/PE binaries.
  1595  </p>
  1596  
  1597  <p>
  1598  We considered using LLVM for <code>gc</code> but we felt it was too large and
  1599  slow to meet our performance goals.
  1600  </p>
  1601  
  1602  <p>
  1603  We also considered writing <code>gc</code>, the original Go compiler, in Go itself but
  1604  elected not to do so because of the difficulties of bootstrapping and
  1605  especially of open source distribution&mdash;you'd need a Go compiler to
  1606  set up a Go environment. <code>Gccgo</code>, which came later, makes it possible to
  1607  consider writing a compiler in Go.
  1608  A plan to do that by machine translation of the existing compiler is under development.
  1609  <a href="http://golang.org/s/go13compiler">A separate document</a>
  1610  explains the reason for this approach.
  1611  </p>
  1612  
  1613  <p>
  1614  That plan aside,
  1615  Go is a
  1616  fine language in which to implement a self-hosting compiler: a native lexer and
  1617  parser are already available in the <a href="/pkg/go/"><code>go</code></a> package
  1618  and a separate type checking
  1619  <a href="http://godoc.org/code.google.com/p/go.tools/go/types">package</a>
  1620  has also been written.
  1621  </p>
  1622  
  1623  <h3 id="How_is_the_run_time_support_implemented">
  1624  How is the run-time support implemented?</h3>
  1625  
  1626  <p>
  1627  Again due to bootstrapping issues, the run-time code was originally written mostly in C (with a
  1628  tiny bit of assembler) although much of it has been translated to Go since then
  1629  and one day all of it might be (except for the assembler bits).
  1630  <code>Gccgo</code>'s run-time support uses <code>glibc</code>.
  1631  <code>Gc</code> uses a custom C library to keep the footprint under
  1632  control; it is
  1633  compiled with a version of the Plan 9 C compiler that supports
  1634  resizable stacks for goroutines.
  1635  The <code>gccgo</code> compiler implements these on Linux only,
  1636  using a technique called segmented stacks,
  1637  supported by recent modifications to the gold linker.
  1638  </p>
  1639  
  1640  <h3 id="Why_is_my_trivial_program_such_a_large_binary">
  1641  Why is my trivial program such a large binary?</h3>
  1642  
  1643  <p>
  1644  The linkers in the gc tool chain (<code>5l</code>, <code>6l</code>, and <code>8l</code>)
  1645  do static linking.  All Go binaries therefore include the Go
  1646  run-time, along with the run-time type information necessary to support dynamic
  1647  type checks, reflection, and even panic-time stack traces.
  1648  </p>
  1649  
  1650  <p>
  1651  A simple C "hello, world" program compiled and linked statically using gcc
  1652  on Linux is around 750 kB,
  1653  including an implementation of <code>printf</code>.
  1654  An equivalent Go program using <code>fmt.Printf</code>
  1655  is around 1.9 MB, but
  1656  that includes more powerful run-time support and type information.
  1657  </p>
  1658  
  1659  <h3 id="unused_variables_and_imports">
  1660  Can I stop these complaints about my unused variable/import?</h3>
  1661  
  1662  <p>
  1663  The presence of an unused variable may indicate a bug, while
  1664  unused imports just slow down compilation,
  1665  an effect that can become substantial as a program accumulates
  1666  code and programmers over time.
  1667  For these reasons, Go refuses to compile programs with unused
  1668  variables or imports,
  1669  trading short-term convenience for long-term build speed and
  1670  program clarity.
  1671  </p>
  1672  
  1673  <p>
  1674  Still, when developing code, it's common to create these situations
  1675  temporarily and it can be annoying to have to edit them out before the
  1676  program will compile.
  1677  </p>
  1678  
  1679  <p>
  1680  Some have asked for a compiler option to turn those checks off
  1681  or at least reduce them to warnings.
  1682  Such an option has not been added, though,
  1683  because compiler options should not affect the semantics of the
  1684  language and because the Go compiler does not report warnings, only
  1685  errors that prevent compilation.
  1686  </p>
  1687  
  1688  <p>
  1689  There are two reasons for having no warnings.  First, if it's worth
  1690  complaining about, it's worth fixing in the code.  (And if it's not
  1691  worth fixing, it's not worth mentioning.) Second, having the compiler
  1692  generate warnings encourages the implementation to warn about weak
  1693  cases that can make compilation noisy, masking real errors that
  1694  <em>should</em> be fixed.
  1695  </p>
  1696  
  1697  <p>
  1698  It's easy to address the situation, though.  Use the blank identifier
  1699  to let unused things persist while you're developing.
  1700  </p>
  1701  
  1702  <pre>
  1703  import "unused"
  1704  
  1705  // This declaration marks the import as used by referencing an
  1706  // item from the package.
  1707  var _ = unused.Item  // TODO: Delete before committing!
  1708  
  1709  func main() {
  1710      debugData := debug.Profile()
  1711      _ = debugData // Used only during debugging.
  1712      ....
  1713  }
  1714  </pre>
  1715  
  1716  <p>
  1717  Nowadays, most Go programmers use a tool,
  1718  <a href="http://godoc.org/code.google.com/p/go.tools/cmd/goimports">goimports</a>,
  1719  which automatically rewrites a Go source file to have the correct imports,
  1720  eliminating the unused imports issue in practice.
  1721  This program is easily connected to most editors to run automatically when a Go source file is written.
  1722  </p>
  1723  
  1724  <h2 id="Performance">Performance</h2>
  1725  
  1726  <h3 id="Why_does_Go_perform_badly_on_benchmark_x">
  1727  Why does Go perform badly on benchmark X?</h3>
  1728  
  1729  <p>
  1730  One of Go's design goals is to approach the performance of C for comparable
  1731  programs, yet on some benchmarks it does quite poorly, including several
  1732  in <a href="/test/bench/shootout/">test/bench/shootout</a>. The slowest depend on libraries
  1733  for which versions of comparable performance are not available in Go.
  1734  For instance, <a href="/test/bench/shootout/pidigits.go">pidigits.go</a>
  1735  depends on a multi-precision math package, and the C
  1736  versions, unlike Go's, use <a href="http://gmplib.org/">GMP</a> (which is
  1737  written in optimized assembler).
  1738  Benchmarks that depend on regular expressions
  1739  (<a href="/test/bench/shootout/regex-dna.go">regex-dna.go</a>, for instance) are
  1740  essentially comparing Go's native <a href="/pkg/regexp">regexp package</a> to
  1741  mature, highly optimized regular expression libraries like PCRE.
  1742  </p>
  1743  
  1744  <p>
  1745  Benchmark games are won by extensive tuning and the Go versions of most
  1746  of the benchmarks need attention.  If you measure comparable C
  1747  and Go programs
  1748  (<a href="/test/bench/shootout/reverse-complement.go">reverse-complement.go</a> is one example), you'll see the two
  1749  languages are much closer in raw performance than this suite would
  1750  indicate.
  1751  </p>
  1752  
  1753  <p>
  1754  Still, there is room for improvement. The compilers are good but could be
  1755  better, many libraries need major performance work, and the garbage collector
  1756  isn't fast enough yet. (Even if it were, taking care not to generate unnecessary
  1757  garbage can have a huge effect.)
  1758  </p>
  1759  
  1760  <p>
  1761  In any case, Go can often be very competitive.
  1762  There has been significant improvement in the performance of many programs
  1763  as the language and tools have developed.
  1764  See the blog post about
  1765  <a href="//blog.golang.org/2011/06/profiling-go-programs.html">profiling
  1766  Go programs</a> for an informative example.
  1767  
  1768  <h2 id="change_from_c">Changes from C</h2>
  1769  
  1770  <h3 id="different_syntax">
  1771  Why is the syntax so different from C?</h3>
  1772  <p>
  1773  Other than declaration syntax, the differences are not major and stem
  1774  from two desires.  First, the syntax should feel light, without too
  1775  many mandatory keywords, repetition, or arcana.  Second, the language
  1776  has been designed to be easy to analyze
  1777  and can be parsed without a symbol table.  This makes it much easier
  1778  to build tools such as debuggers, dependency analyzers, automated
  1779  documentation extractors, IDE plug-ins, and so on.  C and its
  1780  descendants are notoriously difficult in this regard.
  1781  </p>
  1782  
  1783  <h3 id="declarations_backwards">
  1784  Why are declarations backwards?</h3>
  1785  <p>
  1786  They're only backwards if you're used to C. In C, the notion is that a
  1787  variable is declared like an expression denoting its type, which is a
  1788  nice idea, but the type and expression grammars don't mix very well and
  1789  the results can be confusing; consider function pointers.  Go mostly
  1790  separates expression and type syntax and that simplifies things (using
  1791  prefix <code>*</code> for pointers is an exception that proves the rule).  In C,
  1792  the declaration
  1793  </p>
  1794  <pre>
  1795      int* a, b;
  1796  </pre>
  1797  <p>
  1798  declares <code>a</code> to be a pointer but not <code>b</code>; in Go
  1799  </p>
  1800  <pre>
  1801      var a, b *int
  1802  </pre>
  1803  <p>
  1804  declares both to be pointers.  This is clearer and more regular.
  1805  Also, the <code>:=</code> short declaration form argues that a full variable
  1806  declaration should present the same order as <code>:=</code> so
  1807  </p>
  1808  <pre>
  1809      var a uint64 = 1
  1810  </pre>
  1811  <p>
  1812  has the same effect as
  1813  </p>
  1814  <pre>
  1815      a := uint64(1)
  1816  </pre>
  1817  <p>
  1818  Parsing is also simplified by having a distinct grammar for types that
  1819  is not just the expression grammar; keywords such as <code>func</code>
  1820  and <code>chan</code> keep things clear.
  1821  </p>
  1822  
  1823  <p>
  1824  See the article about
  1825  <a href="/doc/articles/gos_declaration_syntax.html">Go's Declaration Syntax</a>
  1826  for more details.
  1827  </p>
  1828  
  1829  <h3 id="no_pointer_arithmetic">
  1830  Why is there no pointer arithmetic?</h3>
  1831  <p>
  1832  Safety.  Without pointer arithmetic it's possible to create a
  1833  language that can never derive an illegal address that succeeds
  1834  incorrectly.  Compiler and hardware technology have advanced to the
  1835  point where a loop using array indices can be as efficient as a loop
  1836  using pointer arithmetic.  Also, the lack of pointer arithmetic can
  1837  simplify the implementation of the garbage collector.
  1838  </p>
  1839  
  1840  <h3 id="inc_dec">
  1841  Why are <code>++</code> and <code>--</code> statements and not expressions?  And why postfix, not prefix?</h3>
  1842  <p>
  1843  Without pointer arithmetic, the convenience value of pre- and postfix
  1844  increment operators drops.  By removing them from the expression
  1845  hierarchy altogether, expression syntax is simplified and the messy
  1846  issues around order of evaluation of <code>++</code> and <code>--</code>
  1847  (consider <code>f(i++)</code> and <code>p[i] = q[++i]</code>)
  1848  are eliminated as well.  The simplification is
  1849  significant.  As for postfix vs. prefix, either would work fine but
  1850  the postfix version is more traditional; insistence on prefix arose
  1851  with the STL, a library for a language whose name contains, ironically, a
  1852  postfix increment.
  1853  </p>
  1854  
  1855  <h3 id="semicolons">
  1856  Why are there braces but no semicolons? And why can't I put the opening
  1857  brace on the next line?</h3>
  1858  <p>
  1859  Go uses brace brackets for statement grouping, a syntax familiar to
  1860  programmers who have worked with any language in the C family.
  1861  Semicolons, however, are for parsers, not for people, and we wanted to
  1862  eliminate them as much as possible.  To achieve this goal, Go borrows
  1863  a trick from BCPL: the semicolons that separate statements are in the
  1864  formal grammar but are injected automatically, without lookahead, by
  1865  the lexer at the end of any line that could be the end of a statement.
  1866  This works very well in practice but has the effect that it forces a
  1867  brace style.  For instance, the opening brace of a function cannot
  1868  appear on a line by itself.
  1869  </p>
  1870  
  1871  <p>
  1872  Some have argued that the lexer should do lookahead to permit the
  1873  brace to live on the next line.  We disagree.  Since Go code is meant
  1874  to be formatted automatically by
  1875  <a href="/cmd/gofmt/"><code>gofmt</code></a>,
  1876  <i>some</i> style must be chosen.  That style may differ from what
  1877  you've used in C or Java, but Go is a new language and
  1878  <code>gofmt</code>'s style is as good as any other.  More
  1879  important&mdash;much more important&mdash;the advantages of a single,
  1880  programmatically mandated format for all Go programs greatly outweigh
  1881  any perceived disadvantages of the particular style.
  1882  Note too that Go's style means that an interactive implementation of
  1883  Go can use the standard syntax one line at a time without special rules.
  1884  </p>
  1885  
  1886  <h3 id="garbage_collection">
  1887  Why do garbage collection?  Won't it be too expensive?</h3>
  1888  <p>
  1889  One of the biggest sources of bookkeeping in systems programs is
  1890  memory management.  We feel it's critical to eliminate that
  1891  programmer overhead, and advances in garbage collection
  1892  technology in the last few years give us confidence that we can
  1893  implement it with low enough overhead and no significant
  1894  latency.
  1895  </p>
  1896  
  1897  <p>
  1898  Another point is that a large part of the difficulty of concurrent
  1899  and multi-threaded programming is memory management;
  1900  as objects get passed among threads it becomes cumbersome
  1901  to guarantee they become freed safely.
  1902  Automatic garbage collection makes concurrent code far easier to write.
  1903  Of course, implementing garbage collection in a concurrent environment is
  1904  itself a challenge, but meeting it once rather than in every
  1905  program helps everyone.
  1906  </p>
  1907  
  1908  <p>
  1909  Finally, concurrency aside, garbage collection makes interfaces
  1910  simpler because they don't need to specify how memory is managed across them.
  1911  </p>
  1912  
  1913  <p>
  1914  The current implementation is a parallel mark-and-sweep
  1915  collector but a future version might take a different approach.
  1916  </p>
  1917  
  1918  <p>
  1919  On the topic of performance, keep in mind that Go gives the programmer
  1920  considerable control over memory layout and allocation, much more than
  1921  is typical in garbage-collected languages. A careful programmer can reduce
  1922  the garbage collection overhead dramatically by using the language well;
  1923  see the article about
  1924  <a href="//blog.golang.org/2011/06/profiling-go-programs.html">profiling
  1925  Go programs</a> for a worked example, including a demonstration of Go's
  1926  profiling tools.
  1927  </p>