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