effective_go.html 77.5 KB
Newer Older
1
<!-- Effective Go -->
Rob Pike's avatar
Rob Pike committed
2

Russ Cox's avatar
Russ Cox committed
3 4
<h2 id="introduction">Introduction</h2>

Rob Pike's avatar
Rob Pike committed
5
<p>
Rob Pike's avatar
Rob Pike committed
6 7 8
Go is a new language.  Although it borrows ideas from
existing languages,
it has unusual properties that make effective Go programs
Russ Cox's avatar
Russ Cox committed
9
different in character from programs written in its relatives.
10
A straightforward translation of a C++ or Java program into Go
Rob Pike's avatar
Rob Pike committed
11
is unlikely to produce a satisfactory result&mdash;Java programs
12 13 14 15 16 17
are written in Java, not Go.
On the other hand, thinking about the problem from a Go
perspective could produce a successful but quite different
program.
In other words,
to write Go well, it's important to understand its properties
Rob Pike's avatar
Rob Pike committed
18
and idioms.
19 20 21 22
It's also important to know the established conventions for
programming in Go, such as naming, formatting, program
construction, and so on, so that programs you write
will be easy for other Go programmers to understand.
Rob Pike's avatar
Rob Pike committed
23 24
</p>

Russ Cox's avatar
Russ Cox committed
25
<p>
26
This document gives tips for writing clear, idiomatic Go code.
Russ Cox's avatar
Russ Cox committed
27 28
It augments the <a href="go_spec.html">language specification</a>
and the <a href="go_tutorial.html">tutorial</a>, both of which you
Rob Pike's avatar
Rob Pike committed
29
should read first.
Russ Cox's avatar
Russ Cox committed
30 31
</p>

32
<h3 id="read">Examples</h3>
Russ Cox's avatar
Russ Cox committed
33 34

<p>
Rob Pike's avatar
Rob Pike committed
35
The <a href="/src/pkg/">Go package sources</a>
Russ Cox's avatar
Russ Cox committed
36 37
are intended to serve not
only as the core library but also as examples of how to
38 39
use the language.
If you have a question about how to approach a problem or how something
Russ Cox's avatar
Russ Cox committed
40
might be implemented, they can provide answers, ideas and
41
background.
Russ Cox's avatar
Russ Cox committed
42 43 44 45 46 47 48 49
</p>


<h2 id="formatting">Formatting</h2>

<p>
Formatting issues are the most contentious
but the least consequential.
50 51 52 53 54 55
People can adapt to different formatting styles
but it's better if they don't have to, and
less time is devoted to the topic
if everyone adheres to the same style.
The problem is how to approach this Utopia without a long
prescriptive style guide.
Russ Cox's avatar
Russ Cox committed
56 57
</p>

58
<p>
Rob Pike's avatar
Rob Pike committed
59
With Go we take an unusual
60 61 62 63 64 65 66 67 68 69
approach and let the machine
take care of most formatting issues.
A program, <code>gofmt</code>, reads a Go program
and emits the source in a standard style of indentation
and vertical alignment, retaining and if necessary
reformatting comments.
If you want to know how to handle some new layout
situation, run <code>gofmt</code>; if the answer doesn't
seem right, fix the program (or file a bug), don't work around it.
</p>
Russ Cox's avatar
Russ Cox committed
70 71

<p>
72 73 74 75
As an example, there's no need to spend time lining up
the comments on the fields of a structure.
<code>Gofmt</code> will do that for you.  Given the
declaration
Rob Pike's avatar
Rob Pike committed
76 77
</p>

78 79
<pre>
type T struct {
80 81
    name string // name of the object
    value int // its value
82 83
}
</pre>
Rob Pike's avatar
Rob Pike committed
84 85

<p>
Russ Cox's avatar
Russ Cox committed
86
<code>gofmt</code> will line up the columns:
Russ Cox's avatar
Russ Cox committed
87 88
</p>

89 90
<pre>
type T struct {
91 92
    name    string // name of the object
    value   int    // its value
93 94
}
</pre>
Russ Cox's avatar
Russ Cox committed
95 96

<p>
97
All code in the libraries has been formatted with <code>gofmt</code>.
Russ Cox's avatar
Russ Cox committed
98 99 100 101
</p>


<p>
102
Some formatting details remain.  Very briefly,
Russ Cox's avatar
Russ Cox committed
103 104
</p>

105
<dl>
106 107 108 109 110 111 112 113 114 115 116 117 118 119 120
    <dt>Indentation</dt>
    <dd>We use tabs for indentation and <code>gofmt</code> emits them by default.
    Use spaces only if you must.
    </dd>
    <dt>Line length</dt>
    <dd>
    Go has no line length limit.  Don't worry about overflowing a punched card.
    If a line feels too long, wrap it and indent with an extra tab.
    </dd>
    <dt>Parentheses</dt>
    <dd>
    Go needs fewer parentheses: control structures (<code>if</code>,
    <code>for</code>, <code>switch</code>) do not require parentheses in
    their syntax.
    Also, the operator precedence hierarchy is shorter and clearer, so
121 122 123
<pre>
x&lt;&lt;8 + y&lt;&lt;16
</pre>
124 125
    means what the spacing implies.
    </dd>
126
</dl>
Russ Cox's avatar
Russ Cox committed
127

Rob Pike's avatar
Rob Pike committed
128
<h2 id="commentary">Commentary</h2>
Russ Cox's avatar
Russ Cox committed
129 130

<p>
131
Go provides C-style <code>/* */</code> block comments
Russ Cox's avatar
Russ Cox committed
132
and C++-style <code>//</code> line comments.
Rob Pike's avatar
Rob Pike committed
133 134 135
Line comments are the norm;
block comments appear mostly as package comments and
are also useful to disable large swaths of code.
Russ Cox's avatar
Russ Cox committed
136 137
</p>

Rob Pike's avatar
Rob Pike committed
138 139 140 141 142 143 144 145 146
<p>
The program—and web server—<code>godoc</code> processes
Go source files to extract documentation about the contents of the
package.
Comments that appear before top-level declarations, with no intervening newlines,
are extracted along with the declaration to serve as explanatory text for the item.
The nature and style of these comments determines the
quality of the documentation <code>godoc</code> produces.
</p>
Rob Pike's avatar
Rob Pike committed
147 148

<p>
Rob Pike's avatar
Rob Pike committed
149
Every package should have a <i>package comment</i>, a block
Rob Pike's avatar
Rob Pike committed
150
comment preceding the package clause.
Rob Pike's avatar
Rob Pike committed
151 152 153
For multi-file packages, the package comment only needs to be
present in one file, and any one will do.
The package comment should introduce the package and
Rob Pike's avatar
Rob Pike committed
154
provide information relevant to the package as a whole.
Rob Pike's avatar
Rob Pike committed
155 156
It will appear first on the <code>godoc</code> page and
should set up the detailed documentation that follows.
Rob Pike's avatar
Rob Pike committed
157 158 159 160
</p>

<pre>
/*
161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178
    The regexp package implements a simple library for
    regular expressions.

    The syntax of the regular expressions accepted is:

    regexp:
        concatenation { '|' concatenation }
    concatenation:
        { closure }
    closure:
        term [ '*' | '+' | '?' ]
    term:
        '^'
        '$'
        '.'
        character
        '[' [ '^' ] character-ranges ']'
        '(' regexp ')'
Rob Pike's avatar
Rob Pike committed
179 180 181 182 183
*/
package regexp
</pre>

<p>
Rob Pike's avatar
Rob Pike committed
184
If the package is simple, the package comment can be brief.
Rob Pike's avatar
Rob Pike committed
185 186 187 188 189 190 191
</p>

<pre>
// The path package implements utility routines for
// manipulating slash-separated filename paths.
</pre>

Russ Cox's avatar
Russ Cox committed
192
<p>
Rob Pike's avatar
Rob Pike committed
193 194
Comments do not need extra formatting such as banners of stars.
The generated output may not even be presented in a fixed-width font, so don't depend
195
on spacing for alignment&mdash;<code>godoc</code>, like <code>gofmt</code>,
Rob Pike's avatar
Rob Pike committed
196 197 198 199
takes care of that.
Finally, the comments are uninterpreted plain text, so HTML and other
annotations such as <code>_this_</code> will reproduce <i>verbatim</i> and should
not be used.
Russ Cox's avatar
Russ Cox committed
200 201 202
</p>

<p>
Rob Pike's avatar
Rob Pike committed
203 204
Inside a package, any comment immediately preceding a top-level declaration
serves as a <i>doc comment</i> for that declaration.
Russ Cox's avatar
Russ Cox committed
205
Every exported (capitalized) name in a program should
Rob Pike's avatar
Rob Pike committed
206
have a doc comment.
Russ Cox's avatar
Russ Cox committed
207 208 209
</p>

<p>
Rob Pike's avatar
Rob Pike committed
210 211
Doc comments work best as complete English sentences, which allow
a wide variety of automated presentations.
Russ Cox's avatar
Russ Cox committed
212
The first sentence should be a one-sentence summary that
213
starts with the name being declared.
Russ Cox's avatar
Russ Cox committed
214 215 216
</p>

<pre>
Rob Pike's avatar
Rob Pike committed
217 218 219
// Compile parses a regular expression and returns, if successful, a Regexp
// object that can be used to match against text.
func Compile(str string) (regexp *Regexp, error os.Error) {
Russ Cox's avatar
Russ Cox committed
220 221
</pre>

Rob Pike's avatar
Rob Pike committed
222 223
<p>
Go's declaration syntax allows grouping of declarations.
Rob Pike's avatar
Rob Pike committed
224 225
A single doc comment can introduce a group of related constants or variables.
Since the whole declaration is presented, such a comment can often be perfunctory.
Rob Pike's avatar
Rob Pike committed
226 227 228
</p>

<pre>
Rob Pike's avatar
Rob Pike committed
229 230
// Error codes returned by failures to parse an expression.
var (
231 232 233 234
    ErrInternal      = os.NewError("internal error")
    ErrUnmatchedLpar = os.NewError("unmatched '('")
    ErrUnmatchedRpar = os.NewError("unmatched ')'")
    ...
Rob Pike's avatar
Rob Pike committed
235 236 237 238
)
</pre>

<p>
Rob Pike's avatar
Rob Pike committed
239
Even for private names, grouping can also indicate relationships between items,
Russ Cox's avatar
Russ Cox committed
240
such as the fact that a set of variables is protected by a mutex.
Rob Pike's avatar
Rob Pike committed
241 242 243 244
</p>

<pre>
var (
245 246 247 248
    countLock   sync.Mutex
    inputCount  uint32
    outputCount uint32
    errorCount uint32
Rob Pike's avatar
Rob Pike committed
249 250 251
)
</pre>

Russ Cox's avatar
Russ Cox committed
252 253
<h2 id="names">Names</h2>

Rob Pike's avatar
names  
Rob Pike committed
254 255 256 257
<p>
Names are as important in Go as in any other language.
In some cases they even have semantic effect: for instance,
the visibility of a name outside a package is determined by whether its
Rob Pike's avatar
Rob Pike committed
258
first character is upper case.
Rob Pike's avatar
names  
Rob Pike committed
259 260 261 262 263 264
It's therefore worth spending a little time talking about naming conventions
in Go programs.
</p>


<h3 id="package-names">Package names</h3>
Russ Cox's avatar
Russ Cox committed
265 266

<p>
Rob Pike's avatar
names  
Rob Pike committed
267 268
When a package is imported, the package name becomes an accessor for the
contents.  After
Russ Cox's avatar
Russ Cox committed
269 270
</p>

Rob Pike's avatar
names  
Rob Pike committed
271 272 273
<pre>
import "bytes"
</pre>
Russ Cox's avatar
Russ Cox committed
274 275

<p>
Rob Pike's avatar
names  
Rob Pike committed
276 277 278 279 280 281 282 283 284 285 286 287
the importing package can talk about <code>bytes.Buffer</code>.  It's
helpful if everyone using the package can use the same name to refer to
its contents, which implies that the package name should be good:
short, concise, evocative.  By convention, packages are given
lower case, single-word names; there should be no need for underscores
or mixedCaps.
Err on the side of brevity, since everyone using your
package will be typing that name.
And don't worry about collisions <i>a priori</i>.
The package name is only the default name for imports; it need not be unique
across all source code, and in the rare case of a collision the
importing package can choose a different name to use locally.
Rob Pike's avatar
Rob Pike committed
288
In any case, confusion is rare because the file name in the import
Ian Lance Taylor's avatar
Ian Lance Taylor committed
289
determines just which package is being used.
Rob Pike's avatar
names  
Rob Pike committed
290 291 292 293 294 295
</p>

<p>
Another convention is that the package name is the base name of
its source directory;
the package in <code>src/pkg/container/vector</code>
Russ Cox's avatar
Russ Cox committed
296
is imported as <code>"container/vector"</code> but has name <code>vector</code>,
Russ Cox's avatar
Russ Cox committed
297 298 299 300
not <code>container_vector</code> and not <code>containerVector</code>.
</p>

<p>
Rob Pike's avatar
names  
Rob Pike committed
301 302
The importer of a package will use the name to refer to its contents
(the <code>import .</code> notation is intended mostly for tests and other
Russ Cox's avatar
Russ Cox committed
303
unusual situations), so exported names in the package can use that fact
Rob Pike's avatar
names  
Rob Pike committed
304 305 306 307 308 309 310
to avoid stutter.
For instance, the buffered reader type in the <code>bufio</code> package is called <code>Reader</code>,
not <code>BufReader</code>, because users see it as <code>bufio.Reader</code>,
which is a clear, concise name.
Moreover,
because imported entities are always addressed with their package name, <code>bufio.Reader</code>
does not conflict with <code>io.Reader</code>.
311
Similarly, the function to make new instances of <code>ring.Ring</code>&mdash;which
Russ Cox's avatar
Russ Cox committed
312
is the definition of a <em>constructor</em> in Go&mdash;would
313 314 315 316
normally be called <code>NewRing</code>, but since
<code>Ring</code> is the only type exported by the package, and since the
package is called <code>ring</code>, it's called just <code>New</code>.
Clients of the package see that as <code>ring.New</code>.
Rob Pike's avatar
names  
Rob Pike committed
317
Use the package structure to help you choose good names.
Russ Cox's avatar
Russ Cox committed
318 319 320
</p>

<p>
Rob Pike's avatar
names  
Rob Pike committed
321 322 323 324 325 326 327
Another short example is <code>once.Do</code>;
<code>once.Do(setup)</code> reads well and would not be improved by
writing <code>once.DoOrWaitUntilDone(setup)</code>.
Long names don't automatically make things more readable.
If the name represents something intricate or subtle, it's usually better
to write a helpful doc comment than to attempt to put all the information
into the name.
Russ Cox's avatar
Russ Cox committed
328 329
</p>

Rob Pike's avatar
names  
Rob Pike committed
330
<h3 id="interface-names">Interface names</h3>
Russ Cox's avatar
Russ Cox committed
331 332

<p>
Rob Pike's avatar
names  
Rob Pike committed
333
By convention, one-method interfaces are named by
Russ Cox's avatar
Russ Cox committed
334
the method name plus the -er suffix: <code>Reader</code>,
Rob Pike's avatar
names  
Rob Pike committed
335
<code>Writer</code>, <code>Formatter</code> etc.
Russ Cox's avatar
Russ Cox committed
336 337 338
</p>

<p>
Rob Pike's avatar
names  
Rob Pike committed
339 340 341 342
There are a number of such names and it's productive to honor them and the function
names they capture.
<code>Read</code>, <code>Write</code>, <code>Close</code>, <code>Flush</code>,
<code>String</code> and so on have
Russ Cox's avatar
Russ Cox committed
343 344 345 346 347
canonical signatures and meanings.  To avoid confusion,
don't give your method one of those names unless it
has the same signature and meaning.
Conversely, if your type implements a method with the
same meaning as a method on a well-known type,
Rob Pike's avatar
names  
Rob Pike committed
348 349
give it the same name and signature;
call your string-converter method <code>String</code> not <code>ToString</code>.
Russ Cox's avatar
Russ Cox committed
350 351
</p>

Rob Pike's avatar
names  
Rob Pike committed
352 353
<h3 id="mixed-caps">MixedCaps</h3>

Russ Cox's avatar
Russ Cox committed
354
<p>
Rob Pike's avatar
Rob Pike committed
355
Finally, the convention in Go is to use <code>MixedCaps</code>
Rob Pike's avatar
names  
Rob Pike committed
356 357
or <code>mixedCaps</code> rather than underscores to write
multiword names.
Russ Cox's avatar
Russ Cox committed
358 359
</p>

Rob Pike's avatar
Rob Pike committed
360
<h2 id="semicolons">Semicolons</h2>
Rob Pike's avatar
names  
Rob Pike committed
361

Rob Pike's avatar
Rob Pike committed
362
<p>
363 364 365 366
Like C, Go's formal grammar uses semicolons to terminate statements;
unlike C, those semicolons do not appear in the source.
Instead the lexer uses a simple rule to insert semicolons automatically
as it scans, so the input text is mostly free of them.
Rob Pike's avatar
Rob Pike committed
367
</p>
Russ Cox's avatar
Russ Cox committed
368

369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387
<p>
The rule is this. If the last token before a newline is an identifier
(which includes words like <code>int</code> and <code>float64</code>),
a basic literal such as a number or string constant, or one of the
tokens
</p>
<pre>
break continue fallthrough return ++ -- ) }
</pre>
<p>
the lexer always inserts a semicolon after the token.
This could be summarized as, &ldquo;if the newline comes
after a token that could end a statement, add a semicolon&rdquo;.
</p>

