123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667668669670671672673674675676677678679680681682683684685686687688689690691692693694695696697698699700701702703704705706707708709710711712713714715716717718719720721722723724725726727728729730731732733734735736737738739740741742743744745746747748749750751752753754755756757758759760761762763764765766767768769770771772773774775776777778779780781782783784785786787788789790791792793794795796797798799800801802803804805806807808809810811812813814815816817818819820821822823824825826827828829830831832833834835836837838839840841842843844845846847848849850851852853854855856857858859860861862863864865866867868869870871872873874875876877878879880881882883884885886887888889890891892893894895896897898899900901902903904905906907908909910911912913914915916917918919920921922923924925926927928929930931932933934935936937938939940941942943944945946947948949950951952953954955956957958959960961962963964965966967968969970971972973974975976977978979980981982983984985986987988989990991992993994995996997998999100010011002100310041005100610071008100910101011101210131014101510161017101810191020102110221023102410251026102710281029103010311032103310341035103610371038103910401041104210431044104510461047104810491050105110521053105410551056105710581059106010611062106310641065106610671068106910701071107210731074107510761077107810791080108110821083108410851086108710881089109010911092109310941095109610971098109911001101110211031104110511061107110811091110111111121113111411151116111711181119112011211122112311241125112611271128112911301131113211331134113511361137113811391140114111421143114411451146114711481149115011511152115311541155115611571158115911601161116211631164116511661167116811691170117111721173117411751176117711781179118011811182118311841185118611871188118911901191119211931194119511961197119811991200120112021203120412051206120712081209121012111212121312141215121612171218121912201221122212231224122512261227122812291230123112321233123412351236123712381239124012411242124312441245124612471248124912501251125212531254125512561257125812591260126112621263126412651266126712681269127012711272127312741275127612771278127912801281128212831284128512861287128812891290129112921293129412951296129712981299130013011302130313041305130613071308130913101311131213131314131513161317131813191320132113221323132413251326132713281329133013311332133313341335133613371338133913401341134213431344134513461347134813491350135113521353135413551356135713581359136013611362136313641365136613671368136913701371137213731374137513761377137813791380138113821383138413851386138713881389139013911392139313941395139613971398139914001401140214031404140514061407140814091410141114121413141414151416141714181419142014211422142314241425142614271428142914301431143214331434143514361437143814391440144114421443144414451446144714481449145014511452145314541455145614571458145914601461146214631464146514661467146814691470147114721473147414751476147714781479148014811482148314841485148614871488148914901491149214931494149514961497149814991500150115021503150415051506150715081509151015111512151315141515151615171518151915201521152215231524152515261527152815291530153115321533153415351536153715381539154015411542154315441545154615471548154915501551155215531554155515561557155815591560156115621563156415651566156715681569157015711572157315741575157615771578157915801581158215831584158515861587158815891590159115921593159415951596159715981599160016011602160316041605160616071608160916101611161216131614161516161617161816191620162116221623162416251626162716281629163016311632163316341635163616371638163916401641164216431644164516461647164816491650165116521653165416551656165716581659166016611662166316641665166616671668166916701671167216731674167516761677167816791680168116821683168416851686168716881689169016911692169316941695169616971698169917001701170217031704170517061707170817091710171117121713171417151716171717181719172017211722172317241725172617271728172917301731173217331734173517361737173817391740174117421743174417451746174717481749175017511752175317541755175617571758175917601761176217631764176517661767176817691770177117721773177417751776177717781779178017811782178317841785178617871788178917901791179217931794179517961797179817991800180118021803180418051806180718081809181018111812181318141815181618171818181918201821182218231824182518261827182818291830183118321833183418351836183718381839184018411842184318441845184618471848184918501851185218531854185518561857185818591860186118621863186418651866186718681869187018711872187318741875187618771878187918801881188218831884188518861887188818891890189118921893189418951896189718981899190019011902190319041905190619071908190919101911191219131914191519161917191819191920192119221923192419251926192719281929193019311932193319341935193619371938193919401941194219431944194519461947194819491950195119521953195419551956195719581959196019611962196319641965196619671968196919701971197219731974197519761977197819791980198119821983198419851986198719881989199019911992199319941995199619971998199920002001200220032004200520062007200820092010201120122013201420152016201720182019202020212022202320242025202620272028202920302031203220332034203520362037203820392040204120422043204420452046204720482049205020512052205320542055205620572058205920602061206220632064206520662067206820692070207120722073207420752076207720782079208020812082208320842085208620872088208920902091209220932094209520962097209820992100210121022103210421052106210721082109211021112112211321142115211621172118211921202121212221232124212521262127212821292130213121322133213421352136213721382139214021412142214321442145214621472148214921502151215221532154215521562157215821592160216121622163216421652166216721682169217021712172217321742175217621772178217921802181218221832184218521862187218821892190219121922193219421952196219721982199220022012202220322042205220622072208220922102211221222132214221522162217221822192220222122222223222422252226222722282229223022312232223322342235223622372238223922402241224222432244224522462247224822492250225122522253225422552256225722582259226022612262226322642265226622672268226922702271227222732274227522762277227822792280228122822283228422852286228722882289229022912292229322942295229622972298229923002301230223032304230523062307230823092310231123122313231423152316231723182319232023212322232323242325232623272328232923302331233223332334233523362337233823392340234123422343234423452346234723482349235023512352235323542355235623572358235923602361236223632364236523662367236823692370237123722373237423752376237723782379238023812382238323842385238623872388238923902391239223932394239523962397239823992400240124022403240424052406240724082409241024112412241324142415241624172418241924202421242224232424242524262427242824292430243124322433243424352436243724382439244024412442244324442445244624472448244924502451245224532454245524562457245824592460246124622463246424652466246724682469247024712472247324742475 |
- <!--{
- "Title": "Frequently Asked Questions (FAQ)",
- "Path": "/doc/faq"
- }-->
- <h2 id="Origins">Origins</h2>
- <h3 id="What_is_the_purpose_of_the_project">
- What is the purpose of the project?</h3>
- <p>
- At the time of Go's inception, only a decade ago, the programming world was different from today.
- Production software was usually written in C++ or Java,
- GitHub did not exist, most computers were not yet multiprocessors,
- and other than Visual Studio and Eclipse there were few IDEs or other high-level tools available
- at all, let alone for free on the Internet.
- </p>
- <p>
- Meanwhile, we had become frustrated by the undue complexity required to use
- the languages we worked with to develop server software.
- Computers had become enormously quicker since languages such as
- C, C++ and Java were first developed but the act of programming had not
- itself advanced nearly as much.
- Also, it was clear that multiprocessors were becoming universal but
- most languages offered little help to program them efficiently
- and safely.
- </p>
- <p>
- We decided to take a step back and think about what major issues were
- going to dominate software engineering in the years ahead as technology
- developed, and how a new language might help address them.
- For instance, the rise of multicore CPUs argued that a language should
- provide first-class support for some sort of concurrency or parallelism.
- And to make resource management tractable in a large concurrent program,
- garbage collection, or at least some sort of safe automatic memory management was required.
- </p>
- <p>
- These considerations led to
- <a href="https://commandcenter.blogspot.com/2017/09/go-ten-years-and-climbing.html">a
- series of discussions</a> from which Go arose, first as a set of ideas and
- desiderata, then as a language.
- An overarching goal was that Go do more to help the working programmer
- by enabling tooling, automating mundane tasks such as code formatting,
- and removing obstacles to working on large code bases.
- </p>
- <p>
- A much more expansive description of the goals of Go and how
- they are met, or at least approached, is available in the article,
- <a href="//talks.golang.org/2012/splash.article">Go at Google:
- Language Design in the Service of Software Engineering</a>.
- </p>
- <h3 id="history">
- What is the history of the project?</h3>
- <p>
- Robert Griesemer, Rob Pike and Ken Thompson started sketching the
- goals for a new language on the white board on September 21, 2007.
- Within a few days the goals had settled into a plan to do something
- and a fair idea of what it would be. Design continued part-time in
- parallel with unrelated work. By January 2008, Ken had started work
- on a compiler with which to explore ideas; it generated C code as its
- output. By mid-year the language had become a full-time project and
- had settled enough to attempt a production compiler. In May 2008,
- Ian Taylor independently started on a GCC front end for Go using the
- draft specification. Russ Cox joined in late 2008 and helped move the language
- and libraries from prototype to reality.
- </p>
- <p>
- Go became a public open source project on November 10, 2009.
- Countless people from the community have contributed ideas, discussions, and code.
- </p>
- <p>
- There are now millions of Go programmers—gophers—around the world,
- and there are more every day.
- Go's success has far exceeded our expectations.
- </p>
- <h3 id="gopher">
- What's the origin of the gopher mascot?</h3>
- <p>
- The mascot and logo were designed by
- <a href="https://reneefrench.blogspot.com">Renée French</a>, who also designed
- <a href="https://9p.io/plan9/glenda.html">Glenda</a>,
- the Plan 9 bunny.
- A <a href="https://blog.golang.org/gopher">blog post</a>
- about the gopher explains how it was
- derived from one she used for a <a href="https://wfmu.org/">WFMU</a>
- T-shirt design some years ago.
- The logo and mascot are covered by the
- <a href="https://creativecommons.org/licenses/by/3.0/">Creative Commons Attribution 3.0</a>
- license.
- </p>
- <p>
- The gopher has a
- <a href="/doc/gopher/modelsheet.jpg">model sheet</a>
- illustrating his characteristics and how to represent them correctly.
- The model sheet was first shown in a
- <a href="https://www.youtube.com/watch?v=4rw_B4yY69k">talk</a>
- by Renée at Gophercon in 2016.
- He has unique features; he's the <em>Go gopher</em>, not just any old gopher.
- </p>
- <h3 id="go_or_golang">
- Is the language called Go or Golang?</h3>
- <p>
- The language is called Go.
- The "golang" moniker arose because the web site is
- <a href="https://golang.org">golang.org</a>, not
- go.org, which was not available to us.
- Many use the golang name, though, and it is handy as
- a label.
- For instance, the Twitter tag for the language is "#golang".
- The language's name is just plain Go, regardless.
- </p>
- <p>
- A side note: Although the
- <a href="https://blog.golang.org/go-brand">official logo</a>
- has two capital letters, the language name is written Go, not GO.
- </p>
- <h3 id="creating_a_new_language">
- Why did you create a new language?</h3>
- <p>
- Go was born out of frustration with existing languages and
- environments for the work we were doing at Google.
- Programming had become too
- difficult and the choice of languages was partly to blame. One had to
- choose either efficient compilation, efficient execution, or ease of
- programming; all three were not available in the same mainstream
- language. Programmers who could were choosing ease over
- safety and efficiency by moving to dynamically typed languages such as
- Python and JavaScript rather than C++ or, to a lesser extent, Java.
- </p>
- <p>
- We were not alone in our concerns.
- After many years with a pretty quiet landscape for programming languages,
- Go was among the first of several new languages—Rust,
- Elixir, Swift, and more—that have made programming language development
- an active, almost mainstream field again.
- </p>
- <p>
- Go addressed these issues by attempting to combine the ease of programming of an interpreted,
- dynamically typed
- language with the efficiency and safety of a statically typed, compiled language.
- It also aimed to be modern, with support for networked and multicore
- computing. Finally, working with Go is intended to be <i>fast</i>: it should take
- at most a few seconds to build a large executable on a single computer.
- To meet these goals required addressing a number of
- linguistic issues: an expressive but lightweight type system;
- concurrency and garbage collection; rigid dependency specification;
- and so on. These cannot be addressed well by libraries or tools; a new
- language was called for.
- </p>
- <p>
- The article <a href="//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>
- Go is mostly in the C family (basic syntax),
- with significant input from the Pascal/Modula/Oberon
- family (declarations, packages),
- plus some ideas from languages
- inspired by Tony Hoare's CSP,
- such as Newsqueak and Limbo (concurrency).
- However, it is a new language across the board.
- In every respect the language was designed by thinking
- about what programmers do and how to make programming, at least the
- kind of programming we do, more effective, which means more fun.
- </p>
- <h3 id="principles">
- What are the guiding principles in the design?</h3>
- <p>
- When Go was designed, Java and C++ were the most commonly
- used languages for writing servers, at least at Google.
- We felt that these languages required
- too much bookkeeping and repetition.
- Some programmers reacted by moving towards more dynamic,
- fluid languages like Python, at the cost of efficiency and
- type safety.
- We felt it should be possible to have the efficiency,
- the safety, and the fluidity in a single language.
- </p>
- <p>
- Go attempts to reduce the amount of typing in both senses of the word.
- Throughout its design, we have tried to reduce clutter and
- complexity. There are no forward declarations and no header files;
- everything is declared exactly once. Initialization is expressive,
- automatic, and easy to use. Syntax is clean and light on keywords.
- Stuttering (<code>foo.Foo* myFoo = new(foo.Foo)</code>) is reduced by
- simple type derivation using the <code>:=</code>
- declare-and-initialize construct. And perhaps most radically, there
- is no type hierarchy: types just <i>are</i>, they don't have to
- announce their relationships. These simplifications allow Go to be
- expressive yet comprehensible without sacrificing, well, sophistication.
- </p>
- <p>
- Another important principle is to keep the concepts orthogonal.
- Methods can be implemented for any type; structures represent data while
- interfaces represent abstraction; and so on. Orthogonality makes it
- easier to understand what happens when things combine.
- </p>
- <h2 id="Usage">Usage</h2>
- <h3 id="internal_usage">
- Is Google using Go internally?</h3>
- <p>
- Yes. Go is used widely in production inside Google.
- One easy example is the server behind
- <a href="//golang.org">golang.org</a>.
- It's just the <a href="/cmd/godoc"><code>godoc</code></a>
- document server running in a production configuration on
- <a href="https://developers.google.com/appengine/">Google App Engine</a>.
- </p>
- <p>
- A more significant instance is 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>
- <p>
- Go is not the only language used at Google, far from it, but it is a key language
- for a number of areas including
- <a href="https://talks.golang.org/2013/go-sreops.slide">site reliability
- engineering (SRE)</a>
- and large-scale data processing.
- </p>
- <h3 id="external_usage">
- What other companies use Go?</h3>
- <p>
- Go usage is growing worldwide, especially but by no means exclusively
- in the cloud computing space.
- A couple of major cloud infrastructure projects written in Go are
- Docker and Kubernetes,
- but there are many more.
- </p>
- <p>
- It's not just cloud, though.
- The Go Wiki includes a
- <a href="https://github.com/golang/go/wiki/GoUsers">page</a>,
- updated regularly, that lists some of the many companies using Go.
- </p>
- <p>
- The Wiki also has a page with links to
- <a href="https://github.com/golang/go/wiki/SuccessStories">success stories</a>
- about companies and projects that are using the language.
- </p>
- <h3 id="Do_Go_programs_link_with_Cpp_programs">
- Do Go programs link with C/C++ programs?</h3>
- <p>
- It is possible to use C and Go together in the same address space,
- but it is not a natural fit and can require special interface software.
- Also, linking C with Go code gives up the memory
- safety and stack management properties that Go provides.
- Sometimes it's absolutely necessary to use C libraries to solve a problem,
- but doing so always introduces an element of risk not present with
- pure Go code, so do so with care.
- </p>
- <p>
- If you do need to use C with Go, how to proceed depends on the Go
- compiler implementation.
- There are three Go compiler implementations supported by the
- Go team.
- These are <code>gc</code>, the default compiler,
- <code>gccgo</code>, which uses the GCC back end,
- and a somewhat less mature <code>gollvm</code>, which uses the LLVM infrastructure.
- </p>
- <p>
- <code>Gc</code> uses a different calling convention and linker from C and
- therefore cannot be called directly from C programs, or vice versa.
- The <a href="/cmd/cgo/"><code>cgo</code></a> program provides the mechanism for a
- “foreign function interface” to allow safe calling of
- C libraries from Go code.
- SWIG extends this capability to C++ libraries.
- </p>
- <p>
- You can also use <code>cgo</code> and SWIG with <code>Gccgo</code> and <code>gollvm</code>.
- Since they use a traditional API, it's also possible, with great care,
- to link code from these compilers directly with GCC/LLVM-compiled C or C++ programs.
- However, doing so safely requires an understanding of the calling conventions for
- all languages concerned, as well as concern for stack limits when calling C or C++
- from Go.
- </p>
- <h3 id="ide">
- What IDEs does Go support?</h3>
- <p>
- The Go project does not include a custom IDE, but the language and
- libraries have been designed to make it easy to analyze source code.
- As a consequence, most well-known editors and IDEs support Go well,
- either directly or through a plugin.
- </p>
- <p>
- The list of well-known IDEs and editors that have good Go support
- available includes Emacs, Vim, VSCode, Atom, Eclipse, Sublime, IntelliJ
- (through a custom variant called Goland), and many more.
- Chances are your favorite environment is a productive one for
- programming in Go.
- </p>
- <h3 id="protocol_buffers">
- Does Go support Google's protocol buffers?</h3>
- <p>
- A separate open source project provides the necessary compiler plugin and library.
- It is available at
- <a href="//github.com/golang/protobuf">github.com/golang/protobuf/</a>.
- </p>
- <h3 id="Can_I_translate_the_Go_home_page">
- Can I translate the Go home page into another language?</h3>
- <p>
- Absolutely. We encourage developers to make Go Language sites in their own languages.
- However, if you choose to add the Google logo or branding to your site
- (it does not appear on <a href="//golang.org/">golang.org</a>),
- you will need to abide by the guidelines at
- <a href="//www.google.com/permissions/guidelines.html">www.google.com/permissions/guidelines.html</a>
- </p>
- <h2 id="Design">Design</h2>
- <h3 id="runtime">
- Does Go have a runtime?</h3>
- <p>
- Go does have an extensive library, called the <em>runtime</em>,
- that is part of every Go program.
- The runtime library implements garbage collection, concurrency,
- stack management, and other critical features of the Go language.
- Although it is more central to the language, Go's runtime is analogous
- to <code>libc</code>, the C library.
- </p>
- <p>
- It is important to understand, however, that Go's runtime does not
- include a virtual machine, such as is provided by the Java runtime.
- Go programs are compiled ahead of time to native machine code
- (or JavaScript or WebAssembly, for some variant implementations).
- Thus, although the term is often used to describe the virtual
- environment in which a program runs, in Go the word “runtime”
- is just the name given to the library providing critical language services.
- </p>
- <h3 id="unicode_identifiers">
- What's up with Unicode identifiers?</h3>
- <p>
- When designing Go, we wanted to make sure that it was not
- overly ASCII-centric,
- which meant extending the space of identifiers from the
- confines of 7-bit ASCII.
- Go's rule—identifier characters must be
- letters or digits as defined by Unicode—is simple to understand
- and to implement but has restrictions.
- Combining characters are
- excluded by design, for instance,
- and that excludes some languages such as Devanagari.
- </p>
- <p>
- This rule has one other unfortunate consequence.
- Since an exported identifier must begin with an
- upper-case letter, identifiers created from characters
- in some languages can, by definition, not be exported.
- For now the
- only solution is to use something like <code>X日本語</code>, which
- is clearly unsatisfactory.
- </p>
- <p>
- Since the earliest version of the language, there has been considerable
- thought into how best to expand the identifier space to accommodate
- programmers using other native languages.
- Exactly what to do remains an active topic of discussion, and a future
- version of the language may be more liberal in its definition
- of an identifier.
- For instance, it might adopt some of the ideas from the Unicode
- organization's <a href="http://unicode.org/reports/tr31/">recommendations</a>
- for identifiers.
- Whatever happens, it must be done compatibly while preserving
- (or perhaps expanding) the way letter case determines visibility of
- identifiers, which remains one of our favorite features of Go.
- </p>
- <p>
- For the time being, we have a simple rule that can be expanded later
- without breaking programs, one that avoids bugs that would surely arise
- from a rule that admits ambiguous identifiers.
- </p>
- <h3 id="Why_doesnt_Go_have_feature_X">Why does Go not have feature X?</h3>
- <p>
- Every language contains novel features and omits someone's favorite
- feature. Go was designed with an eye on felicity of programming, speed of
- compilation, orthogonality of concepts, and the need to support features
- such as concurrency and garbage collection. Your favorite feature may be
- missing because it doesn't fit, because it affects compilation speed or
- clarity of design, or because it would make the fundamental system model
- too difficult.
- </p>
- <p>
- If it bothers you that Go is missing feature <var>X</var>,
- please forgive us and investigate the features that Go does have. You might find that
- they compensate in interesting ways for the lack of <var>X</var>.
- </p>
- <h3 id="generics">
- Why does Go not have generic types?</h3>
- <p>
- Generics may well be added at some point. We don't feel an urgency for
- them, although we understand some programmers do.
- </p>
- <p>
- Go was intended as a language for writing server programs that would be
- easy to maintain over time.
- (See <a href="https://talks.golang.org/2012/splash.article">this
- article</a> for more background.)
- The design concentrated on things like scalability, readability, and
- concurrency.
- Polymorphic programming did not seem essential to the language's
- goals at the time, and so was left out for simplicity.
- </p>
- <p>
- The language is more mature now, and there is scope to consider
- some form of generic programming.
- However, there remain some caveats.
- </p>
- <p>
- Generics are convenient but they come at a cost in
- complexity in the type system and run-time. We haven't yet found a
- design that gives value proportionate to the complexity, although we
- continue to think about it. Meanwhile, Go's built-in maps and slices,
- plus the ability to use the empty interface to construct containers
- (with explicit unboxing) mean in many cases it is possible to write
- code that does what generics would enable, if less smoothly.
- </p>
- <p>
- The topic remains open.
- For a look at several previous unsuccessful attempts to
- design a good generics solution for Go, see
- <a href="https://golang.org/issue/15292">this proposal</a>.
- </p>
- <h3 id="exceptions">
- Why does Go not have exceptions?</h3>
- <p>
- We believe that coupling exceptions to a control
- structure, as in the <code>try-catch-finally</code> idiom, results in
- convoluted code. It also tends to encourage programmers to label
- too many ordinary errors, such as failing to open a file, as
- exceptional.
- </p>
- <p>
- Go takes a different approach. For plain error handling, Go's multi-value
- returns make it easy to report an error without overloading the return value.
- <a href="/doc/articles/error_handling.html">A canonical error type, coupled
- with Go's other features</a>, makes error handling pleasant but quite different
- from that in other languages.
- </p>
- <p>
- Go also has a couple
- of built-in functions to signal and recover from truly exceptional
- conditions. The recovery mechanism is executed only as part of a
- function's state being torn down after an error, which is sufficient
- to handle catastrophe but requires no extra control structures and,
- when used well, can result in clean error-handling code.
- </p>
- <p>
- See the <a href="/doc/articles/defer_panic_recover.html">Defer, Panic, and Recover</a> article for details.
- Also, the <a href="https://blog.golang.org/errors-are-values">Errors are values</a> blog post
- describes one approach to handling errors cleanly in Go by demonstrating that,
- since errors are just values, the full power of Go can deployed in error handling.
- </p>
- <h3 id="assertions">
- Why does Go not have assertions?</h3>
- <p>
- Go doesn't provide assertions. They are undeniably convenient, but our
- experience has been that programmers use them as a crutch to avoid thinking
- about proper error handling and reporting. Proper error handling means that
- servers continue to operate instead of crashing after a non-fatal error.
- Proper error reporting means that errors are direct and to the point,
- saving the programmer from interpreting a large crash trace. Precise
- errors are particularly important when the programmer seeing the errors is
- not familiar with the code.
- </p>
- <p>
- We understand that this is a point of contention. There are many things in
- the Go language and libraries that differ from modern practices, simply
- because we feel it's sometimes worth trying a different approach.
- </p>
- <h3 id="csp">
- Why build concurrency on the ideas of CSP?</h3>
- <p>
- Concurrency and multi-threaded programming have over time
- developed a reputation for difficulty. We believe this is due partly to complex
- designs such as
- <a href="https://en.wikipedia.org/wiki/POSIX_Threads">pthreads</a>
- and partly to overemphasis on low-level details
- such as mutexes, condition variables, and memory barriers.
- Higher-level interfaces enable much simpler code, even if there are still
- mutexes and such under the covers.
- </p>
- <p>
- One of the most successful models for providing high-level linguistic support
- 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">
- Why goroutines instead of threads?</h3>
- <p>
- Goroutines are part of making concurrency easy to use. The idea, which has
- been around for a while, is to multiplex independently executing
- functions—coroutines—onto a set of threads.
- When a coroutine blocks, such as by calling a blocking system call,
- the run-time automatically moves other coroutines on the same operating
- system thread to a different, runnable thread so they won't be blocked.
- The programmer sees none of this, which is the point.
- The result, which we call goroutines, can be very cheap: they have little
- overhead beyond the memory for the stack, which is just a few kilobytes.
- </p>
- <p>
- To make the stacks small, Go's run-time uses resizable, bounded stacks. A newly
- minted goroutine is given a few kilobytes, which is almost always enough.
- When it isn't, the run-time grows (and shrinks) the memory for storing
- the stack automatically, allowing many goroutines to live in a modest
- amount of memory.
- The CPU overhead averages about three cheap instructions per function call.
- It is practical to create hundreds of thousands of goroutines in the same
- address space.
- If goroutines were just threads, system resources would
- run out at a much smaller number.
- </p>
- <h3 id="atomic_maps">
- Why are map operations not defined to be atomic?</h3>
- <p>
- After long discussion it was decided that the typical use of maps did not require
- safe access from multiple goroutines, and in those cases where it did, the map was
- probably part of some larger data structure or computation that was already
- synchronized. Therefore requiring that all map operations grab a mutex would slow
- down most programs and add safety to few. This was not an easy decision,
- however, since it means uncontrolled map access can crash the program.
- </p>
- <p>
- The language does not preclude atomic map updates. When required, such
- as when hosting an untrusted program, the implementation could interlock
- map access.
- </p>
- <p>
- Map access is unsafe only when updates are occurring.
- As long as all goroutines are only reading—looking up elements in the map,
- including iterating through it using a
- <code>for</code> <code>range</code> loop—and not changing the map
- by assigning to elements or doing deletions,
- it is safe for them to access the map concurrently without synchronization.
- </p>
- <p>
- As an aid to correct map use, some implementations of the language
- contain a special check that automatically reports at run time when a map is modified
- unsafely by concurrent execution.
- </p>
- <h3 id="language_changes">
- Will you accept my language change?</h3>
- <p>
- People often suggest improvements to the language—the
- <a href="//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, at least at the source code level
- (programs may need to be recompiled occasionally to stay current).
- 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 discussions
- on that topic have only just begun and one thing is certain:
- there will be very few such incompatibilities introduced in the process.
- Moreover, the compatibility promise encourages us to provide an automatic path
- forward for old programs to adapt should that situation arise.
- </p>
- <p>
- Even if your proposal is compatible with the Go 1 spec, it might
- not be in the spirit of Go's design goals.
- The article <i><a href="//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">
- Is Go an object-oriented language?</h3>
- <p>
- Yes and no. Although Go has types and methods and allows an
- object-oriented style of programming, there is no type hierarchy.
- The concept of “interface” in Go provides a different approach that
- we believe is easy to use and in some ways more general. There are
- also ways to embed types in other types to provide something
- analogous—but not identical—to subclassing.
- Moreover, methods in Go are more general than in C++ or Java:
- they can be defined for any sort of data, even built-in types such
- as plain, “unboxed” integers.
- They are not restricted to structs (classes).
- </p>
- <p>
- Also, the lack of a type hierarchy makes “objects” in Go feel much more
- lightweight than in languages such as C++ or Java.
- </p>
- <h3 id="How_do_I_get_dynamic_dispatch_of_methods">
- How do I get dynamic dispatch of methods?</h3>
- <p>
- The only way to have dynamically dispatched methods is through an
- interface. Methods on a struct or any other concrete type are always resolved statically.
- </p>
- <h3 id="inheritance">
- Why is there no type inheritance?</h3>
- <p>
- Object-oriented programming, at least in the best-known languages,
- involves too much discussion of the relationships between types,
- relationships that often could be derived automatically. Go takes a
- different approach.
- </p>
- <p>
- Rather than requiring the programmer to declare ahead of time that two
- types are related, in Go a type automatically satisfies any interface
- that specifies a subset of its methods. Besides reducing the
- bookkeeping, this approach has real advantages. Types can satisfy
- many interfaces at once, without the complexities of traditional
- multiple inheritance.
- Interfaces can be very lightweight—an interface with
- one or even zero methods can express a useful concept.
- Interfaces can be added after the fact if a new idea comes along
- or for testing—without annotating the original types.
- Because there are no explicit relationships between types
- and interfaces, there is no type hierarchy to manage or discuss.
- </p>
- <p>
- It's possible to use these ideas to construct something analogous to
- type-safe Unix pipes. For instance, see how <code>fmt.Fprintf</code>
- enables formatted printing to any output, not just a file, or how the
- <code>bufio</code> package can be completely separate from file I/O,
- or how the <code>image</code> packages generate compressed
- image files. All these ideas stem from a single interface
- (<code>io.Writer</code>) representing a single method
- (<code>Write</code>). And that's only scratching the surface.
- Go's interfaces have a profound influence on how programs are structured.
- </p>
- <p>
- It takes some getting used to but this implicit style of type
- dependency is one of the most productive things about Go.
- </p>
- <h3 id="methods_on_basics">
- Why is <code>len</code> a function and not a method?</h3>
- <p>
- We debated this issue but decided
- implementing <code>len</code> and friends as functions was fine in practice and
- didn't complicate questions about the interface (in the Go type sense)
- of basic types.
- </p>
- <h3 id="overloading">
- Why does Go not support overloading of methods and operators?</h3>
- <p>
- Method dispatch is simplified if it doesn't need to do type matching as well.
- Experience with other languages told us that having a variety of
- methods with the same name but different signatures was occasionally useful
- but that it could also be confusing and fragile in practice. Matching only by name
- and requiring consistency in the types was a major simplifying decision
- in Go's type system.
- </p>
- <p>
- Regarding operator overloading, it seems more a convenience than an absolute
- requirement. Again, things are simpler without it.
- </p>
- <h3 id="implements_interface">
- Why doesn't Go have "implements" declarations?</h3>
- <p>
- A Go type satisfies an interface by implementing the methods of that interface,
- nothing more. This property allows interfaces to be defined and used without
- needing to modify existing code. It enables a kind of
- <a href="https://en.wikipedia.org/wiki/Structural_type_system">structural typing</a> that
- promotes separation of concerns and improves code re-use, and makes it easier
- to build on patterns that emerge as the code develops.
- The semantics of interfaces is one of the main reasons for Go's nimble,
- lightweight feel.
- </p>
- <p>
- See the <a href="#inheritance">question on type inheritance</a> for more detail.
- </p>
- <h3 id="guarantee_satisfies_interface">
- How can I guarantee my type satisfies an interface?</h3>
- <p>
- You can ask the compiler to check that the type <code>T</code> implements the
- interface <code>I</code> by attempting an assignment using the zero value for
- <code>T</code> or pointer to <code>T</code>, as appropriate:
- </p>
- <pre>
- type T struct{}
- var _ I = T{} // Verify that T implements I.
- var _ I = (*T)(nil) // Verify that *T implements I.
- </pre>
- <p>
- If <code>T</code> (or <code>*T</code>, accordingly) doesn't implement
- <code>I</code>, the mistake will be caught at compile time.
- </p>
- <p>
- If you wish the users of an interface to explicitly declare that they implement
- it, you can add a method with a descriptive name to the interface's method set.
- For example:
- </p>
- <pre>
- type Fooer interface {
- Foo()
- ImplementsFooer()
- }
- </pre>
- <p>
- A type must then implement the <code>ImplementsFooer</code> method to be a
- <code>Fooer</code>, clearly documenting the fact and announcing it in
- <a href="/cmd/go/#hdr-Show_documentation_for_package_or_symbol">go doc</a>'s output.
- </p>
- <pre>
- type Bar struct{}
- func (b Bar) ImplementsFooer() {}
- func (b Bar) Foo() {}
- </pre>
- <p>
- Most code doesn't make use of such constraints, since they limit the utility of
- the interface idea. Sometimes, though, they're necessary to resolve ambiguities
- among similar interfaces.
- </p>
- <h3 id="t_and_equal_interface">
- Why doesn't type T satisfy the Equal interface?</h3>
- <p>
- Consider this simple interface to represent an object that can compare
- itself with another value:
- </p>
- <pre>
- type Equaler interface {
- Equal(Equaler) bool
- }
- </pre>
- <p>
- and this type, <code>T</code>:
- </p>
- <pre>
- type T int
- func (t T) Equal(u T) bool { return t == u } // does not satisfy Equaler
- </pre>
- <p>
- Unlike the analogous situation in some polymorphic type systems,
- <code>T</code> does not implement <code>Equaler</code>.
- The argument type of <code>T.Equal</code> is <code>T</code>,
- not literally the required type <code>Equaler</code>.
- </p>
- <p>
- In Go, the type system does not promote the argument of
- <code>Equal</code>; that is the programmer's responsibility, as
- illustrated by the type <code>T2</code>, which does implement
- <code>Equaler</code>:
- </p>
- <pre>
- type T2 int
- func (t T2) Equal(u Equaler) bool { return t == u.(T2) } // satisfies Equaler
- </pre>
- <p>
- Even this isn't like other type systems, though, because in Go <em>any</em>
- type that satisfies <code>Equaler</code> could be passed as the
- argument to <code>T2.Equal</code>, and at run time we must
- check that the argument is of type <code>T2</code>.
- Some languages arrange to make that guarantee at compile time.
- </p>
- <p>
- A related example goes the other way:
- </p>
- <pre>
- type Opener interface {
- Open() Reader
- }
- func (t T3) Open() *os.File
- </pre>
- <p>
- In Go, <code>T3</code> does not satisfy <code>Opener</code>,
- although it might in another language.
- </p>
- <p>
- While it is true that Go's type system does less for the programmer
- in such cases, the lack of subtyping makes the rules about
- interface satisfaction very easy to state: are the function's names
- and signatures exactly those of the interface?
- Go's rule is also easy to implement efficiently.
- We feel these benefits offset the lack of
- automatic type promotion. Should Go one day adopt some form of polymorphic
- typing, we expect there would be a way to express the idea of these
- examples and also have them be statically checked.
- </p>
- <h3 id="convert_slice_of_interface">
- Can I convert a []T to an []interface{}?</h3>
- <p>
- Not directly.
- It is disallowed by the language specification because the two types
- do not have the same representation in memory.
- It is necessary to copy the elements individually to the destination
- slice. This example converts a slice of <code>int</code> to a slice of
- <code>interface{}</code>:
- </p>
- <pre>
- t := []int{1, 2, 3, 4}
- s := make([]interface{}, len(t))
- for i, v := range t {
- s[i] = v
- }
- </pre>
- <h3 id="convert_slice_with_same_underlying_type">
- Can I convert []T1 to []T2 if T1 and T2 have the same underlying type?</h3>
- This last line of this code sample does not compile.
- <pre>
- type T1 int
- type T2 int
- var t1 T1
- var x = T2(t1) // OK
- var st1 []T1
- var sx = ([]T2)(st1) // NOT OK
- </pre>
- <p>
- In Go, types are closely tied to methods, in that every named type has
- a (possibly empty) method set.
- The general rule is that you can change the name of the type being
- converted (and thus possibly change its method set) but you can't
- change the name (and method set) of elements of a composite type.
- Go requires you to be explicit about type conversions.
- </p>
- <h3 id="nil_error">
- Why is my nil error value not equal to nil?
- </h3>
- <p>
- Under the covers, interfaces are implemented as two elements, a type <code>T</code>
- and a value <code>V</code>.
- <code>V</code> is a concrete value such as an <code>int</code>,
- <code>struct</code> or pointer, never an interface itself, and has
- type <code>T</code>.
- For instance, if we store the <code>int</code> value 3 in an interface,
- the resulting interface value has, schematically,
- (<code>T=int</code>, <code>V=3</code>).
- The value <code>V</code> is also known as the interface's
- <em>dynamic</em> value,
- since a given interface variable might hold different values <code>V</code>
- (and corresponding types <code>T</code>)
- during the execution of the program.
- </p>
- <p>
- An interface value is <code>nil</code> only if the <code>V</code> and <code>T</code>
- are both unset, (<code>T=nil</code>, <code>V</code> is not set),
- In particular, a <code>nil</code> interface will always hold a <code>nil</code> type.
- If we store a <code>nil</code> pointer of type <code>*int</code> inside
- an interface value, the inner type will be <code>*int</code> regardless of the value of the pointer:
- (<code>T=*int</code>, <code>V=nil</code>).
- Such an interface value will therefore be non-<code>nil</code>
- <em>even when the pointer value <code>V</code> inside is</em> <code>nil</code>.
- </p>
- <p>
- This situation can be confusing, and arises when a <code>nil</code> value is
- stored inside an interface value such as an <code>error</code> return:
- </p>
- <pre>
- func returnsError() error {
- var p *MyError = nil
- if bad() {
- p = ErrBad
- }
- return p // Will always return a non-nil error.
- }
- </pre>
- <p>
- If all goes well, the function returns a <code>nil</code> <code>p</code>,
- so the return value is an <code>error</code> interface
- value holding (<code>T=*MyError</code>, <code>V=nil</code>).
- This means that if the caller compares the returned error to <code>nil</code>,
- it will always look as if there was an error even if nothing bad happened.
- To return a proper <code>nil</code> <code>error</code> to the caller,
- the function must return an explicit <code>nil</code>:
- </p>
- <pre>
- func returnsError() error {
- if bad() {
- return ErrBad
- }
- return nil
- }
- </pre>
- <p>
- It's a good idea for functions
- that return errors always to use the <code>error</code> type in
- their signature (as we did above) rather than a concrete type such
- as <code>*MyError</code>, to help guarantee the error is
- created correctly. As an example,
- <a href="/pkg/os/#Open"><code>os.Open</code></a>
- returns an <code>error</code> even though, if not <code>nil</code>,
- it's always of concrete type
- <a href="/pkg/os/#PathError"><code>*os.PathError</code></a>.
- </p>
- <p>
- Similar situations to those described here can arise whenever interfaces are used.
- Just keep in mind that if any concrete value
- has been stored in the interface, the interface will not be <code>nil</code>.
- For more information, see
- <a href="/doc/articles/laws_of_reflection.html">The Laws of Reflection</a>.
- </p>
- <h3 id="unions">
- Why are there no untagged unions, as in C?</h3>
- <p>
- Untagged unions would violate Go's memory safety
- guarantees.
- </p>
- <h3 id="variant_types">
- Why does Go not have variant types?</h3>
- <p>
- Variant types, also known as algebraic types, provide a way to specify
- that a value might take one of a set of other types, but only those
- types. A common example in systems programming would specify that an
- error is, say, a network error, a security error or an application
- error and allow the caller to discriminate the source of the problem
- by examining the type of the error. Another example is a syntax tree
- in which each node can be a different type: declaration, statement,
- assignment and so on.
- </p>
- <p>
- We considered adding variant types to Go, but after discussion
- decided to leave them out because they overlap in confusing ways
- with interfaces. What would happen if the elements of a variant type
- were themselves interfaces?
- </p>
- <p>
- Also, some of what variant types address is already covered by the
- language. The error example is easy to express using an interface
- value to hold the error and a type switch to discriminate cases. The
- syntax tree example is also doable, although not as elegantly.
- </p>
- <h3 id="covariant_types">
- Why does Go not have covariant result types?</h3>
- <p>
- Covariant result types would mean that an interface like
- </p>
- <pre>
- type Copyable interface {
- Copy() interface{}
- }
- </pre>
- <p>
- would be satisfied by the method
- </p>
- <pre>
- func (v Value) Copy() Value
- </pre>
- <p>because <code>Value</code> implements the empty interface.
- In Go method types must match exactly, so <code>Value</code> does not
- implement <code>Copyable</code>.
- Go separates the notion of what a
- type does—its methods—from the type's implementation.
- If two methods return different types, they are not doing the same thing.
- Programmers who want covariant result types are often trying to
- express a type hierarchy through interfaces.
- In Go it's more natural to have a clean separation between interface
- and implementation.
- </p>
- <h2 id="values">Values</h2>
- <h3 id="conversions">
- Why does Go not provide implicit numeric conversions?</h3>
- <p>
- The convenience of automatic conversion between numeric types in C is
- outweighed by the confusion it causes. When is an expression unsigned?
- How big is the value? Does it overflow? Is the result portable, independent
- of the machine on which it executes?
- It also complicates the compiler; “the usual arithmetic conversions”
- are not easy to implement and inconsistent across architectures.
- For reasons of portability, we decided to make things clear and straightforward
- at the cost of some explicit conversions in the code.
- The definition of constants in Go—arbitrary precision values free
- of signedness and size annotations—ameliorates matters considerably,
- though.
- </p>
- <p>
- A related detail is that, unlike in C, <code>int</code> and <code>int64</code>
- are distinct types even if <code>int</code> is a 64-bit type. The <code>int</code>
- type is generic; if you care about how many bits an integer holds, Go
- encourages you to be explicit.
- </p>
- <h3 id="constants">
- How do constants work in Go?</h3>
- <p>
- Although Go is strict about conversion between variables of different
- numeric types, constants in the language are much more flexible.
- Literal constants such as <code>23</code>, <code>3.14159</code>
- and <a href="/pkg/math/#pkg-constants"><code>math.Pi</code></a>
- occupy a sort of ideal number space, with arbitrary precision and
- no overflow or underflow.
- For instance, the value of <code>math.Pi</code> is specified to 63 places
- in the source code, and constant expressions involving the value keep
- precision beyond what a <code>float64</code> could hold.
- Only when the constant or constant expression is assigned to a
- variable—a memory location in the program—does
- it become a "computer" number with
- the usual floating-point properties and precision.
- </p>
- <p>
- Also,
- because they are just numbers, not typed values, constants in Go can be
- used more freely than variables, thereby softening some of the awkwardness
- around the strict conversion rules.
- One can write expressions such as
- </p>
- <pre>
- sqrt2 := math.Sqrt(2)
- </pre>
- <p>
- without complaint from the compiler because the ideal number <code>2</code>
- can be converted safely and accurately
- to a <code>float64</code> for the call to <code>math.Sqrt</code>.
- </p>
- <p>
- A blog post titled <a href="https://blog.golang.org/constants">Constants</a>
- explores this topic in more detail.
- </p>
- <h3 id="builtin_maps">
- Why are maps built in?</h3>
- <p>
- The same reason strings are: they are such a powerful and important data
- structure that providing one excellent implementation with syntactic support
- makes programming more pleasant. We believe that Go's implementation of maps
- is strong enough that it will serve for the vast majority of uses.
- If a specific application can benefit from a custom implementation, it's possible
- to write one but it will not be as convenient syntactically; this seems a reasonable tradeoff.
- </p>
- <h3 id="map_keys">
- Why don't maps allow slices as keys?</h3>
- <p>
- Map lookup requires an equality operator, which slices do not implement.
- They don't implement equality because equality is not well defined on such types;
- there are multiple considerations involving shallow vs. deep comparison, pointer vs.
- value comparison, how to deal with recursive types, and so on.
- We may revisit this issue—and implementing equality for slices
- will not invalidate any existing programs—but without a clear idea of what
- equality of slices should mean, it was simpler to leave it out for now.
- </p>
- <p>
- In Go 1, unlike prior releases, equality is defined for structs and arrays, so such
- types can be used as map keys. Slices still do not have a definition of equality, though.
- </p>
- <h3 id="references">
- Why are maps, slices, and channels references while arrays are values?</h3>
- <p>
- 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. 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>
- <h3 id="How_are_libraries_documented">
- How are libraries documented?</h3>
- <p>
- There is a program, <code>godoc</code>, written in Go, that extracts
- package documentation from the source code and serves it as a web
- page with links to declarations, files, and so on.
- An instance is running at
- <a href="/pkg/">golang.org/pkg/</a>.
- In fact, <code>godoc</code> implements the full site at
- <a href="/">golang.org/</a>.
- </p>
- <p>
- A <code>godoc</code> instance may be configured to provide rich,
- interactive static analyses of symbols in the programs it displays; details are
- listed <a href="https://golang.org/lib/godoc/analysis/help.html">here</a>.
- </p>
- <p>
- For access to documentation from the command line, the
- <a href="https://golang.org/pkg/cmd/go/">go</a> tool has a
- <a href="https://golang.org/pkg/cmd/go/#hdr-Show_documentation_for_package_or_symbol">doc</a>
- subcommand that provides a textual interface to the same information.
- </p>
- <h3 id="Is_there_a_Go_programming_style_guide">
- Is there a Go programming style guide?</h3>
- <p>
- There is no explicit style guide, although there is certainly
- a recognizable "Go style".
- </p>
- <p>
- Go has established conventions to guide decisions around
- naming, layout, and file organization.
- The document <a href="effective_go.html">Effective Go</a>
- contains some advice on these topics.
- More directly, the program <code>gofmt</code> is a pretty-printer
- whose purpose is to enforce layout rules; it replaces the usual
- compendium of do's and don'ts that allows interpretation.
- All the Go code in the repository, and the vast majority in the
- open source world, has been run through <code>gofmt</code>.
- </p>
- <p>
- The document titled
- <a href="//golang.org/s/comments">Go Code Review Comments</a>
- is a collection of very short essays about details of Go idiom that are often
- missed by programmers.
- It is a handy reference for people doing code reviews for Go projects.
- </p>
- <h3 id="How_do_I_submit_patches_to_the_Go_libraries">
- How do I submit patches to the Go libraries?</h3>
- <p>
- The library sources are in the <code>src</code> directory of the repository.
- If you want to make a significant change, please discuss on the mailing list before embarking.
- </p>
- <p>
- See the document
- <a href="contribute.html">Contributing to the Go project</a>
- for more information about how to proceed.
- </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>
- <code>Git</code> can be configured to authenticate over HTTPS or to use SSH in place of HTTPS.
- To authenticate over HTTPS, you can add a line
- to the <code>$HOME/.netrc</code> file that git consults:
- </p>
- <pre>
- machine github.com login <i>USERNAME</i> password <i>APIKEY</i>
- </pre>
- <p>
- For GitHub accounts, the password can be a
- <a href="https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line/">personal access token</a>.
- </p>
- <p>
- <code>Git</code> can also be configured to use SSH in place of HTTPS for URLs matching a given prefix.
- For example, to use SSH for all GitHub access,
- add these lines to your <code>~/.gitconfig</code>:
- </p>
- <pre>
- [url "ssh://git@github.com/"]
- insteadOf = https://github.com/
- </pre>
- <h3 id="get_version">
- How should I manage package versions using "go get"?</h3>
- <p>
- Since the inception of the project, Go has had no explicit concept of package versions,
- but that is changing.
- Versioning is a source of significant complexity, especially in large code bases,
- and it has taken some time to develop an
- approach that works well at scale in a large enough
- variety of situations to be appropriate to supply to all Go users.
- </p>
- <p>
- The Go 1.11 release adds new, experimental support
- for package versioning to the <code>go</code> command,
- in the form of Go modules.
- For more information, see the <a href="/doc/go1.11#modules">Go 1.11 release notes</a>
- and the <a href="/cmd/go#hdr-Modules__module_versions__and_more"><code>go</code> command documentation</a>.
- </p>
- <p>
- Regardless of the actual package management technology,
- "go get" and the larger Go toolchain does provide isolation of
- packages with different import paths.
- For example, the standard library's <code>html/template</code> and <code>text/template</code>
- coexist even though both are "package template".
- This observation leads to some advice for package authors and package users.
- </p>
- <p>
- Packages intended for public use should try to maintain backwards compatibility as they evolve.
- The <a href="/doc/go1compat.html">Go 1 compatibility guidelines</a> are a good reference here:
- don't remove exported names, encourage tagged composite literals, and so on.
- If different functionality is required, add a new name instead of changing an old one.
- If a complete break is required, create a new package with a new import path.
- </p>
- <p>
- If you're using an externally supplied package and worry that it might change in
- unexpected ways, but are not yet using Go modules,
- the simplest solution is to copy it to your local repository.
- This is the approach Google takes internally and is supported by the
- <code>go</code> command through a technique called "vendoring".
- This involves
- storing a copy of the dependency under a new import path that identifies it as a local copy.
- See the <a href="https://golang.org/s/go15vendor">design
- document</a> for details.
- </p>
- <h2 id="Pointers">Pointers and Allocation</h2>
- <h3 id="pass_by_value">
- When are function parameters passed by value?</h3>
- <p>
- As in all languages in the C family, everything in Go is passed by value.
- That is, a function always gets a copy of the
- thing being passed, as if there were an assignment statement assigning the
- value to the parameter. For instance, passing an <code>int</code> value
- to a function makes a copy of the <code>int</code>, and passing a pointer
- value makes a copy of the pointer, but not the data it points to.
- (See a <a href="/doc/faq#methods_on_values_or_pointers">later
- section</a> for a discussion of how this affects method receivers.)
- </p>
- <p>
- Map and slice values behave like pointers: they are descriptors that
- contain pointers to the underlying map or slice data. Copying a map or
- slice value doesn't copy the data it points to. Copying an interface value
- makes a copy of the thing stored in the interface value. If the interface
- value holds a struct, copying the interface value makes a copy of the
- struct. If the interface value holds a pointer, copying the interface value
- makes a copy of the pointer, but again not the data it points to.
- </p>
- <p>
- Note that this discussion is about the semantics of the operations.
- Actual implementations may apply optimizations to avoid copying
- as long as the optimizations do not change the semantics.
- </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 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 an 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>
- <pre>
- func (s *MyStruct) pointerMethod() { } // method on pointer
- func (s MyStruct) valueMethod() { } // method on value
- </pre>
- <p>
- For programmers unaccustomed to pointers, the distinction between these
- two examples can be confusing, but the situation is actually very simple.
- When defining a method on a type, the receiver (<code>s</code> in the above
- examples) behaves exactly as if it were an argument to the method.
- Whether to define the receiver as a value or as a pointer is the same
- question, then, as whether a function argument should be a value or
- a pointer.
- There are several considerations.
- </p>
- <p>
- 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 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
- the fields of <code>s</code>,
- the caller will see those changes, but <code>valueMethod</code>
- is called with a copy of the caller's argument (that's the definition
- of passing a value), so changes it makes will be invisible to the caller.
- </p>
- <p>
- By the way, in Java method receivers are always pointers,
- although their pointer nature is somewhat disguised
- (and there is a proposal to add value receivers to the language).
- It is the value receivers in Go that are unusual.
- </p>
- <p>
- Second is the consideration of efficiency. If the receiver is large,
- a big <code>struct</code> for instance, it will be much cheaper to
- use a pointer receiver.
- </p>
- <p>
- Next is consistency. If some of the methods of the type must have
- pointer receivers, the rest should too, so the method set is
- consistent regardless of how the type is used.
- See the section on <a href="#different_method_sets">method sets</a>
- for details.
- </p>
- <p>
- For types such as basic types, slices, and small <code>structs</code>,
- a value receiver is very cheap so unless the semantics of the method
- requires a pointer, a value receiver is efficient and clear.
- </p>
- <h3 id="new_and_make">
- What's the difference between new and make?</h3>
- <p>
- In short: <code>new</code> allocates memory, while <code>make</code> initializes
- the slice, map, and channel types.
- </p>
- <p>
- See the <a href="/doc/effective_go.html#allocation_new">relevant section
- of Effective Go</a> for more details.
- </p>
- <h3 id="q_int_sizes">
- 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
- but the same as each other on a given platform.
- For portability, code that relies on a particular
- size of value should use an explicitly sized type, like <code>int64</code>.
- On 32-bit machines the compilers use 32-bit integers by default,
- while on 64-bit machines integers have 64 bits.
- (Historically, this was not always true.)
- </p>
- <p>
- On the other hand, floating-point scalars and complex
- types are always sized (there are no <code>float</code> or <code>complex</code> basic types),
- because programmers should be aware of precision when using floating-point numbers.
- The default type used for an (untyped) floating-point constant is <code>float64</code>.
- Thus <code>foo</code> <code>:=</code> <code>3.0</code> declares a variable <code>foo</code>
- of type <code>float64</code>.
- For a <code>float32</code> variable initialized by an (untyped) constant, the variable type
- must be specified explicitly in the variable declaration:
- </p>
- <pre>
- var foo float32 = 3.0
- </pre>
- <p>
- Alternatively, the constant must be given a type with a conversion as in
- <code>foo := float32(3.0)</code>.
- </p>
- <h3 id="stack_or_heap">
- How do I know whether a variable is allocated on the heap or the stack?</h3>
- <p>
- From a correctness standpoint, you don't need to know.
- Each variable in Go exists as long as there are references to it.
- The storage location chosen by the implementation is irrelevant to the
- semantics of the language.
- </p>
- <p>
- The storage location does have an effect on writing efficient programs.
- When possible, the Go compilers will allocate variables that are
- local to a function in that function's stack frame. However, if the
- compiler cannot prove that the variable is not referenced after the
- function returns, then the compiler must allocate the variable on the
- garbage-collected heap to avoid dangling pointer errors.
- Also, if a local variable is very large, it might make more sense
- to store it on the heap rather than the stack.
- </p>
- <p>
- In the current compilers, if a variable has its address taken, that variable
- is a candidate for allocation on the heap. However, a basic <em>escape
- analysis</em> recognizes some cases when such variables will not
- live past the return from the function and can reside on the stack.
- </p>
- <h3 id="Why_does_my_Go_process_use_so_much_virtual_memory">
- Why does my Go process use so much virtual memory?</h3>
- <p>
- The Go memory allocator reserves a large region of virtual memory as an arena
- for allocations. This virtual memory is local to the specific Go process; the
- reservation does not deprive other processes of memory.
- </p>
- <p>
- To find the amount of actual memory allocated to a Go process, use the Unix
- <code>top</code> command and consult the <code>RES</code> (Linux) or
- <code>RSIZE</code> (macOS) columns.
- <!-- TODO(adg): find out how this works on Windows -->
- </p>
- <h2 id="Concurrency">Concurrency</h2>
- <h3 id="What_operations_are_atomic_What_about_mutexes">
- What operations are atomic? What about mutexes?</h3>
- <p>
- A description of the atomicity of operations in Go can be found in
- the <a href="/ref/mem">Go Memory Model</a> document.
- </p>
- <p>
- Low-level synchronization and atomic primitives are available in the
- <a href="/pkg/sync">sync</a> and
- <a href="/pkg/sync/atomic">sync/atomic</a>
- packages.
- These packages are good for simple tasks such as incrementing
- reference counts or guaranteeing small-scale mutual exclusion.
- </p>
- <p>
- For higher-level operations, such as coordination among
- concurrent servers, higher-level techniques can lead
- to nicer programs, and Go supports this approach through
- its goroutines and channels.
- For instance, you can structure your program so that only one
- goroutine at a time is ever responsible for a particular piece of data.
- That approach is summarized by the original
- <a href="https://www.youtube.com/watch?v=PAAkCSZUG1c">Go proverb</a>,
- </p>
- <p>
- Do not communicate by sharing memory. Instead, share memory by communicating.
- </p>
- <p>
- See the <a href="/doc/codewalk/sharemem/">Share Memory By Communicating</a> code walk
- and its <a href="https://blog.golang.org/2010/07/share-memory-by-communicating.html">
- associated article</a> for a detailed discussion of this concept.
- </p>
- <p>
- Large concurrent programs are likely to borrow from both these toolkits.
- </p>
- <h3 id="parallel_slow">
- Why doesn't my program run faster with more CPUs?</h3>
- <p>
- Whether a program runs faster with more CPUs depends on the problem
- it is solving.
- The Go language provides concurrency primitives, such as goroutines
- and channels, but concurrency only enables parallelism
- when the underlying problem is intrinsically parallel.
- Problems that are intrinsically sequential cannot be sped up by adding
- more CPUs, while those that can be broken into pieces that can
- execute in parallel can be sped up, sometimes dramatically.
- </p>
- <p>
- Sometimes adding more CPUs can slow a program down.
- In practical terms, programs that spend more time
- synchronizing or communicating than doing useful computation
- may experience performance degradation when using
- multiple OS threads.
- This is because passing data between threads involves switching
- contexts, which has significant cost, and that cost can increase
- with more CPUs.
- For instance, the <a href="/ref/spec#An_example_package">prime sieve example</a>
- from the Go specification has no significant parallelism although it launches many
- goroutines; increasing the number of threads (CPUs) is more likely to slow it down than
- to speed it up.
- </p>
- <p>
- For more detail on this topic see the talk entitled
- <a href="//blog.golang.org/2013/01/concurrency-is-not-parallelism.html">Concurrency
- is not Parallelism</a>.
- <h3 id="number_cpus">
- How can I control the number of CPUs?</h3>
- <p>
- The number of CPUs available simultaneously to executing goroutines is
- controlled by the <code>GOMAXPROCS</code> shell environment variable,
- whose default value is the number of CPU cores available.
- Programs with the potential for parallel execution should therefore
- achieve it by default on a multiple-CPU machine.
- To change the number of parallel CPUs to use,
- set the environment variable or use the similarly-named
- <a href="/pkg/runtime/#GOMAXPROCS">function</a>
- of the runtime package to configure the
- run-time support to utilize a different number of threads.
- Setting it to 1 eliminates the possibility of true parallelism,
- forcing independent goroutines to take turns executing.
- </p>
- <p>
- The runtime can allocate more threads than the value
- of <code>GOMAXPROCS</code> to service multiple outstanding
- I/O requests.
- <code>GOMAXPROCS</code> only affects how many goroutines
- can actually execute at once; arbitrarily more may be blocked
- in system calls.
- </p>
- <p>
- Go's goroutine scheduler is not as good as it needs to be, although it
- has improved over time.
- In the future, it may better optimize its use of OS threads.
- For now, if there are performance issues,
- setting <code>GOMAXPROCS</code> on a per-application basis may help.
- </p>
- <h3 id="no_goroutine_id">
- Why is there no goroutine ID?</h3>
- <p>
- Goroutines do not have names; they are just anonymous workers.
- They expose no unique identifier, name, or data structure to the programmer.
- Some people are surprised by this, expecting the <code>go</code>
- statement to return some item that can be used to access and control
- the goroutine later.
- </p>
- <p>
- The fundamental reason goroutines are anonymous is so that
- the full Go language is available when programming concurrent code.
- By contrast, the usage patterns that develop when threads and goroutines are
- named can restrict what a library using them can do.
- </p>
- <p>
- Here is an illustration of the difficulties.
- Once one names a goroutine and constructs a model around
- it, it becomes special, and one is tempted to associate all computation
- with that goroutine, ignoring the possibility
- of using multiple, possibly shared goroutines for the processing.
- If the <code>net/http</code> package associated per-request
- state with a goroutine,
- clients would be unable to use more goroutines
- when serving a request.
- </p>
- <p>
- Moreover, experience with libraries such as those for graphics systems
- that require all processing to occur on the "main thread"
- has shown how awkward and limiting the approach can be when
- deployed in a concurrent language.
- The very existence of a special thread or goroutine forces
- the programmer to distort the program to avoid crashes
- and other problems caused by inadvertently operating
- on the wrong thread.
- </p>
- <p>
- For those cases where a particular goroutine is truly special,
- the language provides features such as channels that can be
- used in flexible ways to interact with it.
- </p>
- <h2 id="Functions_methods">Functions and Methods</h2>
- <h3 id="different_method_sets">
- Why do T and *T have different method sets?</h3>
- <p>
- As the <a href="/ref/spec#Types">Go specification</a> says,
- the method set of a type <code>T</code> consists of all methods
- with receiver type <code>T</code>,
- while that of the corresponding pointer
- type <code>*T</code> consists of all methods with receiver <code>*T</code> or
- <code>T</code>.
- That means the method set of <code>*T</code>
- includes that of <code>T</code>,
- but not the reverse.
- </p>
- <p>
- This distinction arises because
- if an interface value contains a pointer <code>*T</code>,
- a method call can obtain a value by dereferencing the pointer,
- but if an interface value contains a value <code>T</code>,
- there is no safe way for a method call to obtain a pointer.
- (Doing so would allow a method to modify the contents of
- the value inside the interface, which is not permitted by
- the language specification.)
- </p>
- <p>
- Even in cases where the compiler could take the address of a value
- to pass to the method, if the method modifies the value the changes
- will be lost in the caller.
- As an example, if the <code>Write</code> method of
- <a href="/pkg/bytes/#Buffer"><code>bytes.Buffer</code></a>
- used a value receiver rather than a pointer,
- this code:
- </p>
- <pre>
- var buf bytes.Buffer
- io.Copy(buf, os.Stdin)
- </pre>
- <p>
- would copy standard input into a <i>copy</i> of <code>buf</code>,
- not into <code>buf</code> itself.
- This is almost never the desired behavior.
- </p>
- <h3 id="closures_and_goroutines">
- What happens with closures running as goroutines?</h3>
- <p>
- Some confusion may arise when using closures with concurrency.
- Consider the following program:
- </p>
- <pre>
- func main() {
- done := make(chan bool)
- values := []string{"a", "b", "c"}
- for _, v := range values {
- go func() {
- fmt.Println(v)
- done <- true
- }()
- }
- // wait for all goroutines to complete before exiting
- for _ = range values {
- <-done
- }
- }
- </pre>
- <p>
- One might mistakenly expect to see <code>a, b, c</code> as the output.
- What you'll probably see instead is <code>c, c, c</code>. This is because
- each iteration of the loop uses the same instance of the variable <code>v</code>, so
- each closure shares that single variable. When the closure runs, it prints the
- value of <code>v</code> at the time <code>fmt.Println</code> is executed,
- but <code>v</code> may have been modified since the goroutine was launched.
- To help detect this and other problems before they happen, run
- <a href="/cmd/go/#hdr-Run_go_tool_vet_on_packages"><code>go vet</code></a>.
- </p>
- <p>
- To bind the current value of <code>v</code> to each closure as it is launched, one
- must modify the inner loop to create a new variable each iteration.
- One way is to pass the variable as an argument to the closure:
- </p>
- <pre>
- for _, v := range values {
- go func(<b>u</b> string) {
- fmt.Println(<b>u</b>)
- done <- true
- }(<b>v</b>)
- }
- </pre>
- <p>
- In this example, the value of <code>v</code> is passed as an argument to the
- anonymous function. That value is then accessible inside the function as
- the variable <code>u</code>.
- </p>
- <p>
- Even easier is just to create a new variable, using a declaration style that may
- seem odd but works fine in Go:
- </p>
- <pre>
- for _, v := range values {
- <b>v := v</b> // create a new 'v'.
- go func() {
- fmt.Println(<b>v</b>)
- done <- true
- }()
- }
- </pre>
- <p>
- This behavior of the language, not defining a new variable for
- each iteration, may have been a mistake in retrospect.
- It may be addressed in a later version but, for compatibility,
- cannot change in Go version 1.
- </p>
- <h2 id="Control_flow">Control flow</h2>
- <h3 id="Does_Go_have_a_ternary_form">
- Why does Go not have the <code>?:</code> operator?</h3>
- <p>
- There is no ternary testing operation in Go.
- You may use the following to achieve the same
- result:
- </p>
- <pre>
- if expr {
- n = trueVal
- } else {
- n = falseVal
- }
- </pre>
- <p>
- The reason <code>?:</code> is absent from Go is that the language's designers
- had seen the operation used too often to create impenetrably complex expressions.
- The <code>if-else</code> form, although longer,
- is unquestionably clearer.
- A language needs only one conditional control flow construct.
- </p>
- <h2 id="Packages_Testing">Packages and Testing</h2>
- <h3 id="How_do_I_create_a_multifile_package">
- How do I create a multifile package?</h3>
- <p>
- Put all the source files for the package in a directory by themselves.
- Source files can refer to items from different files at will; there is
- no need for forward declarations or a header file.
- </p>
- <p>
- Other than being split into multiple files, the package will compile and test
- just like a single-file package.
- </p>
- <h3 id="How_do_I_write_a_unit_test">
- How do I write a unit test?</h3>
- <p>
- Create a new file ending in <code>_test.go</code> in the same directory
- as your package sources. Inside that file, <code>import "testing"</code>
- and write functions of the form
- </p>
- <pre>
- func TestFoo(t *testing.T) {
- ...
- }
- </pre>
- <p>
- Run <code>go test</code> in that directory.
- That script finds the <code>Test</code> functions,
- builds a test binary, and runs it.
- </p>
- <p>See the <a href="/doc/code.html">How to Write Go Code</a> document,
- the <a href="/pkg/testing/"><code>testing</code></a> package
- and the <a href="/cmd/go/#hdr-Test_packages"><code>go test</code></a> subcommand for more details.
- </p>
- <h3 id="testing_framework">
- Where is my favorite helper function for testing?</h3>
- <p>
- Go's standard <a href="/pkg/testing/"><code>testing</code></a> package makes it easy to write unit tests, but it lacks
- features provided in other language's testing frameworks such as assertion functions.
- An <a href="#assertions">earlier section</a> of this document explained why Go
- doesn't have assertions, and
- the same arguments apply to the use of <code>assert</code> in tests.
- Proper error handling means letting other tests run after one has failed, so
- that the person debugging the failure gets a complete picture of what is
- wrong. It is more useful for a test to report that
- <code>isPrime</code> gives the wrong answer for 2, 3, 5, and 7 (or for
- 2, 4, 8, and 16) than to report that <code>isPrime</code> gives the wrong
- answer for 2 and therefore no more tests were run. The programmer who
- triggers the test failure may not be familiar with the code that fails.
- Time invested writing a good error message now pays off later when the
- test breaks.
- </p>
- <p>
- A related point is that testing frameworks tend to develop into mini-languages
- of their own, with conditionals and controls and printing mechanisms,
- but Go already has all those capabilities; why recreate them?
- We'd rather write tests in Go; it's one fewer language to learn and the
- approach keeps the tests straightforward and easy to understand.
- </p>
- <p>
- If the amount of extra code required to write
- good errors seems repetitive and overwhelming, the test might work better if
- table-driven, iterating over a list of inputs and outputs defined
- in a data structure (Go has excellent support for data structure literals).
- The work to write a good test and good error messages will then be amortized over many
- test cases. The standard Go library is full of illustrative examples, such as in
- <a href="/src/fmt/fmt_test.go">the formatting tests for the <code>fmt</code> package</a>.
- </p>
- <h3 id="x_in_std">
- Why isn't <i>X</i> in the standard library?</h3>
- <p>
- The standard library's purpose is to support the runtime, connect to
- the operating system, and provide key functionality that many Go
- programs require, such as formatted I/O and networking.
- It also contains elements important for web programming, including
- cryptography and support for standards like HTTP, JSON, and XML.
- </p>
- <p>
- There is no clear criterion that defines what is included because for
- a long time, this was the <i>only</i> Go library.
- There are criteria that define what gets added today, however.
- </p>
- <p>
- New additions to the standard library are rare and the bar for
- inclusion is high.
- Code included in the standard library bears a large ongoing maintenance cost
- (often borne by those other than the original author),
- is subject to the <a href="/doc/go1compat.html">Go 1 compatibility promise</a>
- (blocking fixes to any flaws in the API),
- and is subject to the Go
- <a href="https://golang.org/s/releasesched">release schedule</a>,
- preventing bug fixes from being available to users quickly.
- </p>
- <p>
- Most new code should live outside of the standard library and be accessible
- via the <a href="/cmd/go/"><code>go</code> tool</a>'s
- <code>go get</code> command.
- Such code can have its own maintainers, release cycle,
- and compatibility guarantees.
- Users can find packages and read their documentation at
- <a href="https://godoc.org/">godoc.org</a>.
- </p>
- <p>
- Although there are pieces in the standard library that don't really belong,
- such as <code>log/syslog</code>, we continue to maintain everything in the
- library because of the Go 1 compatibility promise.
- But we encourage most new code to live elsewhere.
- </p>
- <h2 id="Implementation">Implementation</h2>
- <h3 id="What_compiler_technology_is_used_to_build_the_compilers">
- What compiler technology is used to build the compilers?</h3>
- <p>
- There are several production compilers for Go, and a number of others
- in development for various platforms.
- </p>
- <p>
- The default compiler, <code>gc</code>, is included with the
- Go distribution as part of the support for the <code>go</code>
- command.
- <code>Gc</code> was originally written in C
- because of the difficulties of bootstrapping—you'd need a Go compiler to
- set up a Go environment.
- But things have advanced and since the Go 1.5 release the compiler has been
- a Go program.
- The compiler was converted from C to Go using automatic translation tools, as
- described in this <a href="/s/go13compiler">design document</a>
- and <a href="https://talks.golang.org/2015/gogo.slide#1">talk</a>.
- Thus the compiler is now "self-hosting", which means we needed to face
- the bootstrapping problem.
- The solution is to have a working Go installation already in place,
- just as one normally has with a working C installation.
- The story of how to bring up a new Go environment from source
- is described <a href="/s/go15bootstrap">here</a> and
- <a href="/doc/install/source">here</a>.
- </p>
- <p>
- <code>Gc</code> is written in Go with a recursive descent parser
- and uses a custom loader, also written in Go but
- based on the Plan 9 loader, to generate ELF/Mach-O/PE binaries.
- </p>
- <p>
- At the beginning of the project we considered using LLVM for
- <code>gc</code> but decided it was too large and slow to meet
- our performance goals.
- More important in retrospect, starting with LLVM would have made it
- harder to introduce some of the ABI and related changes, such as
- stack management, that Go requires but not are not part of the
- standard C setup.
- A new <a href="https://go.googlesource.com/gollvm/">LLVM implementation</a>
- is starting to come together now, however.
- </p>
- <p>
- The <code>Gccgo</code> compiler is a front end written in C++
- with a recursive descent parser coupled to the
- standard GCC back end.
- </p>
- <p>
- Go turned out to be a fine language in which to implement a Go compiler,
- although that was not its original goal.
- Not being self-hosting from the beginning allowed Go's design to
- concentrate on its original use case, which was networked servers.
- Had we decided Go should compile itself early on, we might have
- ended up with a language targeted more for compiler construction,
- which is a worthy goal but not the one we had initially.
- </p>
- <p>
- Although <code>gc</code> does not use them (yet?), a native lexer and
- parser are available in the <a href="/pkg/go/"><code>go</code></a> package
- and there is also a native <a href="/pkg/go/types">type checker</a>.
- </p>
- <h3 id="How_is_the_run_time_support_implemented">
- How is the run-time support implemented?</h3>
- <p>
- Again due to bootstrapping issues, the run-time code was originally written mostly in C (with a
- tiny bit of assembler) but it has since been translated to Go
- (except for some assembler bits).
- <code>Gccgo</code>'s run-time support uses <code>glibc</code>.
- The <code>gccgo</code> compiler implements goroutines using
- a technique called segmented stacks,
- supported by recent modifications to the gold linker.
- <code>Gollvm</code> similarly is built on the corresponding
- LLVM infrastructure.
- </p>
- <h3 id="Why_is_my_trivial_program_such_a_large_binary">
- Why is my trivial program such a large binary?</h3>
- <p>
- The linker in the <code>gc</code> toolchain
- creates statically-linked binaries by default.
- All Go binaries therefore include the Go
- runtime, along with the run-time type information necessary to support dynamic
- type checks, reflection, and even panic-time stack traces.
- </p>
- <p>
- A simple C "hello, world" program compiled and linked statically using
- gcc on Linux is around 750 kB, including an implementation of
- <code>printf</code>.
- An equivalent Go program using
- <code>fmt.Printf</code> weighs a couple of megabytes, but that includes
- more powerful run-time support and type and debugging information.
- </p>
- <p>
- A Go program compiled with <code>gc</code> can be linked with
- the <code>-ldflags=-w</code> flag to disable DWARF generation,
- removing debugging information from the binary but with no
- other loss of functionality.
- This can reduce the binary size substantially.
- </p>
- <h3 id="unused_variables_and_imports">
- Can I stop these complaints about my unused variable/import?</h3>
- <p>
- The presence of an unused variable may indicate a bug, while
- unused imports just slow down compilation,
- an effect that can become substantial as a program accumulates
- code and programmers over time.
- For these reasons, Go refuses to compile programs with unused
- variables or imports,
- trading short-term convenience for long-term build speed and
- program clarity.
- </p>
- <p>
- Still, when developing code, it's common to create these situations
- temporarily and it can be annoying to have to edit them out before the
- program will compile.
- </p>
- <p>
- Some have asked for a compiler option to turn those checks off
- or at least reduce them to warnings.
- Such an option has not been added, though,
- because compiler options should not affect the semantics of the
- language and because the Go compiler does not report warnings, only
- errors that prevent compilation.
- </p>
- <p>
- There are two reasons for having no warnings. First, if it's worth
- complaining about, it's worth fixing in the code. (And if it's not
- worth fixing, it's not worth mentioning.) Second, having the compiler
- generate warnings encourages the implementation to warn about weak
- cases that can make compilation noisy, masking real errors that
- <em>should</em> be fixed.
- </p>
- <p>
- It's easy to address the situation, though. Use the blank identifier
- to let unused things persist while you're developing.
- </p>
- <pre>
- import "unused"
- // This declaration marks the import as used by referencing an
- // item from the package.
- var _ = unused.Item // TODO: Delete before committing!
- func main() {
- debugData := debug.Profile()
- _ = debugData // Used only during debugging.
- ....
- }
- </pre>
- <p>
- Nowadays, most Go programmers use a tool,
- <a href="https://godoc.org/golang.org/x/tools/cmd/goimports">goimports</a>,
- which automatically rewrites a Go source file to have the correct imports,
- eliminating the unused imports issue in practice.
- This program is easily connected to most editors to run automatically when a Go source file is written.
- </p>
- <h3 id="virus">
- Why does my virus-scanning software think my Go distribution or compiled binary is infected?</h3>
- <p>
- This is a common occurrence, especially on Windows machines, and is almost always a false positive.
- Commercial virus scanning programs are often confused by the structure of Go binaries, which
- they don't see as often as those compiled from other languages.
- </p>
- <p>
- If you've just installed the Go distribution and the system reports it is infected, that's certainly a mistake.
- To be really thorough, you can verify the download by comparing the checksum with those on the
- <a href="https://golang.org/dl/">downloads page</a>.
- </p>
- <p>
- In any case, if you believe the report is in error, please report a bug to the supplier of your virus scanner.
- Maybe in time virus scanners can learn to understand Go programs.
- </p>
- <h2 id="Performance">Performance</h2>
- <h3 id="Why_does_Go_perform_badly_on_benchmark_x">
- Why does Go perform badly on benchmark X?</h3>
- <p>
- One of Go's design goals is to approach the performance of C for comparable
- programs, yet on some benchmarks it does quite poorly, including several
- in <a href="https://go.googlesource.com/exp/+/master/shootout/">golang.org/x/exp/shootout</a>.
- The slowest depend on libraries for which versions of comparable performance
- are not available in Go.
- For instance, <a href="https://go.googlesource.com/exp/+/master/shootout/pidigits.go">pidigits.go</a>
- depends on a multi-precision math package, and the C
- versions, unlike Go's, use <a href="https://gmplib.org/">GMP</a> (which is
- written in optimized assembler).
- Benchmarks that depend on regular expressions
- (<a href="https://go.googlesource.com/exp/+/master/shootout/regex-dna.go">regex-dna.go</a>,
- for instance) are essentially comparing Go's native <a href="/pkg/regexp">regexp package</a> to
- mature, highly optimized regular expression libraries like PCRE.
- </p>
- <p>
- Benchmark games are won by extensive tuning and the Go versions of most
- of the benchmarks need attention. If you measure comparable C
- and Go programs
- (<a href="https://go.googlesource.com/exp/+/master/shootout/reverse-complement.go">reverse-complement.go</a>
- is one example), you'll see the two languages are much closer in raw performance
- than this suite would indicate.
- </p>
- <p>
- Still, there is room for improvement. The compilers are good but could be
- better, many libraries need major performance work, and the garbage collector
- isn't fast enough yet. (Even if it were, taking care not to generate unnecessary
- garbage can have a huge effect.)
- </p>
- <p>
- In any case, Go can often be very competitive.
- There has been significant improvement in the performance of many programs
- as the language and tools have developed.
- See the blog post about
- <a href="//blog.golang.org/2011/06/profiling-go-programs.html">profiling
- Go programs</a> for an informative example.
- <h2 id="change_from_c">Changes from C</h2>
- <h3 id="different_syntax">
- Why is the syntax so different from C?</h3>
- <p>
- Other than declaration syntax, the differences are not major and stem
- from two desires. First, the syntax should feel light, without too
- many mandatory keywords, repetition, or arcana. Second, the language
- has been designed to be easy to analyze
- and can be parsed without a symbol table. This makes it much easier
- to build tools such as debuggers, dependency analyzers, automated
- documentation extractors, IDE plug-ins, and so on. C and its
- descendants are notoriously difficult in this regard.
- </p>
- <h3 id="declarations_backwards">
- Why are declarations backwards?</h3>
- <p>
- They're only backwards if you're used to C. In C, the notion is that a
- variable is declared like an expression denoting its type, which is a
- nice idea, but the type and expression grammars don't mix very well and
- the results can be confusing; consider function pointers. Go mostly
- separates expression and type syntax and that simplifies things (using
- prefix <code>*</code> for pointers is an exception that proves the rule). In C,
- the declaration
- </p>
- <pre>
- int* a, b;
- </pre>
- <p>
- declares <code>a</code> to be a pointer but not <code>b</code>; in Go
- </p>
- <pre>
- var a, b *int
- </pre>
- <p>
- declares both to be pointers. This is clearer and more regular.
- Also, the <code>:=</code> short declaration form argues that a full variable
- declaration should present the same order as <code>:=</code> so
- </p>
- <pre>
- var a uint64 = 1
- </pre>
- <p>
- has the same effect as
- </p>
- <pre>
- a := uint64(1)
- </pre>
- <p>
- Parsing is also simplified by having a distinct grammar for types that
- is not just the expression grammar; keywords such as <code>func</code>
- and <code>chan</code> keep things clear.
- </p>
- <p>
- See the article about
- <a href="/doc/articles/gos_declaration_syntax.html">Go's Declaration Syntax</a>
- for more details.
- </p>
- <h3 id="no_pointer_arithmetic">
- Why is there no pointer arithmetic?</h3>
- <p>
- Safety. Without pointer arithmetic it's possible to create a
- language that can never derive an illegal address that succeeds
- incorrectly. Compiler and hardware technology have advanced to the
- point where a loop using array indices can be as efficient as a loop
- using pointer arithmetic. Also, the lack of pointer arithmetic can
- simplify the implementation of the garbage collector.
- </p>
- <h3 id="inc_dec">
- Why are <code>++</code> and <code>--</code> statements and not expressions? And why postfix, not prefix?</h3>
- <p>
- Without pointer arithmetic, the convenience value of pre- and postfix
- increment operators drops. By removing them from the expression
- hierarchy altogether, expression syntax is simplified and the messy
- issues around order of evaluation of <code>++</code> and <code>--</code>
- (consider <code>f(i++)</code> and <code>p[i] = q[++i]</code>)
- are eliminated as well. The simplification is
- significant. As for postfix vs. prefix, either would work fine but
- the postfix version is more traditional; insistence on prefix arose
- with the STL, a library for a language whose name contains, ironically, a
- postfix increment.
- </p>
- <h3 id="semicolons">
- Why are there braces but no semicolons? And why can't I put the opening
- brace on the next line?</h3>
- <p>
- Go uses brace brackets for statement grouping, a syntax familiar to
- programmers who have worked with any language in the C family.
- Semicolons, however, are for parsers, not for people, and we wanted to
- eliminate them as much as possible. To achieve this goal, Go borrows
- a trick from BCPL: the semicolons that separate statements are in the
- formal grammar but are injected automatically, without lookahead, by
- the lexer at the end of any line that could be the end of a statement.
- This works very well in practice but has the effect that it forces a
- brace style. For instance, the opening brace of a function cannot
- appear on a line by itself.
- </p>
- <p>
- Some have argued that the lexer should do lookahead to permit the
- brace to live on the next line. We disagree. Since Go code is meant
- to be formatted automatically by
- <a href="/cmd/gofmt/"><code>gofmt</code></a>,
- <i>some</i> style must be chosen. That style may differ from what
- you've used in C or Java, but Go is a different language and
- <code>gofmt</code>'s style is as good as any other. More
- important—much more important—the advantages of a single,
- programmatically mandated format for all Go programs greatly outweigh
- any perceived disadvantages of the particular style.
- Note too that Go's style means that an interactive implementation of
- Go can use the standard syntax one line at a time without special rules.
- </p>
- <h3 id="garbage_collection">
- Why do garbage collection? Won't it be too expensive?</h3>
- <p>
- One of the biggest sources of bookkeeping in systems programs is
- managing the lifetimes of allocated objects.
- In languages such as C in which it is done manually,
- it can consume a significant amount of programmer time and is
- often the cause of pernicious bugs.
- Even in languages like C++ or Rust that provide mechanisms
- to assist, those mechanisms can have a significant effect on the
- design of the software, often adding programming overhead
- of its own.
- We felt it was critical to eliminate such
- programmer overheads, and advances in garbage collection
- technology in the last few years gave us confidence that it
- could be implemented cheaply enough, and with low enough
- latency, that it could be a viable approach for networked
- systems.
- </p>
- <p>
- Much of the difficulty of concurrent programming
- has its roots in the object lifetime problem:
- as objects get passed among threads it becomes cumbersome
- to guarantee they become freed safely.
- Automatic garbage collection makes concurrent code far easier to write.
- Of course, implementing garbage collection in a concurrent environment is
- itself a challenge, but meeting it once rather than in every
- program helps everyone.
- </p>
- <p>
- Finally, concurrency aside, garbage collection makes interfaces
- simpler because they don't need to specify how memory is managed across them.
- </p>
- <p>
- This is not to say that the recent work in languages
- like Rust that bring new ideas to the problem of managing
- resources is misguided; we encourage this work and are excited to see
- how it evolves.
- But Go takes a more traditional approach by addressing
- object lifetimes through
- garbage collection, and garbage collection alone.
- </p>
- <p>
- The current implementation is a mark-and-sweep collector.
- If the machine is a multiprocessor, the collector runs on a separate CPU
- core in parallel with the main program.
- Major work on the collector in recent years has reduced pause times
- often to the sub-millisecond range, even for large heaps,
- all but eliminating one of the major objections to garbage collection
- in networked servers.
- Work continues to refine the algorithm, reduce overhead and
- latency further, and to explore new approaches.
- The 2018
- <a href="https://blog.golang.org/ismmkeynote">ISMM keynote</a>
- by Rick Hudson of the Go team
- describes the progress so far and suggests some future approaches.
- </p>
- <p>
- On the topic of performance, keep in mind that Go gives the programmer
- considerable control over memory layout and allocation, much more than
- is typical in garbage-collected languages. A careful programmer can reduce
- the garbage collection overhead dramatically by using the language well;
- see the article about
- <a href="//blog.golang.org/2011/06/profiling-go-programs.html">profiling
- Go programs</a> for a worked example, including a demonstration of Go's
- profiling tools.
- </p>
|