<p>
A semicolon can also be omitted immediately before a closing brace,
so a statement such as
</p>
Rob Pike's avatar
Rob Pike committed
388 389 390
<pre>
    go func() { for { dst &lt;- &lt;-src } }()
</pre>
391 392 393 394 395 396 397
<p>
needs no semicolons.
Idiomatic Go programs have semicolons only in places such as
<code>for</code> loop clauses, to separate the initializer, condition, and
continuation elements.  They are also necessary to separate multiple
statements on a line, should you write code that way.
</p>
Russ Cox's avatar
Russ Cox committed
398 399

<p>
400 401 402 403 404
One caveat. You should never put the opening brace of a
control structure (<code>if</code>, <code>for</code>, <code>switch</code>,
or <code>select</code>) on the next line.  If you do, a semicolon
will be inserted before the brace, which could cause unwanted
effects.  Write them like this
Russ Cox's avatar
Russ Cox committed
405 406
</p>

Rob Pike's avatar
Rob Pike committed
407
<pre>
408
if i &lt; f() {
409
    g()
Rob Pike's avatar
Rob Pike committed
410
}
411
</pre>
Rob Pike's avatar
Rob Pike committed
412
<p>
413
not like this
Rob Pike's avatar
Rob Pike committed
414
</p>
415
<pre>
416
if i &lt; f()  // wrong!
417 418 419 420 421
{           // wrong!
    g()
}
</pre>

Rob Pike's avatar
Rob Pike committed
422 423 424 425 426 427 428 429 430 431 432 433 434 435

<h2 id="control-structures">Control structures</h2>

<p>
The control structures of Go are related to those of C but different
in important ways.
There is no <code>do</code> or <code>while</code> loop, only a
slightly generalized
<code>for</code>;
<code>switch</code> is more flexible;
<code>if</code> and <code>switch</code> accept an optional
initialization statement like that of <code>for</code>;
and there are new control structures including a type switch and a
multiway communications multiplexer, <code>select</code>.
Rob Pike's avatar
Rob Pike committed
436 437
The syntax is also slightly different:
parentheses are not required
Rob Pike's avatar
Rob Pike committed
438 439 440 441 442 443 444 445
and the bodies must always be brace-delimited.
</p>

<h3 id="if">If</h3>

<p>
In Go a simple <code>if</code> looks like this:
</p>
446
<pre>
447
if x &gt; 0 {
Rob Pike's avatar
Rob Pike committed
448 449
    return y
}
Rob Pike's avatar
Rob Pike committed
450
</pre>
Russ Cox's avatar
Russ Cox committed
451

Rob Pike's avatar
Rob Pike committed
452 453 454 455 456 457 458 459 460
<p>
Mandatory braces encourage writing simple <code>if</code> statements
on multiple lines.  It's good style to do so anyway,
especially when the body contains a control statement such as a
<code>return</code> or <code>break</code>.
</p>

<p>
Since <code>if</code> and <code>switch</code> accept an initialization
461
statement, it's common to see one used to set up a local variable.
Rob Pike's avatar
Rob Pike committed
462
</p>
Russ Cox's avatar
Russ Cox committed
463 464

<pre>
Rob Pike's avatar
Rob Pike committed
465
if err := file.Chmod(0664); err != nil {
466 467
    log.Stderr(err)
    return err
Rob Pike's avatar
Rob Pike committed
468
}
Russ Cox's avatar
Russ Cox committed
469 470
</pre>

Rob Pike's avatar
Rob Pike committed
471 472 473 474 475 476 477
<p id="else">
In the Go libraries, you'll find that
when an <code>if</code> statement doesn't flow into the next statement—that is,
the body ends in <code>break</code>, <code>continue</code>,
<code>goto</code>, or <code>return</code>—the unnecessary
<code>else</code> is omitted.
</p>
Russ Cox's avatar
Russ Cox committed
478

Rob Pike's avatar
Rob Pike committed
479
<pre>
480
f, err := os.Open(name, os.O_RDONLY, 0)
Rob Pike's avatar
Rob Pike committed
481
if err != nil {
482
    return err
Rob Pike's avatar
Rob Pike committed
483
}
484
codeUsing(f)
Rob Pike's avatar
Rob Pike committed
485
</pre>
Russ Cox's avatar
Russ Cox committed
486 487

<p>
Rob Pike's avatar
Rob Pike committed
488 489 490 491
This is a example of a common situation where code must analyze a
sequence of error possibilities.  The code reads well if the
successful flow of control runs down the page, eliminating error cases
as they arise.  Since error cases tend to end in <code>return</code>
492
statements, the resulting code needs no <code>else</code> statements.
Russ Cox's avatar
Russ Cox committed
493 494 495
</p>

<pre>
496
f, err := os.Open(name, os.O_RDONLY, 0)
Russ Cox's avatar
Russ Cox committed
497
if err != nil {
498
    return err
Russ Cox's avatar
Russ Cox committed
499
}
500
d, err := f.Stat()
Rob Pike's avatar
Rob Pike committed
501
if err != nil {
502
    return err
Rob Pike's avatar
Rob Pike committed
503
}
504
codeUsing(f, d)
Russ Cox's avatar
Russ Cox committed
505 506
</pre>

Rob Pike's avatar
Rob Pike committed
507

Rob Pike's avatar
Rob Pike committed
508 509 510
<h3 id="for">For</h3>

<p>
511
The Go <code>for</code> loop is similar to&mdash;but not the same as&mdash;C's.
Rob Pike's avatar
Rob Pike committed
512 513
It unifies <code>for</code>
and <code>while</code> and there is no <code>do-while</code>.
514
There are three forms, only one of which has semicolons.
Rob Pike's avatar
Rob Pike committed
515 516
</p>
<pre>
Rob Pike's avatar
Rob Pike committed
517
// Like a C for
Rob Pike's avatar
Rob Pike committed
518 519
for init; condition; post { }

Rob Pike's avatar
Rob Pike committed
520
// Like a C while
Rob Pike's avatar
Rob Pike committed
521 522 523 524 525 526 527
for condition { }

// Like a C for(;;)
for { }
</pre>

<p>
528
Short declarations make it easy to declare the index variable right in the loop.
Rob Pike's avatar
Rob Pike committed
529 530
</p>
<pre>
531
sum := 0
532
for i := 0; i &lt; 10; i++ {
Rob Pike's avatar
Rob Pike committed
533 534 535 536 537
    sum += i
}
</pre>

<p>
Rob Pike's avatar
Rob Pike committed
538 539 540
If you're looping over an array, slice, string, or map,
or reading from a channel, a <code>range</code> clause can
manage the loop for you.
Rob Pike's avatar
Rob Pike committed
541 542
</p>
<pre>
543 544
var m map[string]int
sum := 0
Rob Pike's avatar
Rob Pike committed
545
for _, value := range m {  // key is unused
Rob Pike's avatar
Rob Pike committed
546 547 548 549
    sum += value
}
</pre>

Rob Pike's avatar
Rob Pike committed
550
<p>
Rob Pike's avatar
Rob Pike committed
551 552
For strings, the <code>range</code> does more work for you, breaking out individual
Unicode characters by parsing the UTF-8 (erroneous encodings consume one byte and produce the
Rob Pike's avatar
Rob Pike committed
553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568
replacement rune U+FFFD). The loop
</p>
<pre>
for pos, char := range "日本語" {
    fmt.Printf("character %c starts at byte position %d\n", char, pos)
}
</pre>
<p>
prints
</p>
<pre>
character 日 starts at byte position 0
character 本 starts at byte position 3
character 語 starts at byte position 6
</pre>

Rob Pike's avatar
Rob Pike committed
569 570 571
<p>
Finally, since Go has no comma operator and <code>++</code> and <code>--</code>
are statements not expressions, if you want to run multiple variables in a <code>for</code>
572
you should use parallel assignment.
Rob Pike's avatar
Rob Pike committed
573 574 575
</p>
<pre>
// Reverse a
576
for i, j := 0, len(a)-1; i &lt; j; i, j = i+1, j-1 {
577
    a[i], a[j] = a[j], a[i]
Rob Pike's avatar
Rob Pike committed
578 579 580
}
</pre>

Russ Cox's avatar
Russ Cox committed
581 582 583
<h3 id="switch">Switch</h3>

<p>
Rob Pike's avatar
Rob Pike committed
584
Go's <code>switch</code> is more general than C's.
Rob Pike's avatar
Rob Pike committed
585 586 587 588
The expressions need not be constants or even integers,
the cases are evaluated top to bottom until a match is found,
and if the <code>switch</code> has no expression it switches on
<code>true</code>.
589
It's therefore possible&mdash;and idiomatic&mdash;to write an
Rob Pike's avatar
Rob Pike committed
590
<code>if</code>-<code>else</code>-<code>if</code>-<code>else</code>
591
chain as a <code>switch</code>.
Russ Cox's avatar
Russ Cox committed
592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607
</p>

<pre>
func unhex(c byte) byte {
    switch {
    case '0' &lt;= c &amp;&amp; c &lt;= '9':
        return c - '0'
    case 'a' &lt;= c &amp;&amp; c &lt;= 'f':
        return c - 'a' + 10
    case 'A' &lt;= c &amp;&amp; c &lt;= 'F':
        return c - 'A' + 10
    }
    return 0
}
</pre>

Rob Pike's avatar
Rob Pike committed
608 609
<p>
There is no automatic fall through, but cases can be presented
610
in comma-separated lists.
Russ Cox's avatar
Russ Cox committed
611 612 613
<pre>
func shouldEscape(c byte) bool {
    switch c {
Rob Pike's avatar
Rob Pike committed
614
    case ' ', '?', '&amp;', '=', '#', '+', '%':
Russ Cox's avatar
Russ Cox committed
615 616 617 618 619 620
        return true
    }
    return false
}
</pre>

Rob Pike's avatar
Rob Pike committed
621 622 623
<p>
Here's a comparison routine for byte arrays that uses two
<code>switch</code> statements:
Rob Pike's avatar
Rob Pike committed
624
<pre>
Rob Pike's avatar
Rob Pike committed
625 626
// Compare returns an integer comparing the two byte arrays
// lexicographically.
Rob Pike's avatar
Rob Pike committed
627
// The result will be 0 if a == b, -1 if a &lt; b, and +1 if a &gt; b
Rob Pike's avatar
Rob Pike committed
628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646
func Compare(a, b []byte) int {
    for i := 0; i &lt; len(a) &amp;&amp; i &lt; len(b); i++ {
        switch {
        case a[i] &gt; b[i]:
            return 1
        case a[i] &lt; b[i]:
            return -1
        }
    }
    switch {
    case len(a) &lt; len(b):
        return -1
    case len(a) &gt; len(b):
        return 1
    }
    return 0
}
</pre>

Rob Pike's avatar
Rob Pike committed
647 648 649 650 651 652 653 654 655 656
<p>
A switch can also be used to discover the dynamic type of an interface
variable.  Such a <em>type switch</em> uses the syntax of a type
assertion with the keyword <code>type</code> inside the parentheses.
If the switch declares a variable in the expression, the variable will
have the corresponding type in each clause.
</p>
<pre>
switch t := interfaceValue.(type) {
default:
657
    fmt.Printf("unexpected type %T", t)  // %T prints type
Rob Pike's avatar
Rob Pike committed
658
case bool:
659
    fmt.Printf("boolean %t\n", t)
Rob Pike's avatar
Rob Pike committed
660
case int:
661
    fmt.Printf("integer %d\n", t)
Rob Pike's avatar
Rob Pike committed
662
case *bool:
663
    fmt.Printf("pointer to boolean %t\n", *t)
Rob Pike's avatar
Rob Pike committed
664
case *int:
665
    fmt.Printf("pointer to integer %d\n", *t)
Rob Pike's avatar
Rob Pike committed
666 667 668
}
</pre>

Russ Cox's avatar
Russ Cox committed
669 670
<h2 id="functions">Functions</h2>

Rob Pike's avatar
Rob Pike committed
671 672 673
<h3 id="multiple-returns">Multiple return values</h3>

<p>
Ian Lance Taylor's avatar
Ian Lance Taylor committed
674 675
One of Go's unusual features is that functions and methods
can return multiple values.  This can be used to
Rob Pike's avatar
Rob Pike committed
676
improve on a couple of clumsy idioms in C programs: in-band
Rob Pike's avatar
Rob Pike committed
677
error returns (such as <code>-1</code> for <code>EOF</code>)
Rob Pike's avatar
Rob Pike committed
678 679 680 681
and modifying an argument.
</p>

<p>
Russ Cox's avatar
Russ Cox committed
682
In C, a write error is signaled by a negative count with the
Rob Pike's avatar
Rob Pike committed
683 684
error code secreted away in a volatile location.
In Go, <code>Write</code>
Russ Cox's avatar
Russ Cox committed
685 686
can return a count <i>and</i> an error: &ldquo;Yes, you wrote some
bytes but not all of them because you filled the device&rdquo;.
Rob Pike's avatar
Rob Pike committed
687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702
The signature of <code>*File.Write</code> in package <code>os</code> is:
</p>

<pre>
func (file *File) Write(b []byte) (n int, err Error)
</pre>

<p>
and as the documentation says, it returns the number of bytes
written and a non-nil <code>Error</code> when <code>n</code>
<code>!=</code> <code>len(b)</code>.
This is a common style; see the section on error handling for more examples.
</p>

<p>
A similar approach obviates the need to pass a pointer to a return
Rob Pike's avatar
Rob Pike committed
703 704
value to simulate a reference parameter.
Here's a simple-minded function to
Rob Pike's avatar
Rob Pike committed
705 706 707 708 709 710
grab a number from a position in a byte array, returning the number
and the next position.
</p>

<pre>
func nextInt(b []byte, i int) (int, int) {
711
    for ; i &lt; len(b) &amp;&amp; !isDigit(b[i]); i++ {
712 713
    }
    x := 0
714
    for ; i &lt; len(b) &amp;&amp; isDigit(b[i]); i++ {
715 716 717
        x = x*10 + int(b[i])-'0'
    }
    return x, i
Rob Pike's avatar
Rob Pike committed
718 719 720 721 722 723 724 725
}
</pre>

<p>
You could use it to scan the numbers in an input array <code>a</code> like this:
</p>

<pre>
726
    for i := 0; i &lt; len(a); {
727 728 729
        x, i = nextInt(a, i)
        fmt.Println(x)
    }
Rob Pike's avatar
Rob Pike committed
730 731 732
</pre>

<h3 id="named-results">Named result parameters</h3>
Russ Cox's avatar
Russ Cox committed
733 734

<p>
Rob Pike's avatar
Rob Pike committed
735 736
The return or result "parameters" of a Go function can be given names and
used as regular variables, just like the incoming parameters.
Rob Pike's avatar
Rob Pike committed
737
When named, they are initialized to the zero values for their types when
Rob Pike's avatar
Rob Pike committed
738
the function begins; if the function executes a <code>return</code> statement
739
with no arguments, the current values of the result parameters are
Rob Pike's avatar
Rob Pike committed
740
used as the returned values.
Russ Cox's avatar
Russ Cox committed
741 742
</p>

Rob Pike's avatar
Rob Pike committed
743 744 745 746 747 748 749 750 751 752 753
<p>
The names are not mandatory but they can make code shorter and clearer:
they're documentation.
If we name the results of <code>nextInt</code> it becomes
obvious which returned <code>int</code>
is which.
</p>

<pre>
func nextInt(b []byte, pos int) (value, nextPos int) {
</pre>
Russ Cox's avatar
Russ Cox committed
754 755

<p>
Rob Pike's avatar
Rob Pike committed
756 757 758
Because named results are initialized and tied to an unadorned return, they can simplify
as well as clarify.  Here's a version
of <code>io.ReadFull</code> that uses them well:
Russ Cox's avatar
Russ Cox committed
759 760
</p>

Rob Pike's avatar
Rob Pike committed
761 762
<pre>
func ReadFull(r Reader, buf []byte) (n int, err os.Error) {
763
    for len(buf) &gt; 0 &amp;&amp; err == nil {
764 765 766 767 768 769
        var nr int
        nr, err = r.Read(buf)
        n += nr
        buf = buf[nr:len(buf)]
    }
    return
Rob Pike's avatar
Rob Pike committed
770 771 772
}
</pre>

773
<h2 id="data">Data</h2>
Rob Pike's avatar
Rob Pike committed
774

775
<h3 id="allocation_new">Allocation with <code>new()</code></h3>
Rob Pike's avatar
Rob Pike committed
776

777 778 779 780 781 782
<p>
Go has two allocation primitives, <code>new()</code> and <code>make()</code>.
They do different things and apply to different types, which can be confusing,
but the rules are simple.
Let's talk about <code>new()</code> first.
It's a built-in function essentially the same as its namesakes
Russ Cox's avatar
Russ Cox committed
783
in other languages: <code>new(T)</code> allocates zeroed storage for a new item of type
784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802
<code>T</code> and returns its address, a value of type <code>*T</code>.
In Go terminology, it returns a pointer to a newly allocated zero value of type
<code>T</code>.
</p>

<p>
Since the memory returned by <code>new()</code> is zeroed, it's helpful to arrange that the
zeroed object can be used without further initialization.  This means a user of
the data structure can create one with <code>new()</code> and get right to
work.
For example, the documentation for <code>bytes.Buffer</code> states that
"the zero value for <code>Buffer</code> is an empty buffer ready to use."
Similarly, <code>sync.Mutex</code> does not
have an explicit constructor or <code>Init</code> method.
Instead, the zero value for a <code>sync.Mutex</code>
is defined to be an unlocked mutex.
</p>

<p>
803
The zero-value-is-useful property works transitively. Consider this type declaration.
804 805 806 807
</p>

<pre>
type SyncedBuffer struct {
808 809
    lock    sync.Mutex
    buffer  bytes.Buffer
810 811 812 813 814 815
}
</pre>

<p>
Values of type <code>SyncedBuffer</code> are also ready to use immediately upon allocation
or just declaration.  In this snippet, both <code>p</code> and <code>v</code> will work
816
correctly without further arrangement.
817 818 819
</p>

<pre>
820 821
p := new(SyncedBuffer)  // type *SyncedBuffer
var v SyncedBuffer      // type  SyncedBuffer
822 823 824 825 826 827 828
</pre>

<h3 id="composite_literals">Constructors and composite literals</h3>

<p>
Sometimes the zero value isn't good enough and an initializing
constructor is necessary, as in this example derived from
829
package <code>os</code>.
830 831 832 833
</p>

<pre>
func NewFile(fd int, name string) *File {
834 835 836 837 838 839 840 841 842
    if fd &lt; 0 {
        return nil
    }
    f := new(File)
    f.fd = fd
    f.name = name
    f.dirinfo = nil
    f.nepipe = 0
    return f
843 844 845 846
}
</pre>

<p>
847
There's a lot of boiler plate in there.  We can simplify it
848 849 850 851 852 853 854 855
using a <i>composite literal</i>, which is
an expression that creates a
new instance each time it is evaluated.
</p>


<pre>
func NewFile(fd int, name string) *File {
856 857 858 859 860
    if fd &lt; 0 {
        return nil
    }
    f := File{fd, name, nil, 0}
    return &amp;f
861 862 863 864 865 866 867
}
</pre>

<p>
Note that it's perfectly OK to return the address of a local variable;
the storage associated with the variable survives after the function
returns.
Rob Pike's avatar
Rob Pike committed
868 869
In fact, taking the address of a composite literal
allocates a fresh instance each time it is evaluated,
870
so we can combine these last two lines.
871 872 873
</p>

<pre>
874
    return &amp;File{fd, name, nil, 0}
875 876 877 878 879 880 881 882 883 884
</pre>

<p>
The fields of a composite literal are laid out in order and must all be present.
However, by labeling the elements explicitly as <i>field</i><code>:</code><i>value</i>
pairs, the initializers can appear in any
order, with the missing ones left as their respective zero values.  Thus we could say
</p>

<pre>
885
    return &amp;File{fd: fd, name: name}
886 887 888 889
</pre>

<p>
As a limiting case, if a composite literal contains no fields at all, it creates
Russ Cox's avatar
Russ Cox committed
890
a zero value for the type.  The expressions <code>new(File)</code> and <code>&amp;File{}</code> are equivalent.
891 892 893 894 895
</p>

<p>
Composite literals can also be created for arrays, slices, and maps,
with the field labels being indices or map keys as appropriate.
Russ Cox's avatar
Russ Cox committed
896
In these examples, the initializations work regardless of the values of <code>Enone</code>,
897
<code>Eio</code>, and <code>Einval</code>, as long as they are distinct.
898
</p>
Rob Pike's avatar
Rob Pike committed
899

900
<pre>
901 902 903
a := [...]string   {Enone: "no error", Eio: "Eio", Einval: "invalid argument"}
s := []string      {Enone: "no error", Eio: "Eio", Einval: "invalid argument"}
m := map[int]string{Enone: "no error", Eio: "Eio", Einval: "invalid argument"}
904 905 906
</pre>

<h3 id="allocation_make">Allocation with <code>make()</code></h3>
Rob Pike's avatar
Rob Pike committed
907 908

<p>
909 910 911 912 913 914 915 916 917 918 919
Back to allocation.
The built-in function <code>make(T, </code><i>args</i><code>)</code> serves
a purpose different from <code>new(T)</code>.
It creates slices, maps, and channels only, and it returns an initialized (not zero)
value of type <code>T</code>, not <code>*T</code>.
The reason for the distinction
is that these three types are, under the covers, references to data structures that
must be initialized before use.
A slice, for example, is a three-item descriptor
containing a pointer to the data (inside an array), the length, and the
capacity; until those items are initialized, the slice is <code>nil</code>.
920
For slices, maps, and channels,
921 922 923
<code>make</code> initializes the internal data structure and prepares
the value for use.
For instance,
Rob Pike's avatar
Rob Pike committed
924 925 926
</p>

<pre>
927
make([]int, 10, 100)
Rob Pike's avatar
Rob Pike committed
928 929
</pre>

930 931 932 933 934 935 936 937 938 939 940
<p>
allocates an array of 100 ints and then creates a slice
structure with length 10 and a capacity of 100 pointing at the first
10 elements of the array.
(When making a slice, the capacity can be omitted; see the section on slices
for more information.)
In contrast, <code>new([]int)</code> returns a pointer to a newly allocated, zeroed slice
structure, that is, a pointer to a <code>nil</code> slice value.

<p>
These examples illustrate the difference between <code>new()</code> and
941
<code>make()</code>.
942 943 944
</p>

<pre>
945
var p *[]int = new([]int)       // allocates slice structure; *p == nil; rarely useful
946
var v  []int = make([]int, 100) // the slice v now refers to a new array of 100 ints
947 948

// Unnecessarily complex:
949 950
var p *[]int = new([]int)
*p = make([]int, 100, 100)
951 952

// Idiomatic:
953
v := make([]int, 100)
954 955 956
</pre>

<p>
Russ Cox's avatar
Russ Cox committed
957 958
Remember that <code>make()</code> applies only to maps, slices and channels
and does not return a pointer.
959 960 961 962 963 964 965
To obtain an explicit pointer allocate with <code>new()</code>.
</p>

<h3 id="arrays">Arrays</h3>

<p>
Arrays are useful when planning the detailed layout of memory and sometimes
Russ Cox's avatar
Russ Cox committed
966
can help avoid allocation, but primarily
967 968 969 970 971 972
they are a building block for slices, the subject of the next section.
To lay the foundation for that topic, here are a few words about arrays.
</p>

<p>
There are major differences between the ways arrays work in Go and C.
973
In Go,
974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989
</p>
<ul>
<li>
Arrays are values. Assigning one array to another copies all the elements.
</li>
<li>
In particular, if you pass an array to a function, it
will receive a <i>copy</i> of the array, not a pointer to it.
<li>
The size of an array is part of its type.  The types <code>[10]int</code>
and <code>[20]int</code> are distinct.
</li>
</ul>

<p>
The value property can be useful but also expensive; if you want C-like behavior and efficiency,
990
you can pass a pointer to the array.
991 992
</p>

Rob Pike's avatar
Rob Pike committed
993
<pre>
Russ Cox's avatar
Russ Cox committed
994
func Sum(a *[3]float) (sum float) {
995 996 997 998
    for _, v := range *a {
        sum += v
    }
    return
999 1000
}

1001 1002
array := [...]float{7.0, 8.5, 9.1}
x := Sum(&amp;array)  // Note the explicit address-of operator
Rob Pike's avatar
Rob Pike committed
1003 1004
</pre>

1005 1006 1007 1008 1009 1010 1011
<p>
But even this style isn't idiomatic Go.  Slices are.
</p>

<h3 id="slices">Slices</h3>

<p>
Rob Pike's avatar
Rob Pike committed
1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022
Slices wrap arrays to give a more general, powerful, and convenient
interface to sequences of data.  Except for items with explicit
dimension such as transformation matrices, most array programming in
Go is done with slices rather than simple arrays.
</p>
<p>
Slices are <i>reference types</i>, which means that if you assign one
slice to another, both refer to the same underlying array.  For
instance, if a function takes a slice argument, changes it makes to
the elements of the slice will be visible to the caller, analogous to
passing a pointer to the underlying array.  A <code>Read</code>
Russ Cox's avatar
Russ Cox committed
1023 1024
function can therefore accept a slice argument rather than a pointer
and a count; the length within the slice sets an upper
Rob Pike's avatar
Rob Pike committed
1025 1026 1027 1028 1029 1030 1031 1032 1033 1034
limit of how much data to read.  Here is the signature of the
<code>Read</code> method of the <code>File</code> type in package
<code>os</code>:
</p>
<pre>
func (file *File) Read(buf []byte) (n int, err os.Error)
</pre>
<p>
The method returns the number of bytes read and an error value, if
any.  To read into the first 32 bytes of a larger buffer
1035
<code>b</code>, <i>slice</i> (here used as a verb) the buffer.
Rob Pike's avatar
Rob Pike committed
1036 1037
</p>
<pre>
1038
    n, err := f.Read(buf[0:32])
Rob Pike's avatar
Rob Pike committed
1039 1040 1041
</pre>
<p>
Such slicing is common and efficient.  In fact, leaving efficiency aside for
1042
the moment, this snippet would also read the first 32 bytes of the buffer.
Rob Pike's avatar
Rob Pike committed
1043 1044
</p>
<pre>
1045 1046
    var n int
    var err os.Error
1047
    for i := 0; i &lt; 32; i++ {
1048 1049 1050 1051 1052 1053 1054
        nbytes, e := f.Read(buf[i:i+1])  // Read one byte.
        if nbytes == 0 || e != nil {
            err = e
            break
        }
        n += nbytes
    }
Rob Pike's avatar
Rob Pike committed
1055 1056 1057
</pre>
<p>
The length of a slice may be changed as long as it still fits within
1058
the limits of the underlying array; just assign it to a slice of
Rob Pike's avatar
Rob Pike committed
1059 1060 1061 1062 1063 1064 1065 1066 1067 1068
itself.  The <i>capacity</i> of a slice, accessible by the built-in
function <code>cap</code>, reports the maximum length the slice may
assume.  Here is a function to append data to a slice.  If the data
exceeds the capacity, the slice is reallocated.  The
resulting slice is returned.  The function uses the fact that
<code>len</code> and <code>cap</code> are legal when applied to the
<code>nil</code> slice, and return 0.
</p>
<pre>
func Append(slice, data[]byte) []byte {
1069
    l := len(slice)
1070
    if l + len(data) &gt; cap(slice) {  // reallocate
1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083
        // Allocate double what's needed, for future growth.
        newSlice := make([]byte, (l+len(data))*2)
        // Copy data (could use bytes.Copy()).
        for i, c := range slice {
            newSlice[i] = c
        }
        slice = newSlice
    }
    slice = slice[0:l+len(data)]
    for i, c := range data {
        slice[l+i] = c
    }
    return slice
Rob Pike's avatar
Rob Pike committed
1084 1085 1086 1087 1088 1089
}
</pre>
<p>
We must return the slice afterwards because, although <code>Append</code>
can modify the elements of <code>slice</code>, the slice itself (the run-time data
structure holding the pointer, length, and capacity) is passed by value.
1090 1091 1092 1093
</p>


<h3 id="maps">Maps</h3>
Rob Pike's avatar
Rob Pike committed
1094 1095 1096 1097

<p>
Maps are a convenient and powerful built-in data structure to associate
values of different types.
Russ Cox's avatar
Russ Cox committed
1098 1099
The key can be of any type for which the equality operator is defined,
such as integers,
Rob Pike's avatar
Rob Pike committed
1100
floats, strings, pointers, and interfaces (as long as the dynamic type
Russ Cox's avatar
Russ Cox committed
1101 1102
supports equality).  Structs, arrays and slices cannot be used as map keys,
because equality is not defined on those types.
Rob Pike's avatar
Rob Pike committed
1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113
Like slices, maps are a reference type. If you pass a map to a function
that changes the contents of the map, the changes will be visible
in the caller.
</p>
<p>
Maps can be constructed using the usual composite literal syntax
with colon-separated key-value pairs,
so it's easy to build them during initialization.
</p>
<pre>
var timeZone = map[string] int {
1114 1115 1116 1117 1118
    "UTC":  0*60*60,
    "EST": -5*60*60,
    "CST": -6*60*60,
    "MST": -7*60*60,
    "PST": -8*60*60,
Rob Pike's avatar
Rob Pike committed
1119 1120 1121 1122 1123 1124 1125 1126 1127 1128
}
</pre>
<p>
Assigning and fetching map values looks syntactically just like
doing the same for arrays except that the index doesn't need to
be an integer.  An attempt to fetch a map value with a key that
is not present in the map will cause the program to crash, but
there is a way to do so safely using a multiple assignment.
</p>
<pre>
1129 1130
var seconds int
var ok bool
Rob Pike's avatar
Rob Pike committed
1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142
seconds, ok = timeZone[tz]
</pre>
<p>
For obvious reasons this is called the &ldquo;comma ok&rdquo; idiom.
In this example, if <code>tz</code> is present, <code>seconds</code>
will be set appropriately and <code>ok</code> will be true; if not,
<code>seconds</code> will be set to zero and <code>ok</code> will
be false.
Here's a function that puts it together:
</p>
<pre>
func offset(tz string) int {
1143 1144 1145 1146 1147
    if seconds, ok := timeZone[tz]; ok {
        return seconds
    }
    log.Stderr("unknown time zone", tz)
    return 0
Rob Pike's avatar
Rob Pike committed
1148 1149 1150 1151 1152 1153 1154 1155 1156 1157
}
</pre>
<p>
To test for presence in the map without worrying about the actual value,
you can use the <em>blank identifier</em>, a simple underscore (<code>_</code>).
The blank identifier can be assigned or declared with any value of any type, with the
value discarded harmlessly.  For testing presence in a map, use the blank
identifier in place of the usual variable for the value.
</p>
<pre>
1158
_, present := timeZone[tz]
Rob Pike's avatar
Rob Pike committed
1159 1160 1161 1162 1163 1164 1165 1166
</pre>
<p>
To delete a map entry, turn the multiple assignment around by placing
an extra boolean on the right; if the boolean is false, the entry
is deleted. It's safe to do this even if the key is already absent
from the map.
</p>
<pre>
1167
timeZone["PDT"] = 0, false  // Now on Standard Time
Rob Pike's avatar
Rob Pike committed
1168
</pre>
1169 1170
<h3 id="printing">Printing</h3>

Rob Pike's avatar
Rob Pike committed
1171 1172 1173 1174 1175 1176 1177 1178 1179
<p>
Formatted printing in Go uses a style similar to C's <code>printf</code>
family but is richer and more general. The functions live in the <code>fmt</code>
package and have capitalized names: <code>fmt.Printf</code>, <code>fmt.Fprintf</code>,
<code>fmt.Sprintf</code> and so on.  The string functions (<code>Sprintf</code> etc.)
return a string rather than filling in a provided buffer.
</p>
<p>
You don't need to provide a format string.  For each of <code>Printf</code>,
Ian Lance Taylor's avatar
Ian Lance Taylor committed
1180
<code>Fprintf</code> and <code>Sprintf</code> there is another pair
Rob Pike's avatar
Rob Pike committed
1181 1182 1183 1184 1185 1186 1187
of functions, for instance <code>Print</code> and <code>Println</code>.
These functions do not take a format string but instead generate a default
format for each argument. The <code>ln</code> version also inserts a blank
between arguments if neither is a string and appends a newline to the output.
In this example each line produces the same output.
</p>
<pre>
1188 1189 1190
fmt.Printf("Hello %d\n", 23)
fmt.Fprint(os.Stdout, "Hello ", 23, "\n")
fmt.Println(fmt.Sprint("Hello ", 23))
Rob Pike's avatar
Rob Pike committed
1191 1192
</pre>
<p>
Ian Lance Taylor's avatar
Ian Lance Taylor committed
1193 1194 1195
As mentioned in
the <a href="go_tutorial.html">tutorial</a>, <code>fmt.Fprint</code>
and friends take as a first argument any object
Rob Pike's avatar
Rob Pike committed
1196 1197 1198 1199 1200 1201 1202 1203 1204
that implements the <code>io.Writer</code> interface; the variables <code>os.Stdout</code>
and <code>os.Stderr</code> are familiar instances.
</p>
<p>
Here things start to diverge from C.  First, the numeric formats such as <code>%d</code>
do not take flags for signedness or size; instead, the printing routines use the
type of the argument to decide these properties.
</p>
<pre>
1205
var x uint64 = 1&lt;&lt;64 - 1
1206
fmt.Printf("%d %x; %d %x\n", x, x, int64(x), int64(x))
Rob Pike's avatar
Rob Pike committed
1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221
</pre>
<p>
prints
</p>
<pre>
18446744073709551615 ffffffffffffffff; -1 -1
</pre>
<p>
If you just want the default conversion, such as decimal for integers, you can use
the catchall format <code>%v</code> (for &ldquo;value&rdquo;); the result is exactly
what <code>Print</code> and <code>Println</code> would produce.
Moreover, that format can print <em>any</em> value, even arrays, structs, and
maps.  Here is a print statement for the time zone map defined in the previous section.
</p>
<pre>
1222
fmt.Printf("%v\n", timeZone)  // or just fmt.Println(timeZone)
Rob Pike's avatar
Rob Pike committed
1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237
</pre>
<p>
which gives output
</p>
<pre>
map[CST:-21600 PST:-28800 EST:-18000 UTC:0 MST:-25200]
</pre>
<p>
For maps the keys may be output in any order, of course.
When printing a struct, the modified format <code>%+v</code> annotates the
fields of the structure with their names, and for any value the alternate
format <code>%#v</code> prints the value in full Go syntax.
</p>
<pre>
type T struct {
1238 1239 1240
    a int
    b float
    c string
Rob Pike's avatar
Rob Pike committed
1241
}
1242 1243 1244 1245 1246
t := &amp;T{ 7, -2.35, "abc\tdef" }
fmt.Printf("%v\n", t)
fmt.Printf("%+v\n", t)
fmt.Printf("%#v\n", t)
fmt.Printf("%#v\n", timeZone)
Rob Pike's avatar
Rob Pike committed
1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268
</pre>
<p>
prints
</p>
<pre>
&amp;{7 -2.35 abc   def}
&amp;{a:7 b:-2.35 c:abc     def}
&amp;main.T{a:7, b:-2.35, c:"abc\tdef"}
map[string] int{"CST":-21600, "PST":-28800, "EST":-18000, "UTC":0, "MST":-25200}
</pre>
<p>
(Note the ampersands.)
That quoted string format is also available through <code>%q</code> when
applied to a value of type <code>string</code> or <code>[]byte</code>;
the alternate format <code>%#q</code> will use backquotes instead if possible.
Also, <code>%x</code> works on strings and arrays of bytes as well as on integers,
generating a long hexadecimal string, and with
a space in the format (<code>%&nbsp;x</code>) it puts spaces between the bytes.
</p>
<p>
Another handy format is <code>%T</code>, which prints the <em>type</em> of a value.
<pre>
1269
fmt.Printf(&quot;%T\n&quot;, timeZone)
Rob Pike's avatar
Rob Pike committed
1270 1271 1272 1273 1274 1275 1276 1277 1278
</pre>
<p>
prints
</p>
<pre>
map[string] int
</pre>
<p>
If you want to control the default format for a custom type, all that's required is to define
1279 1280
a method <code>String() string</code> on the type.
For our simple type <code>T</code>, that might look like this.
Rob Pike's avatar
Rob Pike committed
1281 1282 1283
</p>
<pre>
func (t *T) String() string {
1284
    return fmt.Sprintf("%d/%g/%q", t.a, t.b, t.c)
Rob Pike's avatar
Rob Pike committed
1285
}
1286
fmt.Printf("%v\n", t)
Rob Pike's avatar
Rob Pike committed
1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313
</pre>
<p>
to print in the format
</p>
<pre>
7/-2.35/"abc\tdef"
</pre>
<p>
Our <code>String()</code> method is able to call <code>Sprintf</code> because the
print routines are fully reentrant and can be used recursively.
We can even go one step further and pass a print routine's arguments directly to another such routine.
The signature of <code>Printf</code> uses the <code>...</code>
type for its final argument to specify that an arbitrary number of parameters can appear
after the format.
</p>
<pre>
func Printf(format string, v ...) (n int, errno os.Error) {
</pre>
<p>
Within the function <code>Printf</code>, <code>v</code> is a variable that can be passed,
for instance, to another print routine.  Here is the implementation of the
function <code>log.Stderr</code> we used above. It passes its arguments directly to
<code>fmt.Sprintln</code> for the actual formatting.
</p>
<pre>
// Stderr is a helper function for easy logging to stderr. It is analogous to Fprint(os.Stderr).
func Stderr(v ...) {
1314
    stderr.Output(2, fmt.Sprintln(v))  // Output takes parameters (int, string)
Rob Pike's avatar
Rob Pike committed
1315 1316 1317 1318 1319 1320 1321
}
</pre>
<p>
There's even more to printing than we've covered here.  See the <code>godoc</code> documentation
for package <code>fmt</code> for the details.
</p>

Rob Pike's avatar
Rob Pike committed
1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352
<h2 id="initialization">Initialization</h2>

<p>
Although it doesn't look superficially very different from
initialization in C or C++, initialization in Go is more powerful.
Complex structures can be built during initialization and the ordering
issues between initialized objects in different packages are handled
correctly.
</p>

<h3 id="constants">Constants</h3>

<p>
Constants in Go are just that&mdash;constant.
They are created at compile time, even when defined as
locals in functions,
and can only be numbers, strings or booleans.
Because of the compile-time restriction, the expressions
that define them must be constant expressions,
evaluatable by the compiler.  For instance,
<code>1&lt;&lt;3</code> is a constant expression, while
<code>math.Sin(math.Pi/4)</code> is not because
the function call to <code>math.Sin</code> needs
to happen at run time.
</p>

<p>
In Go, enumerated constants are created using the <code>iota</code>
enumerator.  Since <code>iota</code> can be part of an expression and
expressions can be implicitly repeated, it is easy to build intricate
sets of values.
Rob Pike's avatar
Rob Pike committed
1353
</p>
Rob Pike's avatar
Rob Pike committed
1354 1355 1356
<pre>
type ByteSize float64
const (
1357
    _ = iota  // ignore first value by assigning to blank identifier
1358
    KB ByteSize = 1&lt;&lt;(10*iota)
1359 1360 1361 1362
    MB
    GB
    TB
    PB
1363 1364
    EB
    ZB
1365
    YB
Rob Pike's avatar
Rob Pike committed
1366 1367 1368 1369 1370 1371 1372 1373 1374
)
</pre>
<p>
The ability to attach a method such as <code>String</code> to a
type makes it possible for such values to format themselves
automatically for printing, even as part of a general type.
</p>
<pre>
func (b ByteSize) String() string {
1375
    switch {
1376
    case b &gt;= YB:
1377
        return fmt.Sprintf("%.2fYB", b/YB)
1378 1379 1380 1381
    case b &gt;= ZB:
        return fmt.Sprintf("%.2fZB", b/ZB)
    case b &gt;= EB:
        return fmt.Sprintf("%.2fEB", b/EB)
1382
    case b &gt;= PB:
1383
        return fmt.Sprintf("%.2fPB", b/PB)
1384
    case b &gt;= TB:
1385
        return fmt.Sprintf("%.2fTB", b/TB)
1386
    case b &gt;= GB:
1387
        return fmt.Sprintf("%.2fGB", b/GB)
1388
    case b &gt;= MB:
1389
        return fmt.Sprintf("%.2fMB", b/MB)
1390
    case b &gt;= KB:
1391 1392 1393
        return fmt.Sprintf("%.2fKB", b/KB)
    }
    return fmt.Sprintf("%.2fB", b)
Rob Pike's avatar
Rob Pike committed
1394 1395 1396 1397
}
</pre>
<p>
The expression <code>YB</code> prints as <code>1.00YB</code>,
1398
while <code>ByteSize(1e13)</code> prints as <code>9.09TB</code>.
Rob Pike's avatar
Rob Pike committed
1399 1400 1401 1402 1403 1404 1405 1406 1407 1408
</p>

<h3 id="variables">Variables</h3>

<p>
Variables can be initialized just like constants but the
initializer can be a general expression computed at run time.
</p>
<pre>
var (
1409 1410 1411
    HOME = os.Getenv("HOME")
    USER = os.Getenv("USER")
    GOROOT = os.Getenv("GOROOT")
Rob Pike's avatar
Rob Pike committed
1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435
)
</pre>

<h3 id="init">The init function</h3>

<p>
Finally, each source file can define its own <code>init()</code> function to
set up whatever state is required.  The only restriction is that, although
goroutines can be launched during initialization, they will not begin
execution until it completes; initialization always runs as a single thread
of execution.
And finally means finally: <code>init()</code> is called after all the
variable declarations in the package have evaluated their initializers,
and those are evaluated only after all the imported packages have been
initialized.
</p>
<p>
Besides initializations that cannot be expressed as declarations,
a common use of <code>init()</code> functions is to verify or repair
correctness of the program state before real execution begins.
</p>

<pre>
func init() {
1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446
    if USER == "" {
        log.Exit("$USER not set")
    }
    if HOME == "" {
        HOME = "/usr/" + USER
    }
    if GOROOT == "" {
        GOROOT = HOME + "/go"
    }
    // GOROOT may be overridden by --goroot flag on command line.
    flag.StringVar(&amp;GOROOT, "goroot", GOROOT, "Go root directory")
Rob Pike's avatar
Rob Pike committed
1447 1448 1449 1450
}
</pre>

<h2 id="methods">Methods</h2>
Rob Pike's avatar
Rob Pike committed
1451

1452
<h3 id="pointers_vs_values">Pointers vs. Values</h3>
Rob Pike's avatar
Rob Pike committed
1453
<p>
Ian Lance Taylor's avatar
Ian Lance Taylor committed
1454
Methods can be defined for any named type that is not a pointer or an interface;
Rob Pike's avatar
Rob Pike committed
1455 1456 1457 1458 1459 1460 1461 1462 1463
the receiver does not have to be a struct.
<p>
In the discussion of slices above, we wrote an <code>Append</code>
function.  We can define it as a method on slices instead.  To do
this, we first declare a named type to which we can bind the method, and
then make the receiver for the method a value of that type.
</p>
<pre>
type ByteSlice []byte
1464

Rob Pike's avatar
Rob Pike committed
1465
func (slice ByteSlice) Append(data []byte) []byte {
1466
    // Body exactly the same as above
Rob Pike's avatar
Rob Pike committed
1467 1468 1469 1470 1471 1472 1473 1474 1475 1476
}
</pre>
<p>
This still requires the method to return the updated slice.  We can
eliminate that clumsiness by redefining the method to take a
<i>pointer</i> to a <code>ByteSlice</code> as its receiver, so the
method can overwrite the caller's slice.
</p>
<pre>
func (p *ByteSlice) Append(data []byte) {
1477 1478 1479
    slice := *p
    // Body as above, without the return.
    *p = slice
Rob Pike's avatar
Rob Pike committed
1480 1481 1482 1483 1484 1485 1486 1487
}
</pre>
<p>
In fact, we can do even better.  If we modify our function so it looks
like a standard <code>Write</code> method, like this,
</p>
<pre>
func (p *ByteSlice) Write(data []byte) (n int, err os.Error) {
1488 1489 1490 1491
    slice := *p
    // Again as above.
    *p = slice
    return len(data), nil
Rob Pike's avatar
Rob Pike committed
1492 1493 1494 1495 1496
}
</pre>
<p>
then the type <code>*ByteSlice</code> satisfies the standard interface
<code>io.Writer</code>, which is handy.  For instance, we can
1497
print into one.
Rob Pike's avatar
Rob Pike committed
1498 1499
</p>
<pre>
1500 1501
    var b ByteSlice
    fmt.Fprintf(&amp;b, "This hour has %d days\n", 7)
Rob Pike's avatar
Rob Pike committed
1502 1503
</pre>
<p>
1504
We pass the address of a <code>ByteSlice</code>
Rob Pike's avatar
Rob Pike committed
1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515
because only <code>*ByteSlice</code> satisfies <code>io.Writer</code>.
The rule about pointers vs. values for receivers is that value methods
can be invoked on pointers and values, but pointer methods can only be
invoked on pointers.  This is because pointer methods can modify the
receiver; invoking them on a copy of the value would cause those
modifications to be discarded.
</p>
<p>
By the way, the idea of using <code>Write</code> on a slice of bytes
is implemented by <code>bytes.Buffer</code>.
</p>
1516

Rob Pike's avatar
Rob Pike committed
1517
<h2 id="interfaces_and_types">Interfaces and other types</h2>
1518

1519 1520 1521 1522 1523 1524 1525 1526
<h3 id="interfaces">Interfaces</h3>
<p>
Interfaces in Go provide a way to specify the behavior of an
object: if something can do <em>this</em>, then it can be used
<em>here</em>.  We've seen a couple of simple examples already;
custom printers can be implemented by a <code>String</code> method
while <code>Fprintf</code> can generate output to anything
with a <code>Write</code> method.
Rob Pike's avatar
Rob Pike committed
1527
Interfaces with only one or two methods are common in Go code, and are
1528 1529 1530 1531 1532 1533 1534 1535
usually given a name derived from the method, such as <code>io.Writer</code>
for something that implements <code>Write</code>.
</p>
<p>
A type can implement multiple interfaces.
For instance, a collection can be sorted
by the routines in package <code>sort</code> if it implements
<code>sort.Interface</code>, which contains <code>Len()</code>,
Russ Cox's avatar
Russ Cox committed
1536
<code>Less(i, j int) bool</code>, and <code>Swap(i, j int)</code>,
1537 1538 1539 1540 1541 1542 1543 1544
and it could also have a custom formatter.
In this contrived example <code>Sequence</code> satisfies both.
</p>
<pre>
type Sequence []int

// Methods required by sort.Interface.
func (s Sequence) Len() int {
1545
    return len(s)
1546 1547
}
func (s Sequence) Less(i, j int) bool {
1548
    return s[i] &lt; s[j]
1549 1550
}
func (s Sequence) Swap(i, j int) {
1551
    s[i], s[j] = s[j], s[i]
1552
}
1553

1554 1555
// Method for printing - sorts the elements before printing.
func (s Sequence) String() string {
1556 1557 1558
    sort.Sort(s)
    str := "["
    for i, elem := range s {
1559
        if i &gt; 0 {
1560 1561 1562 1563 1564
            str += " "
        }
        str += fmt.Sprint(elem)
    }
    return str + "]"
1565 1566
}
</pre>
1567

1568
<h3 id="conversions">Conversions</h3>
1569

Rob Pike's avatar
Rob Pike committed
1570
<p>
1571 1572 1573 1574 1575 1576 1577
The <code>String</code> method of <code>Sequence</code> is recreating the
work that <code>Sprint</code> already does for slices.  We can share the
effort if we convert the <code>Sequence</code> to a plain
<code>[]int</code> before calling <code>Sprint</code>.
</p>
<pre>
func (s Sequence) String() string {
1578 1579
    sort.Sort(s)
    return fmt.Sprint([]int(s))
1580 1581 1582 1583 1584 1585 1586 1587 1588 1589 1590 1591 1592 1593 1594
}
</pre>
<p>
The conversion causes <code>s</code> to be treated as an ordinary slice
and therefore receive the default formatting.
Without the conversion, <code>Sprint</code> would find the
<code>String</code> method of <code>Sequence</code> and recur indefinitely.
Because the two types (<code>Sequence</code> and <code>[]int</code>)
are the same if we ignore the type name, it's legal to convert between them.
The conversion doesn't create a new value, it just temporarily acts
as though the existing value has a new type.
(There are other legal conversions, such as from integer to float, that
do create a new value.)
</p>
<p>
Rob Pike's avatar
Rob Pike committed
1595
It's an idiom in Go programs to convert the
1596 1597 1598 1599
type of an expression to access a different
set of methods. As an example, we could use the existing
type <code>sort.IntArray</code> to reduce the entire example
to this:
Rob Pike's avatar
Rob Pike committed
1600
</p>
1601 1602
<pre>
type Sequence []int
Rob Pike's avatar
Rob Pike committed
1603

1604 1605
// Method for printing - sorts the elements before printing
func (s Sequence) String() string {
1606 1607
    sort.IntArray(s).Sort()
    return fmt.Sprint([]int(s))
1608 1609
}
</pre>
Rob Pike's avatar
Rob Pike committed
1610
<p>
1611 1612 1613 1614 1615 1616 1617 1618 1619 1620 1621
Now, instead of having <code>Sequence</code> implement multiple
interfaces (sorting and printing), we're using the ability of a data item to be
converted to multiple types (<code>Sequence</code>, <code>sort.IntArray</code>
and <code>[]int</code>), each of which does some part of the job.
That's more unusual in practice but can be effective.
</p>

<h3 id="generality">Generality</h3>
<p>
If a type exists only to implement an interface
and has no exported methods beyond that interface,
Rob Pike's avatar
Rob Pike committed
1622 1623 1624 1625 1626
there is no need to export the type itself.
Exporting just the interface makes it clear that
it's the behavior that matters, not the implementation,
and that other implementations with different properties
can mirror the behavior of the original type.
1627 1628 1629 1630 1631 1632 1633 1634 1635
It also avoids the need to repeat the documentation
on every instance of a common method.
</p>
<p>
In such cases, the constructor should return an interface value
rather than the implementing type.
As an example, in the hash libraries
both <code>crc32.NewIEEE()</code> and <code>adler32.New()</code>
return the interface type <code>hash.Hash32</code>.
Rob Pike's avatar
Rob Pike committed
1636
Substituting the CRC-32 algorithm for Adler-32 in a Go program
1637
requires only changing the constructor call;
Rob Pike's avatar
Rob Pike committed
1638 1639
the rest of the code is unaffected by the change of algorithm.
</p>
1640 1641 1642 1643
<p>
A similar approach allows the streaming cipher algorithms
in the <code>crypto/block</code> package to be
separated from the block ciphers they chain together.
Rob Pike's avatar
Rob Pike committed
1644
By analogy with the <code>bufio</code> package,
1645
they wrap a <code>Cipher</code> interface
Rob Pike's avatar
Rob Pike committed
1646
and return <code>hash.Hash</code>,
1647
<code>io.Reader</code>, or <code>io.Writer</code>
Rob Pike's avatar
Rob Pike committed
1648
interface values, not specific implementations.
1649 1650 1651 1652 1653 1654
</p>
<p>
The interface to <code>crypto/block</code> includes:
</p>
<pre>
type Cipher interface {
1655 1656 1657
    BlockSize() int
    Encrypt(src, dst []byte)
    Decrypt(src, dst []byte)
1658
}
Rob Pike's avatar
Rob Pike committed
1659

1660 1661 1662
// NewECBDecrypter returns a reader that reads data
// from r and decrypts it using c in electronic codebook (ECB) mode.
func NewECBDecrypter(c Cipher, r io.Reader) io.Reader
Rob Pike's avatar
Rob Pike committed
1663

1664 1665 1666 1667 1668 1669 1670 1671 1672 1673 1674 1675
// NewCBCDecrypter returns a reader that reads data
// from r and decrypts it using c in cipher block chaining (CBC) mode
// with the initialization vector iv.
func NewCBCDecrypter(c Cipher, iv []byte, r io.Reader) io.Reader
</pre>
<p>
<code>NewECBDecrypter</code> and <code>NewCBCReader</code> apply not
just to one specific encryption algorithm and data source but to any
implementation of the <code>Cipher</code> interface and any
<code>io.Reader</code>.  Because they return <code>io.Reader</code>
interface values, replacing ECB
encryption with CBC encryption is a localized change.  The constructor
Russ Cox's avatar
Russ Cox committed
1676
calls must be edited, but because the surrounding code must treat the result only
1677 1678
as an <code>io.Reader</code>, it won't notice the difference.
</p>
Russ Cox's avatar
Russ Cox committed
1679

Rob Pike's avatar
Rob Pike committed
1680 1681 1682 1683 1684 1685 1686 1687 1688
<h3 id="interface_methods">Interfaces and methods</h3>
<p>
Since almost anything can have methods attached, almost anything can
satisfy an interface.  One illustrative example is in the <code>http</code>
package, which defines the <code>Handler</code> interface.  Any object
that implements <code>Handler</code> can serve HTTP requests.
</p>
<pre>
type Handler interface {
1689
    ServeHTTP(*Conn, *Request)
Rob Pike's avatar
Rob Pike committed
1690 1691 1692 1693 1694
}
</pre>
<p>
For brevity, let's ignore POSTs and assume HTTP requests are always
GETs; that simplification does not affect the way the handlers are
Rob Pike's avatar
Rob Pike committed
1695
set up.  Here's a trivial but complete implementation of a handler to
Rob Pike's avatar
Rob Pike committed
1696 1697 1698 1699 1700 1701
count the number of times the
page is visited.
</p>
<pre>
// Simple counter server.
type Counter struct {
1702
    n int
Rob Pike's avatar
Rob Pike committed
1703 1704 1705
}

func (ctr *Counter) ServeHTTP(c *http.Conn, req *http.Request) {
1706 1707
    ctr.n++
    fmt.Fprintf(c, "counter = %d\n", ctr.n)
Rob Pike's avatar
Rob Pike committed
1708 1709 1710 1711
}
</pre>
<p>
(Keeping with our theme, note how <code>Fprintf</code> can print to an HTTP connection.)
Rob Pike's avatar
Rob Pike committed
1712
For reference, here's how to attach such a server to a node on the URL tree.
Rob Pike's avatar
Rob Pike committed
1713 1714 1715
<pre>
import "http"
...
1716 1717
ctr := new(Counter)
http.Handle("/counter", ctr)
Rob Pike's avatar
Rob Pike committed
1718 1719 1720 1721 1722 1723 1724 1725 1726 1727
</pre>
<p>
But why make <code>Counter</code> a struct?  An integer is all that's needed.
(The receiver needs to be a pointer so the increment is visible to the caller.)
</p>
<pre>
// Simpler counter server.
type Counter int

func (ctr *Counter) ServeHTTP(c *http.Conn, req *http.Request) {
1728 1729
    *ctr++
    fmt.Fprintf(c, "counter = %d\n", *ctr)
Rob Pike's avatar
Rob Pike committed
1730 1731 1732 1733 1734 1735 1736 1737 1738
}
</pre>
<p>
What if your program has some internal state that needs to be notified that a page
has been visited?  Tie a channel to the web page.
</p>
<pre>
// A channel that sends a notification on each visit.
// (Probably want the channel to be buffered.)
Rob Pike's avatar
Rob Pike committed
1739
type Chan chan *http.Request
Rob Pike's avatar
Rob Pike committed
1740 1741

func (ch Chan) ServeHTTP(c *http.Conn, req *http.Request) {
1742
    ch &lt;- req
1743
    fmt.Fprint(c, "notification sent")
Rob Pike's avatar
Rob Pike committed
1744 1745 1746 1747 1748
}
</pre>
<p>
Finally, let's say we wanted to present on <code>/args</code> the arguments
used when invoking the server binary.
Rob Pike's avatar
Rob Pike committed
1749
It's easy to write a function to print the arguments.
Rob Pike's avatar
Rob Pike committed
1750 1751 1752
</p>
<pre>
func ArgServer() {
1753 1754 1755
    for i, s := range os.Args {
        fmt.Println(s)
    }
Rob Pike's avatar
Rob Pike committed
1756 1757 1758 1759 1760
}
</pre>
<p>
How do we turn that into an HTTP server?  We could make <code>ArgServer</code>
a method of some type whose value we ignore, but there's a cleaner way.
Rob Pike's avatar
Rob Pike committed
1761 1762
Since we can define a method for any type except pointers and interfaces,
we can write a method for a function.
Rob Pike's avatar
Rob Pike committed
1763 1764 1765 1766 1767 1768 1769 1770 1771 1772 1773
The <code>http</code> package contains this code:
</p>
<pre>
// The HandlerFunc type is an adapter to allow the use of
// ordinary functions as HTTP handlers.  If f is a function
// with the appropriate signature, HandlerFunc(f) is a
// Handler object that calls f.
type HandlerFunc func(*Conn, *Request)

// ServeHTTP calls f(c, req).
func (f HandlerFunc) ServeHTTP(c *Conn, req *Request) {
1774
    f(c, req)
Rob Pike's avatar
Rob Pike committed
1775 1776 1777 1778 1779 1780
}
</pre>
<p>
<code>HandlerFunc</code> is a type with a method, <code>ServeHTTP</code>,
so values of that type can serve HTTP requests.  Look at the implementation
of the method: the receiver is a function, <code>f</code>, and the method
Rob Pike's avatar
Rob Pike committed
1781
calls <code>f</code>.  That may seem odd but it's not that different from, say,
Rob Pike's avatar
Rob Pike committed
1782 1783 1784
the receiver being a channel and the method sending on the channel.
</p>
<p>
Rob Pike's avatar
Rob Pike committed
1785 1786
To make <code>ArgServer</code> into an HTTP server, we first modify it
to have the right signature.
Rob Pike's avatar
Rob Pike committed
1787 1788 1789 1790
</p>
<pre>
// Argument server.
func ArgServer(c *http.Conn, req *http.Request) {
1791 1792 1793
    for i, s := range os.Args {
        fmt.Fprintln(c, s)
    }
Rob Pike's avatar
Rob Pike committed
1794 1795 1796
}
</pre>
<p>
Rob Pike's avatar
Rob Pike committed
1797 1798 1799 1800 1801
<code>ArgServer</code> now has same signature as <code>HandlerFunc</code>,
so it can be converted to that type to access its methods,
just as we converted <code>Sequence</code> to <code>IntArray</code>
to access <code>IntArray.Sort</code>.
The code to set it up is concise:
Rob Pike's avatar
Rob Pike committed
1802 1803
</p>
<pre>
1804
http.Handle("/args", http.HandlerFunc(ArgServer))
Rob Pike's avatar
Rob Pike committed
1805 1806 1807
</pre>
<p>
When someone visits the page <code>/args</code>,
Rob Pike's avatar
Rob Pike committed
1808 1809
the handler installed at that page has value <code>ArgServer</code>
and type <code>HandlerFunc</code>.
Rob Pike's avatar
Rob Pike committed
1810
The HTTP server will invoke the method <code>ServeHTTP</code>
Rob Pike's avatar
Rob Pike committed
1811
of that type, with <code>ArgServer</code> as the receiver, which will in turn call
Rob Pike's avatar
Rob Pike committed
1812
<code>ArgServer</code> (via the invocation <code>f(c, req)</code>
Rob Pike's avatar
Rob Pike committed
1813 1814
inside <code>HandlerFunc.ServeHTTP</code>).
The arguments will then be displayed.
Rob Pike's avatar
Rob Pike committed
1815 1816
</p>
<p>
Rob Pike's avatar
Rob Pike committed
1817
In this section we have made an HTTP server from a struct, an integer,
Rob Pike's avatar
Rob Pike committed
1818 1819 1820 1821
a channel, and a function, all because interfaces are just sets of
methods, which can be defined for (almost) any type.
</p>

Rob Pike's avatar
Rob Pike committed
1822 1823 1824 1825 1826 1827 1828 1829 1830 1831 1832 1833 1834 1835 1836
<h2 id="embedding">Embedding</h2>

<p>
Go does not provide the typical, type-driven notion of subclassing,
but it does have the ability to &ldquo;borrow&rdquo; pieces of an
implementation by <em>embedding</em> types within a struct or
interface.
</p>
<p>
Interface embedding is very simple.
We've mentioned the <code>io.Reader</code> and <code>io.Writer</code> interfaces before;
here are their definitions.
</p>
<pre>
type Reader interface {
1837
    Read(p []byte) (n int, err os.Error)
Rob Pike's avatar
Rob Pike committed
1838 1839 1840
}

type Writer interface {
1841
    Write(p []byte) (n int, err os.Error)
Rob Pike's avatar
Rob Pike committed
1842 1843 1844 1845 1846 1847 1848 1849 1850 1851 1852 1853 1854 1855
}
</pre>
<p>
The <code>io</code> package also exports several other interfaces
that specify objects that can implement several such methods.
For instance, there is <code>io.ReadWriter</code>, an interface
containing both <code>Read</code> and <code>Write</code>.
We could specify <code>io.ReadWriter</code> by listing the
two methods explicitly, but it's easier and more evocative
to embed the two interfaces to form the new one, like this:
</p>
<pre>
// ReadWrite is the interface that groups the basic Read and Write methods.
type ReadWriter interface {
1856 1857
    Reader
    Writer
Rob Pike's avatar
Rob Pike committed
1858 1859 1860 1861 1862 1863 1864 1865 1866 1867 1868 1869 1870 1871 1872 1873 1874 1875 1876 1877 1878 1879 1880
}
</pre>
<p>
This says just what it looks like: A <code>ReadWriter</code> can do
what a <code>Reader</code> does <em>and</em> what a <code>Writer</code>
does; it is a union of the embedded interfaces (which must be disjoint
sets of methods).
Only interfaces can be embedded within interfaces.
<p>
The same basic idea applies to structs, but with more far-reaching
implications.  The <code>bufio</code> package has two struct types,
<code>bufio.Reader</code> and <code>bufio.Writer</code>, each of
which of course implements the analogous interfaces from package
<code>io</code>.
And <code>bufio</code> also implements a buffered reader/writer,
which it does by combining a reader and a writer into one struct
using embedding: it lists the types within the struct
but does not give them field names.
</p>
<pre>
// ReadWriter stores pointers to a Reader and a Writer.
// It implements io.ReadWriter.
type ReadWriter struct {
1881 1882
    *Reader  // *bufio.Reader
    *Writer  // *bufio.Writer
Rob Pike's avatar
Rob Pike committed
1883 1884 1885
}
</pre>
<p>
1886 1887 1888 1889
The embedded elements are pointers to structs and of course
must be initialized to point to valid structs before they
can be used.
The <code>ReadWriter</code> struct could be written as
Rob Pike's avatar
Rob Pike committed
1890 1891 1892
</p>
<pre>
type ReadWriter struct {
1893 1894
    reader *Reader
    writer *Writer
Rob Pike's avatar
Rob Pike committed
1895 1896 1897 1898 1899 1900 1901 1902 1903
}
</pre>
<p>
but then to promote the methods of the fields and to
satisfy the <code>io</code> interfaces, we would also need
to provide forwarding methods, like this:
</p>
<pre>
func (rw *ReadWriter) Read(p []byte) (n int, err os.Error) {
1904
    return rw.reader.Read(p)
Rob Pike's avatar
Rob Pike committed
1905 1906 1907 1908 1909 1910 1911 1912 1913 1914 1915 1916
}
</pre>
<p>
By embedding the structs directly, we avoid this bookkeeping.
The methods of embedded types come along for free, which means that <code>bufio.ReadWriter</code>
not only has the methods of <code>bufio.Reader</code> and <code>bufio.Writer</code>,
it also satisfies all three interfaces:
<code>io.Reader</code>,
<code>io.Writer</code>, and
<code>io.ReadWriter</code>.
</p>
<p>
Rob Pike's avatar
Rob Pike committed
1917
There's an important way in which embedding differs from subclassing.  When we embed a type,
1918 1919
the methods of that type become methods of the outer type,
but when they are invoked the receiver of the method is the inner type, not the outer one.
Rob Pike's avatar
Rob Pike committed
1920
In our example, when the <code>Read</code> method of a <code>bufio.ReadWriter</code> is
Rob Pike's avatar
Rob Pike committed
1921
invoked, it has exactly the same effect as the forwarding method written out above;
Rob Pike's avatar
Rob Pike committed
1922 1923 1924
the receiver is the <code>reader</code> field of the <code>ReadWriter</code>, not the
<code>ReadWriter</code> itself.
</p>
Rob Pike's avatar
Rob Pike committed
1925 1926 1927 1928 1929 1930
<p>
Embedding can also be a simple convenience.
This example shows an embedded field alongside a regular, named field.
</p>
<pre>
type Job struct {
1931 1932
    Command string
    *log.Logger
Rob Pike's avatar
Rob Pike committed
1933 1934 1935 1936 1937 1938
}
</pre>
<p>
The <code>Job</code> type now has the <code>Log</code>, <code>Logf</code>
and other
methods of <code>log.Logger</code>.  We could have given the <code>Logger</code>
1939 1940 1941
a field name, of course, but it's not necessary to do so.  And now, once
initialized, we can
log to the <code>Job</code>:
Rob Pike's avatar
Rob Pike committed
1942 1943
</p>
<pre>
1944
job.Log("starting now...")
Rob Pike's avatar
Rob Pike committed
1945 1946
</pre>
<p>
1947
The <code>Logger</code> is a regular field of the struct and we can initialize
1948
it in the usual way with a constructor,
1949 1950 1951
</p>
<pre>
func NewJob(command string, logger *log.Logger) *Job {
1952
    return &amp;Job{command, logger}
1953 1954 1955
}
</pre>
<p>
1956 1957 1958 1959 1960 1961
or with a composite literal,
</p>
<pre>
job := &amp;Job{command, log.New(os.Stderr, nil, "Job: ", log.Ldate)}
</pre>
<p>
Rob Pike's avatar
Rob Pike committed
1962 1963 1964 1965 1966 1967 1968
If we need to refer to an embedded field directly, the type name of the field,
ignoring the package qualifier, serves as a field name.  If we needed to access the
<code>*log.Logger</code> of a <code>Job</code> variable <code>job</code>,
we would write <code>job.Logger</code>.
This would be useful if we wanted to refine the methods of <code>Logger</code>.
</p>
<pre>
1969
func (job *Job) Logf(format string, args ...) {
1970
    job.Logger.Logf("%q: %s", job.Command, fmt.Sprintf(format, args))
Rob Pike's avatar
Rob Pike committed
1971 1972 1973 1974 1975 1976 1977 1978 1979 1980 1981 1982 1983 1984 1985 1986
}
</pre>
<p>
Embedding types introduces the problem of name conflicts but the rules to resolve
them are simple.
First, a field or method <code>X</code> hides any other item <code>X</code> in a more deeply
nested part of the type.
If <code>log.Logger</code> contained a field or method called <code>Command</code>, the <code>Command</code> field
of <code>Job</code> would dominate it.
</p>
<p>
Second, if the same name appears at the same nesting level, it is usually an error;
it would be erroneous to embed <code>log.Logger</code> if <code>Job</code> struct
contained another field or method called <code>Logger</code>.
However, if the duplicate name is never mentioned in the program outside the type definition, it is OK.
This qualification provides some protection against changes made to types embedded from outside; there
Rob Pike's avatar
Rob Pike committed
1987 1988
is no problem if a field is added that conflicts with another field in another subtype if neither field
is ever used.
Rob Pike's avatar
Rob Pike committed
1989
</p>
Rob Pike's avatar
Rob Pike committed
1990 1991


1992 1993 1994 1995
<h2 id="concurrency">Concurrency</h2>

<h3 id="sharing">Share by communicating</h3>

Rob Pike's avatar
Rob Pike committed
1996 1997 1998 1999
<p>
Concurrent programming is a large topic and there is space only for some
Go-specific highlights here.
</p>
2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019
<p>
Concurrent programming in many environments is made difficult by the
subtleties required to implement correct access to shared variables.  Go encourages
a different approach in which shared values are passed around on channels
and, in fact, never actively shared by separate threads of execution.
Only one goroutine has access to the value at any given time.
Data races cannot occur, by design.
To encourage this way of thinking we have reduced it to a slogan:
</p>
<blockquote>
Do not communicate by sharing memory;
instead, share memory by communicating.
</blockquote>
<p>
This approach can be taken too far.  Reference counts may be best done
by putting a mutex around an integer variable, for instance.  But as a
high-level approach, using channels to control access makes it easier
to write clear, correct programs.
</p>
<p>
Rob Pike's avatar
Rob Pike committed
2020
One way to think about this model is to consider a typical single-threaded
2021 2022 2023
program running on one CPU. It has no need for synchronization primitives.
Now run another such instance; it too needs no synchronization.  Now let those
two communicate; if the communication is the synchronizer, there's still no need
Rob Pike's avatar
Rob Pike committed
2024
for other synchronization.  Unix pipelines, for example, fit this model
Rob Pike's avatar
Rob Pike committed
2025
perfectly.  Although Go's approach to concurrency originates in Hoare's
2026 2027 2028 2029 2030 2031
Communicating Sequential Processes (CSP),
it can also be seen as a type-safe generalization of Unix pipes.
</p>

<h3 id="goroutines">Goroutines</h3>

Rob Pike's avatar
Rob Pike committed
2032 2033 2034 2035 2036 2037 2038 2039 2040 2041 2042 2043 2044 2045 2046 2047 2048 2049 2050 2051 2052 2053 2054 2055 2056
<p>
They're called <em>goroutines</em> because the existing
terms&mdash;threads, coroutines, processes, and so on&mdash;convey
inaccurate connotations.  A goroutine has a simple model: it is a
function executing in parallel with other goroutines in the same
address space.  It is lightweight, costing little more than the
allocation of stack space.
And the stacks start small, so they are cheap, and grow
by allocating (and freeing) heap storage as required.
</p>
<p>
Goroutines are multiplexed onto multiple OS threads so if one should
block, such as while waiting for I/O, others continue to run.  Their
design hides many of the complexities of thread creation and
management.
</p>
<p>
Prefix a function or method call with the <code>go</code>
keyword to run the call in a new goroutine.
When the call completes, the goroutine
exits, silently.  (The effect is similar to the Unix shell's
<code>&amp;</code> notation for running a command in the
background.)
</p>
<pre>
2057
go list.Sort()  // run list.Sort in parallel; don't wait for it. 
Rob Pike's avatar
Rob Pike committed
2058 2059 2060 2061 2062
</pre>
<p>
A function literal can be handy in a goroutine invocation.
<pre>
func Announce(message string, delay int64) {
2063 2064 2065 2066
    go func() {
        time.Sleep(delay)
        fmt.Println(message)
    }()  // Note the parentheses - must call the function.
Rob Pike's avatar
Rob Pike committed
2067 2068 2069
}
</pre>
<p>
Rob Pike's avatar
Rob Pike committed
2070
In Go, function literals are closures: the implementation makes
Rob Pike's avatar
Rob Pike committed
2071 2072 2073 2074 2075 2076
sure the variables referred to by the function survive as long as they are active.
<p>
These examples aren't too practical because the functions have no way of signaling
completion.  For that, we need channels.
</p>

2077 2078
<h3 id="channels">Channels</h3>

Rob Pike's avatar
Rob Pike committed
2079 2080 2081 2082 2083 2084
<p>
Like maps, channels are a reference type and are allocated with <code>make</code>.
If an optional integer parameter is provided, it sets the buffer size for the channel.
The default is zero, for an unbuffered or synchronous channel.
</p>
<pre>
2085 2086 2087
ci := make(chan int)            // unbuffered channel of integers
cj := make(chan int, 0)         // unbuffered channel of integers
cs := make(chan *os.File, 100)  // buffered channel of pointers to Files
Rob Pike's avatar
Rob Pike committed
2088 2089 2090 2091 2092 2093 2094 2095 2096 2097 2098 2099
</pre>
<p>
Channels combine communication&mdash;the exchange of a value&mdash;with
synchronization&mdash;guaranteeing that two calculations (goroutines) are in
a known state.
</p>
<p>
There are lots of nice idioms using channels.  Here's one to get us started.
In the previous section we launched a sort in the background. A channel
can allow the launching goroutine to wait for the sort to complete.
</p>
<pre>
2100
c := make(chan int)  // Allocate a channel.
Rob Pike's avatar
Rob Pike committed
2101 2102
// Start the sort in a goroutine; when it completes, signal on the channel.
go func() {
2103 2104 2105 2106 2107
    list.Sort()
    c &lt;- 1  // Send a signal; value does not matter. 
}()
doSomethingForAWhile()
&lt;-c   // Wait for sort to finish; discard sent value.
Rob Pike's avatar
Rob Pike committed
2108 2109 2110 2111 2112 2113
</pre>
<p>
Receivers always block until there is data to receive.
If the channel is unbuffered, the sender blocks until the receiver has
received the value.
If the channel has a buffer, the sender blocks only until the
Ian Lance Taylor's avatar
Ian Lance Taylor committed
2114 2115
value has been copied to the buffer; if the buffer is full, this
means waiting until some receiver has retrieved a value.
Rob Pike's avatar
Rob Pike committed
2116 2117 2118 2119 2120
</p>
<p>
A buffered channel can be used like a semaphore, for instance to
limit throughput.  In this example, incoming requests are passed
to <code>handle</code>, which sends a value into the channel, processes
Rob Pike's avatar
Rob Pike committed
2121
the request, and then receives a value from the channel.
Rob Pike's avatar
Rob Pike committed
2122 2123 2124 2125 2126 2127 2128
The capacity of the channel buffer limits the number of
simultaneous calls to <code>process</code>.
</p>
<pre>
var sem = make(chan int, MaxOutstanding)

func handle(r *Request) {
2129
    sem &lt;- 1    // Wait for active queue to drain.
2130
    process(r)  // May take a long time.
2131
    &lt;-sem       // Done; enable next request to run.
Rob Pike's avatar
Rob Pike committed
2132 2133 2134 2135
}

func Serve(queue chan *Request) {
    for {
2136
        req := &lt;-queue
2137
        go handle(req)  // Don't wait for handle to finish.
Rob Pike's avatar
Rob Pike committed
2138 2139 2140 2141 2142 2143 2144 2145 2146 2147 2148 2149 2150 2151 2152
    }
}
</pre>
<p>
Here's the same idea implemented by starting a fixed
number of <code>handle</code> goroutines all reading from the request
channel.
The number of goroutines limits the number of simultaneous
calls to <code>process</code>.
This <code>Serve</code> function also accepts a channel on which
it will be told to exit; after launching the goroutines it blocks
receiving from that channel.
</p>
<pre>
func handle(queue chan *Request) {
2153 2154 2155
    for r := range queue {
        process(r)
    }
Rob Pike's avatar
Rob Pike committed
2156 2157 2158
}

func Serve(clientRequests chan *clientRequests, quit chan bool) {
2159
    // Start handlers
2160
    for i := 0; i &lt; MaxOutstanding; i++ {
2161 2162
        go handle(clientRequests)
    }
2163
    &lt;-quit  // Wait to be told to exit.
Rob Pike's avatar
Rob Pike committed
2164 2165 2166 2167 2168 2169 2170 2171 2172 2173 2174 2175 2176 2177 2178 2179 2180 2181
}
</pre>

<h3 id="chan_of_chan">Channels of channels</h3>
<p>
One of the most important properties of Go is that
a channel is a first-class value that can be allocated and passed
around like any other.  A common use of this property is
to implement safe, parallel demultiplexing.
<p>
In the example in the previous section, <code>handle</code> was
an idealized handler for a request but we didn't define the
type it was handling.  If that type includes a channel on which
to reply, each client can provide its own path for the answer.
Here's a schematic definition of type <code>Request</code>.
</p>
<pre>
type Request struct {
2182 2183 2184
    args        []int
    f           func([]int) int
    resultChan  chan int
Rob Pike's avatar
Rob Pike committed
2185 2186 2187 2188 2189 2190 2191 2192
}
</pre>
<p>
The client provides a function and its arguments, as well as
a channel inside the request object on which to receive the answer.
</p>
<pre>
func sum(a []int) (s int) {
2193 2194 2195 2196
    for _, v := range a {
        s += v
    }
    return
Rob Pike's avatar
Rob Pike committed
2197 2198 2199 2200
}

request := &amp;Request{[]int{3, 4, 5}, sum, make(chan int)}
// Send request
2201
clientRequests &lt;- request
Rob Pike's avatar
Rob Pike committed
2202
// Wait for response.
2203
fmt.Printf("answer: %d\n", &lt;-request.resultChan)
Rob Pike's avatar
Rob Pike committed
2204 2205 2206 2207 2208 2209
</pre>
<p>
On the server side, the handler function is the only thing that changes.
</p>
<pre>
func handle(queue chan *Request) {
2210
    for req := range queue {
2211
        req.resultChan &lt;- req.f(req.args)
2212
    }
Rob Pike's avatar
Rob Pike committed
2213 2214 2215 2216 2217 2218 2219 2220 2221 2222 2223 2224 2225 2226 2227 2228
}
</pre>
<p>
There's clearly a lot more to do to make it realistic, but this
code is a framework for a rate-limited, parallel, non-blocking RPC
system, and there's not a mutex in sight.
</p>

<h3 id="parallel">Parallelization</h3>
<p>
Another application of these ideas is to parallelize a calculation
across multiple CPU cores.  If the calculation can be broken into
separate pieces, it can be parallelized, with a channel to signal
when each piece completes.
</p>
<p>
Rob Pike's avatar
Rob Pike committed
2229
Let's say we have an expensive operation to perform on a vector of items,
Rob Pike's avatar
Rob Pike committed
2230 2231 2232 2233
and that the value of the operation on each item is independent,
as in this idealized example.
</p>
<pre>
Rob Pike's avatar
Rob Pike committed
2234
type Vector []float64
Rob Pike's avatar
Rob Pike committed
2235

Rob Pike's avatar
Rob Pike committed
2236
// Apply the operation to v[i], v[i+1] ... up to v[n-1].
Rob Pike's avatar
Rob Pike committed
2237
func (v Vector) DoSome(i, n int, u Vector, c chan int) {
2238
    for ; i &lt; n; i++ {
Rob Pike's avatar
Rob Pike committed
2239 2240
        v[i] += u.Op(v[i])
    }
2241
    c &lt;- 1    // signal that this piece is done
Rob Pike's avatar
Rob Pike committed
2242 2243 2244 2245 2246 2247 2248 2249 2250
}
</pre>
<p>
We launch the pieces independently in a loop, one per CPU.
They can complete in any order but it doesn't matter; we just
count the completion signals by draining the channel after
launching all the goroutines.
</p>
<pre>
2251
const NCPU = 4  // number of CPU cores
Rob Pike's avatar
Rob Pike committed
2252

Rob Pike's avatar
Rob Pike committed
2253
func (v Vector) DoAll(u Vector) {
2254
    c := make(chan int, NCPU)  // Buffering optional but sensible.
2255
    for i := 0; i &lt; NCPU; i++ {
2256
        go v.DoSome(i*len(v)/NCPU, (i+1)*len(v)/NCPU, u, c)
Rob Pike's avatar
Rob Pike committed
2257 2258
    }
    // Drain the channel.
2259 2260
    for i := 0; i &lt; NCPU; i++ {
        &lt;-c    // wait for one task to complete
Rob Pike's avatar
Rob Pike committed
2261 2262 2263 2264 2265 2266
    }
    // All done.
}

</pre>

Rob Pike's avatar
Rob Pike committed
2267 2268 2269 2270 2271 2272 2273 2274 2275 2276 2277 2278 2279 2280 2281 2282
<p>
The current implementation of <code>gc</code> (<code>6g</code>, etc.)
will not parallelize this code by default.
It dedicates only a single core to user-level processing.  An
arbitrary number of goroutines can be blocked in system calls, but
by default only one can be executing user-level code at any time.
It should be smarter and one day it will be smarter, but until it
is if you want CPU parallelism you must tell the run-time
how many goroutines you want executing code simultaneously.  There
are two related ways to do this.  Either run your job with environment
variable <code>GOMAXPROCS</code> set to the number of cores to use
(default 1); or import the <code>runtime</code> package and call
<code>runtime.GOMAXPROCS(NCPU)</code>.
Again, this requirement is expected to be retired as the scheduling and run-time improve.
</p>

2283 2284 2285
<h3 id="leaky_buffer">A leaky buffer</h3>

<p>
Rob Pike's avatar
Rob Pike committed
2286
The tools of concurrent programming can even make non-concurrent
2287 2288 2289 2290 2291 2292 2293 2294 2295
ideas easier to express.  Here's an example abstracted from an RPC
package.  The client goroutine loops receiving data from some source,
perhaps a network.  To avoid allocating and freeing buffers, it keeps
a free list, and uses a buffered channel to represent it.  If the
channel is empty, a new buffer gets allocated.
Once the message buffer is ready, it's sent to the server on
<code>serverChan</code>.
</p>
<pre>
Russ Cox's avatar
Russ Cox committed
2296 2297
var freeList = make(chan *Buffer, 100)
var serverChan = make(chan *Buffer)
2298 2299

func client() {
2300
    for {
2301
        b, ok := &lt;-freeList  // grab a buffer if available
2302 2303 2304 2305
        if !ok {              // if not, allocate a new one
            b = new(Buffer)
        }
        load(b)              // read next message from the net
2306
        serverChan &lt;- b      // send to server
2307
    }
2308 2309 2310 2311 2312 2313 2314 2315
}
</pre>
<p>
The server loop receives messages from the client, processes them,
and returns the buffer to the free list.
</p>
<pre>
func server() {
2316
    for {
2317
        b := &lt;-serverChan    // wait for work
2318
        process(b)
2319
        _ = freeList &lt;- b    // reuse buffer if room
2320
    }
2321 2322 2323 2324 2325 2326 2327 2328 2329 2330 2331 2332 2333 2334 2335 2336 2337 2338
}
</pre>
<p>
The client's non-blocking receive from <code>freeList</code> obtains a
buffer if one is available; otherwise the client allocates
a fresh one.
The server's non-blocking send on freeList puts <code>b</code> back
on the free list unless the list is full, in which case the
buffer is dropped on the floor to be reclaimed by
the garbage collector.
(The assignment of the send operation to the blank identifier
makes it non-blocking but ignores whether
the operation succeeded.)
This implementation builds a leaky bucket free list
in just a few lines, relying on the buffered channel and
the garbage collector for bookkeeping.
</p>

Rob Pike's avatar
Rob Pike committed
2339
<h2 id="errors">Errors</h2>
Russ Cox's avatar
Russ Cox committed
2340

Rob Pike's avatar
Rob Pike committed
2341 2342 2343 2344 2345 2346 2347 2348 2349
<p>
Library routines must often return some sort of error indication to
the caller.  As mentioned earlier, Go's multivalue return makes it
easy to return a detailed error description alongside the normal
return value.  By convention, errors have type <code>os.Error</code>,
a simple interface.
</p>
<pre>
type Error interface {
2350
    String() string
Rob Pike's avatar
Rob Pike committed
2351 2352 2353 2354 2355 2356 2357 2358
}
</pre>
<p>
A library writer is free to implement this interface with a
richer model under the covers, making it possible not only
to see the error but also to provide some context.
For example, <code>os.Open</code> returns an <code>os.PathError</code>.
</p>
Russ Cox's avatar
Russ Cox committed
2359
<pre>
Rob Pike's avatar
Rob Pike committed
2360 2361 2362
// PathError records an error and the operation and
// file path that caused it.
type PathError struct {
2363 2364 2365
    Op string    // "open", "unlink", etc.
    Path string  // The associated file.
    Error Error  // Returned by the system call.
Rob Pike's avatar
Rob Pike committed
2366 2367 2368
}

func (e *PathError) String() string {
2369
    return e.Op + " " + e.Path + ": " + e.Error.String()
Rob Pike's avatar
Rob Pike committed
2370
}
Russ Cox's avatar
Russ Cox committed
2371
</pre>
Rob Pike's avatar
Rob Pike committed
2372
<p>
Rob Pike's avatar
Rob Pike committed
2373 2374
<code>PathError</code>'s <code>String</code> generates
a string like this:
Rob Pike's avatar
Rob Pike committed
2375
</p>
Russ Cox's avatar
Russ Cox committed
2376
<pre>
Rob Pike's avatar
Rob Pike committed
2377
open /etc/passwx: no such file or directory
Russ Cox's avatar
Russ Cox committed
2378
</pre>
Rob Pike's avatar
Rob Pike committed
2379
<p>
Rob Pike's avatar
Rob Pike committed
2380 2381 2382 2383 2384
Such an error, which includes the problematic file name, the
operation, and the operating system error it triggered, is useful even
if printed far from the call that caused it;
it is much more informative than the plain
"no such file or directory".
Rob Pike's avatar
Rob Pike committed
2385 2386 2387 2388
</p>

<p>
Callers that care about the precise error details can
Rob Pike's avatar
Rob Pike committed
2389
use a type switch or a type assertion to look for specific
Rob Pike's avatar
Rob Pike committed
2390 2391
errors and extract details.  For <code>PathErrors</code>
this might include examining the internal <code>Error</code>
Rob Pike's avatar
Rob Pike committed
2392
field for recoverable failures.
Rob Pike's avatar
Rob Pike committed
2393
</p>
Russ Cox's avatar
Russ Cox committed
2394

Rob Pike's avatar
Rob Pike committed
2395
<pre>
2396
for try := 0; try &lt; 2; try++ {
2397 2398 2399 2400 2401 2402 2403 2404 2405
    file, err = os.Open(filename, os.O_RDONLY, 0)
    if err == nil {
        return
    }
    if e, ok := err.(*os.PathError); ok &amp;&amp; e.Error == os.ENOSPC {
        deleteTempFiles()  // Recover some space.
        continue
    }
    return
Rob Pike's avatar
Rob Pike committed
2406 2407 2408
}
</pre>

2409 2410 2411 2412 2413 2414 2415 2416 2417 2418 2419 2420 2421 2422 2423 2424 2425 2426 2427 2428 2429 2430 2431 2432 2433
<h2 id="web_server">A web server</h2>

<p>
Let's finish with a complete Go program, a web server.
This one is actually a kind of web re-server.
Google provides a service at
<a href="http://chart.apis.google.com">http://chart.apis.google.com</a>
that does automatic formatting of data into charts and graphs.
It's hard to use interactively, though,
because you need to put the data into the URL as a query.
The program here provides a nicer interface to one form of data: given a short piece of text,
it calls on the chart server to produce a QR code, a matrix of boxes that encode the
text.
That image can be grabbed with your cell phone's camera and interpreted as,
for instance, a URL, saving you typing the URL into the phone's tiny keyboard.
</p>
<p>
Here's the complete program.
An explanation follows.
</p>

<pre>
package main

import (
2434 2435 2436 2437 2438
    "flag"
    "http"
    "io"
    "log"
    "template"
2439 2440
)

Russ Cox's avatar
Russ Cox committed
2441
var addr = flag.String("addr", ":1718", "http service address") // Q=17, R=18
2442
var fmap = template.FormatterMap{
2443 2444
    "html": template.HTMLFormatter,
    "url+html": UrlHtmlFormatter,
2445 2446 2447 2448
}
var templ = template.MustParse(templateStr, fmap)

func main() {
2449 2450 2451 2452 2453 2454
    flag.Parse()
    http.Handle("/", http.HandlerFunc(QR))
    err := http.ListenAndServe(*addr, nil)
    if err != nil {
        log.Exit("ListenAndServe:", err)
    }
2455 2456 2457
}

func QR(c *http.Conn, req *http.Request) {
2458
    templ.Execute(req.FormValue("s"), c)
2459 2460 2461
}

func UrlHtmlFormatter(w io.Writer, v interface{}, fmt string) {
2462
    template.HTMLEscape(w, []byte(http.URLEscape(v.(string))))
2463 2464 2465 2466 2467 2468 2469 2470 2471 2472 2473 2474 2475 2476 2477 2478 2479 2480 2481 2482 2483 2484 2485 2486 2487 2488 2489 2490 2491 2492 2493 2494 2495 2496 2497 2498 2499 2500 2501 2502 2503
}


const templateStr = `
&lt;html&gt;
&lt;head&gt;
&lt;title&gt;QR Link Generator&lt;/title&gt;
&lt;/head&gt;
&lt;body&gt;
{.section @}
&lt;img src="http://chart.apis.google.com/chart?chs=300x300&amp;cht=qr&amp;choe=UTF-8&amp;chl={@|url+html}"
/&gt;
&lt;br&gt;
{@|html}
&lt;br&gt;
&lt;br&gt;
{.end}
&lt;form action="/" name=f method="GET"&gt;&lt;input maxLength=1024 size=70
name=s value="" title="Text to QR Encode"&gt;&lt;input type=submit
value="Show QR" name=qr&gt;
&lt;/form&gt;
&lt;/body&gt;
&lt;/html&gt;
`
</pre>

<p>
The pieces up to <code>main</code> should be easy to follow.
The one flag sets a default HTTP port for our server.  The template
variable <code>templ</code> is where the fun happens. It builds an HTML template
that will be executed by the server to display the page; more about
that in a moment.
</p>
<p>
The <code>main</code> function parses the flags and, using the mechanism
we talked about above, binds the function <code>QR</code> to the root path
for the server.  Then <code>http.ListenAndServe</code> is called to start the
server; it blocks while the server runs.
</p>
<p>
<code>QR</code> just receives the request, which contains form data, and
Russ Cox's avatar
Russ Cox committed
2504
executes the template on the data in the form value named <code>s</code>.
2505 2506 2507 2508 2509 2510 2511 2512
</p>
<p>
The template package, inspired by <a
href="http://code.google.com/p/json-template">json-template</a>, is
powerful;
this program just touches on its capabilities.
In essence, it rewrites a piece of text on the fly by substituting elements derived
from data items passed to <code>templ.Execute</code>, in this case the
Russ Cox's avatar
Russ Cox committed
2513
form value.  
2514 2515 2516 2517
Within the template text (<code>templateStr</code>),
brace-delimited pieces denote template actions.
The piece from the <code>{.section @}</code>
to <code>{.end}</code> executes with the value of the data item <code>@</code>,
Russ Cox's avatar
Russ Cox committed
2518
which is a shorthand for &ldquo;the current item&rdquo;, which is the form value.
2519 2520 2521 2522 2523 2524 2525 2526 2527 2528 2529 2530 2531 2532 2533 2534 2535 2536 2537 2538
(When the string is empty, this piece of the template is suppressed.)
</p>
<p>
The snippet <code>{@|url+html}</code> says to run the data through the formatter
installed in the formatter map (<code>fmap</code>)
under the name <code>"url+html"</code>.
That is the function <code>UrlHtmlFormatter</code>, which sanitizes the string
for safe display on the web page.
</p>
<p>
The rest of the template string is just the HTML to show when the page loads.
If this is too quick an explanation, see the <a href="/pkg/template/">documentation</a>
for the template package for a more thorough discussion.
</p>
<p>
And there you have it: a useful webserver in a few lines of code plus some
data-driven HTML text.
Go is powerful enough to make a lot happen in a few lines.
</p>

Rob Pike's avatar
Rob Pike committed
2539
<!--
Rob Pike's avatar
Rob Pike committed
2540
TODO
2541 2542 2543 2544 2545 2546 2547 2548
<pre>
verifying implementation
type Color uint32
    
// Check that Color implements image.Color and image.Image
var _ image.Color = Black
var _ image.Image = Black
</pre>
Rob Pike's avatar
Rob Pike committed
2549
-->
Rob Pike's avatar
Rob Pike committed
2550