Golang Learning Notes

By convention, packages are given lower case, single-word names; there should be no need for underscores or mixedCaps.

Another convention is that the package name is the base name of its source directory; the package in src/encoding/base64 is imported as "encoding/base64" but has name base64, not encoding_base64 and not encodingBase64.

Use the package structure to help you choose good names.

Go doesn’t provide automatic support for getters and setters.

There’s nothing wrong with providing getters and setters yourself, and it’s often appropriate to do so, but it’s neither idiomatic nor necessary to put Get into the getter’s name.

If you have a field called owner (lower case, unexported), the getter method should be called Owner (upper case, exported), not GetOwner.

A setter function, if needed, will likely be called SetOwner.

Both names read well in practice:

owner := obj.Owner()
if owner != user {
    obj.SetOwner(user)
}

By convention, one-method interfaces are named by the method name plus an -er suffix or similar modification to construct an agent noun: Reader, Writer, Formatter, CloseNotifier etc.

There are a number of such names and it’s productive to honor them and the function names they capture.

Read, Write, Close, Flush, String and so on have 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, give it the same name and signature; call your string-converter method String not ToString.

The expressions need not be constants or even integers,

the cases are evaluated top to bottom until a match is found,

and if the switch has no expression it switches on true.

It’s therefore possible—​and idiomatic—​to write an if-else-if-else chain as a switch.

There is no automatic fall through, but cases can be presented in comma-separated lists.

Although they are not nearly as common in Go as some other C-like languages, break statements can be used to terminate a switch early.

Sometimes, though, it’s necessary to break out of a surrounding loop, not the switch, and in Go that can be accomplished by putting a label on the loop and "breaking" to that label.

Of course, the continue statement also accepts an optional label but it applies only to loops.

either because the surrounding function executed a return statement, reached the end of its function body,

godir, err := os.Open("/usr/local/go")
if err != nil {
	log.Printf("%s\n", err)
	defer godir.Close()
}

or because the corresponding goroutine is panicking.

	defer func() {
		e := recover()
		fmt.Printf("recover: %s\n", e)
	}()

	defer func() {
		fmt.Println(". . .")
	}()

	panic(fmt.Sprintf("Oops, I'm NOT myself."))
	// Output:
	// . . .
	// recover: Oops, I'm NOT myself.

Go’s defer statement schedules a function call (the deferred function) to be run immediately before the function executing the defer returns.

// The arguments to the deferred function (which include the receiver if the function is a method)
// are evaluated when the _defer_ executes, not when the _call_ executes.
func main() {
	v := 10
	defer fmt.Println(3 * v) // 30

	defer func() {
		fmt.Println(v) // 20
	}()

	defer func(x int) {
		fmt.Println(x) // 10
	}(v)

	v = 20
	_ = v
}

// Output:
// 10
// 20
// 30

It’s an unusual but effective way to deal with situations such as resources that must be released regardless of which path a function takes to return.

func ReadFile(filename string) ([]byte, error) {
    f, err := os.Open(filename)
    if err != nil {
        return nil, err
    }
    defer f.Close()
    return ReadAll(f)
}

Deferred functions are executed in LIFO order (stacking style).

for i := 0; i < 5; i++ {
	defer fmt.Printf("%d ", i)
}
// Output:
// 4 3 2 1 0

// All function values created by this loop "capture"
// and share the same variable—an addressable storage location,
// not its value at that particular moment.
for i := 0; i < 5; i++ {
    defer func() {
        fmt.Print(i, " ")
    }()
}
// Output:
// 5 5 5 5 5

for i := 0; i < 5; i++ {
    // declares inner i, intialized to outer i
    i := i
    defer func() {
        fmt.Print(i, " ")
    }()
}
// Output:
// 4 3 2 1 0

Go source code is always UTF-8.

A string holds arbitrary bytes.

A string literal, absent byte-level escapes, always holds valid UTF-8 sequences.

Those sequences represent Unicode code points, called runes.

No guarantee is made in Go that characters in strings are normalized.

The type [n]T is an array of n values of type T.

Arrays are values. Assigning one array to another copies all the elements.

The size of an array is part of its type.

A slice, on the other hand, is a dynamically-sized, flexible view into the elements of an array.

The type []T is a slice with elements of type T.

A slice is formed by specifying two indices, a low and high bound, separated by a colon:

// This selects a half-open range which includes the first element, but excludes the last one.
a[low : high]

The following expression creates a slice which includes elements 1 through 3 of a:

a[1:4]

A slice does not store any data, it just describes a section of an underlying array.

A slice hold references to an underlying array, and if you assign one slice to another, both refer to the same array.

Changing the elements of a slice modifies the corresponding elements of its underlying array.

Other slices that share the same underlying array will see those changes.

A slice literal is like an array literal without the length.

[]bool{true, true, false}

When slicing, you may omit the high or low bounds to use their defaults instead.

The default is zero for the low bound and the length of the slice for the high bound.

// For the array
var a [10]int
// these slice expressions are equivalent:
a[0:10]
a[:10]
a[0:]
a[:]

A slice has both a length and a capacity.

The length of a slice is the number of elements it contains.

The capacity of a slice is the number of elements in the underlying array, counting from the first element in the slice.

The length and capacity of a slice s can be obtained using the expressions len(s) and cap(s).

You can extend a slice’s length by re-slicing it, provided it has sufficient capacity.

The zero value of a slice is nil.

A nil slice has a length and capacity of 0 and has no underlying array.

It is common to append new elements to a slice, and so Go provides a built-in append function.

  func append(s []T, vs ...T) []T

The resulting value of append is a slice containing all the elements of the original slice plus the provided values.

If the backing array of s is too small to fit all the given values a bigger array will be allocated. The returned slice will point to the newly allocated array.

  var s []int

  // append works on nil slices.
  s = append(s, 0)

  // The slice grows as needed.
  s = append(s, 1)

  // We can add more than one element at a time.
  s = append(s, 2, 3, 4)

Maps are a convenient and powerful built-in data structure that associate values of one type (the key) with values of another type (the element or value).

The key can be of any type that is comparable for which the equality operator is defined.

Slices cannot be used as map keys, because equality is not defined on them.

Like slices, maps hold references to an underlying data structure.

The zero value of a map is nil.

Map literals are like struct literals, but the keys are required.

var m map[string]int // <nil>
m = map[string]int{
    "hello": 100,
    "world": 200,
}

The make function returns a map of the given type with an optional capacity hint as arguments, initialized and ready for use.

// m := make(map[string]int, 100)
m := make(map[string]int)

// insert or update an element
m["Answer"] = 42

// delete an element:
// The delete function doesn’t return anything, and will do nothing if the specified key doesn’t exist.
delete(m, "Answer")

// retrieve an element
// If the requested key doesn’t exist, we get the value type’s zero value.
v := m["Answer"]

// test that a key is present with a two-value assignment
v, ok := m["Answer"]

A function can return any number of results.

func (file *File) Write(b []byte) (n int, err error)

The return or result "parameters" of a Go function can be given names and used as regular variables, just like the incoming parameters.

Functions are values too. They can be passed around just like other values. Function values may be used as function arguments and return values.

Go functions may be closures, that is a function value that references (i.e. bounds to) variables from outside its body.

func adder() func(int) int {
	sum := 0
	return func(x int) int {
		sum += x
		return sum
	}
}

func w(s func(int) int, i int) int {
	return s(i)
}

func main() {
	pos, neg := adder(), adder()
	for i := 1; i <= 3; i++ {
		fmt.Printf("%+d, %+2d\n", w(pos, i), neg(-i))
	}
}

// Output:
// +1, -1
// +3, -3
// +6, -6

A function literal represents an anonymous function and cannot declare type parameters, and it can be assigned to a variable or invoked directly.

Function literals are closures: they may refer to variables defined in a surrounding function, which are then shared between the surrounding function and the function literal, and they survive as long as they are accessible.

func main() {
	var sum int
	var add = func() {
		sum += 1
	}
	add()
	fmt.Printf("%d\n", sum)
}

// Output:
// 1

There are two reasons to use a pointer receiver.

In general, all methods on a given type should have either value or pointer receivers, but not a mixture of both.

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.

Just as some functions allow nil pointers as arguments, so do some methods for their receiver, especially if nil is a meaningful zero value of the type, as with maps and slices.

When you define a type whose methods allow nil as a receiver value, it’s worth pointing this out explicitly in its documentation comment.

package bytes // import "bytes"

type Buffer struct {
	// Has unexported fields.
}
    A Buffer is a variable-sized buffer of bytes with Read and Write methods.
    The zero value for Buffer is an empty buffer ready to use.

A variable of interface type can store a value of any type that is in the type set of the interface. Such a type is said to implement the interface.

The value of an uninitialized variable of interface type is nil.

An interface type is specified by a list of interface elements.

A type implements an interface by implementing its methods. There is no explicit declaration of intent, no "implements" keyword.

Implicit interfaces decouple the definition of an interface from its implementation, which could then appear in any package without prearrangement.

Under the hood, interface values can be thought of as a tuple of a value and a concrete type:

(value, type)

Calling a method on an interface value executes the method of the same name on its underlying type.

If the concrete value inside the interface itself is nil, the method will be called with a nil receiver.

In some languages this would trigger a null pointer exception, but in Go it is common to write methods that gracefully handle being called with a nil receiver.

Note that an interface value that holds a nil concrete value is itself non-nil.

type I interface {
	M()
}

type T struct{}

func (t *T) M() {
	if t == nil {
		fmt.Println("<nil receiver>")
		return
	}
}

func main() {
	var i I // `i` is nil
	// i.M() // runtime error: invalid memory address or nil pointer dereference
	var t *T
	i = t // `i` is not nil, but the concrete type `t` is nil
	i.M()
	fmt.Printf("%v, %T\n", i, i)

	i = &T{} // the concrete type `t` is not nil
	i.M()
	fmt.Printf("%v, %T\n", i, i)
}

// Output:
// <nil receiver>
// <nil>, *main.T
// &{}, *main.T

A nil interface value holds neither value nor concrete type.

Calling a method on a nil interface is a run-time error because there is no type inside the interface tuple to indicate which concrete method to call.

var i I
fmt.Printf("(%v, %T)\n", i, i)
i.M()
// (<nil>, <nil>)
// panic: runtime error: invalid memory address or nil pointer dereference

The interface type that specifies zero methods is known as the empty interface:

interface{}

An empty interface may hold values of any type. (Every type implements at least zero methods.)

Empty interfaces are used by code that handles values of unknown type.

For convenience, the predeclared type any is an alias for the empty interface.

$ go doc builtin.any
package builtin // import "builtin"

type any = interface{}
    any is an alias for interface{} and is equivalent to interface{} in all
    ways.

Interfaces whose type sets can be defined entirely by a list of methods are called basic interfaces.

// A simple File interface.
interface {
	Read([]byte) (int, error)
	Write([]byte) (int, error)
	Close() error
}

In a slightly more general form an interface T may use a (possibly qualified) interface type name E as an interface element, which is called embedding interface E in T.

The type set of T is the intersection of the type sets defined by T’s explicitly declared methods and the type sets of T’s embedded interfaces.

type Reader interface {
	Read(p []byte) (n int, err error)
	Close() error
}

type Writer interface {
	Write(p []byte) (n int, err error)
	Close() error
}

// ReadWriter's methods are Read, Write, and Close.
type ReadWriter interface {
	Reader  // includes methods of Reader in ReadWriter's method set
	Writer  // includes methods of Writer in ReadWriter's method set
}

When embedding interfaces, methods with the same names must have identical signatures.

type ReadCloser interface {
	Reader   // includes methods of Reader in ReadCloser's method set
	Close()  // illegal: signatures of Reader.Close and Close are different
}

In their most general form, an interface element may also be an arbitrary type term T, or a term of the form ~T specifying the underlying type T, or a union of terms t1|t2|…|tn.

By construction, an interface’s type set never contains an interface type.

// An interface representing only the type int.
interface {
	int
}

// An interface representing all types with underlying type int.
interface {
	~int
}

// An interface representing all types with underlying type int that implement the String method.
interface {
	~int
	String() string
}

// An interface representing an empty type set: there is no type that is both an int and a string.
//
// This code defines an interface that no concrete type satisfies because there is no type that is
// both an int and a string. It is not the same as an empty interface (interface{}), which any type
// can satisfy. This code snippet is used to illustrate the concept of an unsatisfiable interface
// in the Go language specification. (Azure AI | ChatGPT 4)
//
// While this interface can be compiled, it cannot be used in practical terms because no type can
// satisfy the constraints. It's a theoretical construct to show the capabilities and limitations of
// the type constraint system in Go. (Azure AI | ChatGPT 4)
interface {
	int
	string
}

In a term of the form ~T, the underlying type of T must be itself, and T cannot be an interface.

type MyInt int

type MyI interface {
	~[]byte  // the underlying type of []byte is itself
	~MyInt   // illegal: the underlying type of MyInt is not MyInt
	~error   // illegal: error is an interface
}

Union elements denote unions of type sets:

// The Float interface represents all floating-point types
// (including any named types whose underlying types are
// either float32 or float64).
type Float interface {
	~float32 | ~float64
}

If a type exists only to implement an interface and will never have exported methods beyond that interface, there is no need to export the type itself.

Exporting just the interface makes it clear the value has no interesting behavior beyond what is described in the interface.

It also avoids the need to repeat the documentation on every instance of a common method.

In such cases, the constructor should return an interface value rather than the implementing type.

A type assertion provides access to an interface value’s underlying concrete value.

t := i.(T)

To test whether an interface value holds a specific type, a type assertion can return two values: the underlying value and a boolean value that reports whether the assertion succeeded.

t, ok := i.(T)

The declaration in a type switch has the same syntax as a type assertion i.(T), but the specific type T is replaced with the keyword type.

switch v := i.(type) {
case T:
    // here v has type T
case S:
    // here v has type S
default:
    // no match; here v has the same type as i
}

Go does not provide the typical, type-driven notion of subclassing, but it does have the ability to “borrow” pieces of an implementation by embedding types within a struct or interface.

package io // import "io"

type Reader interface {
    Read(p []byte) (n int, err error)
}

type Writer interface {
    Write(p []byte) (n int, err error)
}

// ReadWriter is the interface that combines the Reader and Writer interfaces.
type ReadWriter interface {
    Reader
    Writer
}

package bufio // import "bufio"

type Reader struct {
    // Has unexported fields.
}

func (b *Reader) Read(p []byte) (n int, err error)

type Writer struct {
    // Has unexported fields.
}

func (b *Writer) Write(p []byte) (nn int, err error)

// ReadWriter stores pointers to a Reader and a Writer.
// It implements io.ReadWriter.
type ReadWriter struct {
    *Reader
    *Writer
}

For the embedded type, 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.

type Reader struct {
}

func (r *Reader) Read() {
	fmt.Println("Read")
}

type Writer struct {
}

func (r *Writer) Write() {
	fmt.Println("Write")
}

type ReadWriter struct {
	*Reader
	*Writer
}

func main() {
	rw := ReadWriter{}
	rw.Read() // same as rw.Reader.Read()
	// Output:
	// Read
}

Embedding types introduces the problem of name conflicts but the rules to resolve them are simple.

Provides a "has-a" relationship where the outer struct or interface holds instances of other structs or interfaces as separate fields.

Requires explicitly accessing the fields and methods of the inner structs or interfaces through the composed fields.

Keeps a clear separation between the fields and methods of the outer struct or interface and the inner structs or interfaces it holds.

type Reader struct {
}

func (r *Reader) Read() {
	fmt.Printf("Read.\n")
}

type Writer struct {
}

func Write() {
	fmt.Printf("Write.\n")
}

type ReadWriter struct {
	reader *Reader
	writer *Writer
}

func main() {
	rw := &ReadWriter{&Reader{}, &Writer{}}
	rw.reader.Read() // Output: Read.
	rw.Read()        // Compiler error: rw.Read undefined (type *ReadWriter has no field or method Read)
}

Channels are a typed conduit through which you can send and receive values with the channel operator, <-.

ch <- v    // Send v to channel ch.
v := <-ch  // Receive from ch, and assign value to v.

// (The data flows in the direction of the arrow.)

Like maps and slices, channels must be created before use:

// By default, sends and receives block until the other side is ready.
// This allows goroutines to synchronize without explicit locks or condition variables.
blockChan := make(chan int)

// Sends to a buffered channel block only when the buffer is full.
// Receives block when the buffer is empty.
bufChan := make(chan int, 100)

A sender can close a channel to indicate that no more values will be sent.

A channel may be constrained only to send or only to receive by assignment or explicit conversion.

func main() {
	var (
		_ = make(chan int)   // bidirectional
		_ = make(<-chan int) // receive-only
		_ = make(chan<- int) // send-only
	)

	ch := make(chan int)

	// send-only
	go func(ch chan<- int) {
		for i := 0; i < 3; i++ {
			ch <- i
		}
		close(ch)
	}(ch)

	// receive-only
	go func(ch <-chan int) {
		for v := range ch {
			fmt.Println(v)
		}
	}(ch)

	time.Sleep(time.Millisecond)
	// Output:
	// 0
	// 1
	// 2
}

func main() {
	ch1 := make(chan int)
	ch2 := make(chan int, 2) // buffering channel
	quit := make(chan int)

	go func() {
		for i := 1; ; i++ {
			ch1 <- 2 * i
			time.Sleep(time.Duration(rand.Intn(1e3)) * time.Millisecond)
		}
	}()

	go func(ch chan<- int) {
		for i := 1; ; i++ {
			ch <- 2*i + 1
			time.Sleep(time.Duration(rand.Intn(1e3)) * time.Millisecond)
		}
	}(ch2)

	go func() {
		<-time.After(time.Duration(5e3) * time.Millisecond)
		quit <- 0
	}()

	//  The select statement lets a goroutine wait on multiple communication operations.
	//  A select blocks until one of its cases can run, then it executes that case.
	//  It chooses one at random if multiple are ready.
	ch3 := make(chan int)
	timeout := time.After(500 * time.Millisecond)

	go func() {
		defer close(ch3)
		for {
			// multiplexing: ch1 + ch2 => ch3
			select {
			case ch3 <- <-ch1:
			case ch3 <- <-ch2:
			case <-timeout:
				fmt.Println("You're too slow.")
				return
			case <-quit:
				fmt.Println("Quit.")
				return
			}
		}
	}()

	for v := range ch3 {
		fmt.Println(v)
	}
}

Go functions can be written to work on multiple types using type parameters.

func Index[T comparable](s []T, x T) int

package builtin // import "builtin"

type comparable interface{ comparable }
    comparable is an interface that is implemented by all comparable types
    (booleans, numbers, strings, pointers, channels, arrays of comparable types,
    structs whose fields are all comparable types). The comparable interface may
    only be used as a type parameter constraint, not as the type of a variable.

In addition to generic functions, Go also supports generic types.

type ComparableOrdered interface {
	comparable
	constraints.Ordered // "golang.org/x/exp/constraints"
}

// List represents a singly-linked list that holds values of `ComparableOrdered` type.
type List[T ComparableOrdered] struct {
	next *List[T]
	val  T
}

func (head *List[T]) append(vals ...T) {
	var a = func(val T) {
		tail := head
		for tail.next != nil {
			tail = tail.next
		}
		tail.next = &List[T]{val: val}
	}
	for _, val := range vals {
		a(val)
	}
}

func (head *List[T]) max() T {
	max := head.val
	node := head.next
	for node != nil {
		if node.val > max {
			max = node.val
		}
		node = node.next
	}
	return max
}

func (head *List[T]) String() string {
	var b strings.Builder
	node := head
	for node != nil {
		fmt.Fprintf(&b, "%v", node.val)
		node = node.next
		if node != nil {
			fmt.Fprint(&b, " -> ")
		}
	}
	return b.String()
}

func main() {
	list := &List[int]{val: 20}
	list.append(10, 30, 60)
	list.append(40)
	fmt.Printf("list: %v\n", list)
	fmt.Printf("max: %v", list.max())
	// Output:
	// list: 20 -> 60 -> 30 -> 10 -> 40
	// max: 60
}

Type constraint and type parameter

Constants are declared like variables, but with the const keyword.

Constants cannot be declared using the := syntax.

Constants are created at compile time, even when defined as locals in functions, and can only be numbers, characters (runes), strings or booleans.

Because of the compile-time restriction, the expressions that define them must be constant expressions, evaluatable by the compiler.

In Go, enumerated constants are created using the iota enumerator.

type Weekday int

const (
    Sunday Weekday = iota + 1 // iota: 0 ~ Sunday    : 1
    _                         // iota: 1 ~ iota increased
    // comments               // iota: 1 ~ skip: comment
                              // iota: 1 ~ skip: empty line
    Monday                    // iota: 2 ~ Monday    : 3
    Tuesday                   // iota: 3 ~ Monday    : 4
    Wednesday                 // iota: 4 ~ Monday    : 5
    Thursday                  // iota: 5 ~ Monday    : 6
    Friday                    // iota: 6 ~ Monday    : 7
    Saturday                  // iota: 7 ~ Monday    : 8
)

iota (noun)
/aɪˈəʊtə/
/aɪˈəʊtə/

1. [singular] (usually used in negative sentences) an extremely small amount
    There is not one iota of truth (= no truth at all) in the story.
    I don't think that would help one iota.
2. the 9th letter of the Greek alphabet (I, ι)

ref: https://www.oxfordlearnersdictionaries.com/us/definition/english/iota

Go has two allocation primitives, the built-in functions new and make.

new is a built-in function that allocates memory, but unlike its namesakes in some other languages it does not initialize the memory, it only zeros it.

package builtin // import "builtin"

func new(Type) *Type
    The new built-in function allocates memory. The first argument is a type,
    not a value, and the value returned is a pointer to a newly allocated zero
    value of that type.

The built-in function make(T, args) serves a purpose different from new(T).

package builtin // import "builtin"

func make(t Type, size ...IntegerType) Type
    The make built-in function allocates and initializes an object of type
    slice, map, or chan (only). Like new, the first argument is a type, not a
    value. Unlike new, make's return type is the same as the type of its
    argument, not a pointer to it. The specification of the result depends on
    the type:

        Slice: The size specifies the length. The capacity of the slice is
        equal to its length. A second integer argument may be provided to
        specify a different capacity; it must be no smaller than the
        length. For example, make([]int, 0, 10) allocates an underlying array
        of size 10 and returns a slice of length 0 and capacity 10 that is
        backed by this underlying array.

        Map: An empty map is allocated with enough space to hold the
        specified number of elements. The size may be omitted, in which case
        a small starting size is allocated.

        Channel: The channel's buffer is initialized with the specified
        buffer capacity. If zero, or the size is omitted, the channel is
        unbuffered.

Each source file can define its own niladic init function to set up whatever state is required.

Actually each file can have multiple init functions, which called in the order they appear in the source.

init 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.

$ tree
.
├── go.mod
├── hello
│   └── hello.go
├── init.go
└── world
    └── world.go

3 directories, 4 files
$ cat go.mod
module hello.world/init

go 1.18
$ cat hello/hello.go
package hello

import "fmt"

func init() {
	fmt.Printf("Hello")
}
$ cat world/world.go
package world

import "fmt"

func init() {
	fmt.Printf(", ")
}

func init() {
	fmt.Printf("世界")
}

func init() {
	fmt.Printf("!\n")
}
$ cat init.go
package main

import (
	_ "hello.world/init/hello"
	_ "hello.world/init/world"
)

func main() {
}
$ go run init.go
Hello, 世界!

0 for numeric types,

false for the boolean type,

"" (the empty string) for strings,

nil for the pointers, slices, maps, functions, interfaces, channels,

A race condition is a situation in which the program does not give the correct result for some interleaving of the operations of multiple goroutines.

A data race, that is, a particular kind of race condition, occurs whenever two goroutines access the same variable concurrently and at least one of the accesses is a write. It follows from this definition that there are three ways to avoid a data race.

Synchronization is about more than just the order of execution of multiple goroutines; synchronization also affets memory.

The race detector (just add the -race flag to your go build, go run, or go test command) studies this steam of events, looking for cases in which one goroutine reads or writes a shared variables that was most recently written by a different goroutine without an intervening synchronization operation.

The race detector reports all data races that wre actually executed.

 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
func main() {
	var wg sync.WaitGroup
	var x, y int

	wg.Add(1)
	go func() {
		defer wg.Done()
		x = 1
		fmt.Printf("y = %d\n", y)
	}()

	wg.Add(1)
	go func() {
		defer wg.Done()
		y = 1
		fmt.Printf("x = %d\n", x)
	}()

	wg.Wait()
}

$ go run -race race.go
x = 0
==================
WARNING: DATA RACE
Write at 0x00c0000160c8 by goroutine 7:
  main.main.func1()
      /home/x/learn/go/race.go:15 +0xaa

Previous read at 0x00c0000160c8 by goroutine 8:
  main.main.func2()
      /home/x/learn/go/race.go:23 +0xcf
...
==================
==================
WARNING: DATA RACE
Read at 0x00c0000160d8 by goroutine 7:
  main.main.func1()
      /home/x/learn/go/race.go:16 +0xcf

Previous write at 0x00c0000160d8 by goroutine 8:
  main.main.func2()
      /home/x/learn/go/race.go:22 +0xaa
==================
y = 1
Found 2 data race(s)
exit status 66

Within a single goroutine, reads and writes must behave as if they executed in the order specified by the program.

That is, compilers and processors may reorder the reads and writes executed within a single goroutine only when the reordering does not change the behavior within that goroutine as defined by the language specification.

Because of this reordering, the execution order observed by one goroutine may differ from the order perceived by another.

To specify the requirements of reads and writes, we define happens before, a partial order on the execution of memory operations in a Go program.

Within a single goroutine, the happens-before order is the order expressed by the program.

Programs that modify data being simultaneously accessed by multiple goroutines must serialize such access.

To serialize access, protect the data with channel operations or other synchronization primitives such as those in the sync and sync/atomic packages.

Do not communicate by sharing memory; instead, share memory by communicating.

One way to think about this model is to consider a typical single-threaded program running on one CPU.

A goroutine has a simple model: it is a function executing concurrently with other goroutines in the same address space.

Goroutines are multiplexed onto multiple OS threads so if one should block, such as while waiting for I/O, others continue to run.

I/O-bound tasks: If your application performs tasks that are primarily I/O-bound, such as reading from or writing to disk, network, or other external resources, you can benefit from a higher number of goroutines. Since I/O-bound tasks often involve waiting for external resources, having more goroutines can help keep your application busy and utilize available CPU resources effectively. In this case, the optimal number of goroutines might be several times the number of available CPU cores.

CPU-bound tasks: If your application performs tasks that are primarily CPU-bound, such as complex calculations or data processing, you may not benefit from a higher number of goroutines than the number of available CPU cores. Having more goroutines than CPU cores can lead to frequent context switching, which can hurt performance. In this case, the optimal number of goroutines might be close to the number of available CPU cores.

Workload characteristics: The best number of goroutines also depends on the specific characteristics of your application’s workload. For example, if your application has a mix of I/O-bound and CPU-bound tasks, or if it has varying resource requirements over time, you might need to experiment with different numbers of goroutines to find the optimal balance.

Resource availability: The optimal number of goroutines also depends on the resources available on your system, such as CPU, memory, and I/O capacity. If your system is constrained in terms of resources, you may need to limit the number of goroutines to avoid exhausting system resources and causing performance issues.

Like maps, channels are allocated with make, and the resulting value acts as a reference to an underlying data structure.

Receivers always block until there is data to receive.

The sender blocks only until the value has been copied to the buffer;

A buffered channel can be used like a semaphore, for instance to limit throughput.

The assembly line metaphor (pipeline) is useful one for channels and goroutines.

// A concurrent prime sieve

// Send the sequence 2, 3, 4, ... to channel 'ch'.
func Generate(ch chan<- int) {
	for i := 2; ; i++ {
		ch <- i // Send 'i' to channel 'ch'.
	}
}

// Copy the values from channel 'in' to channel 'out',
// removing those divisible by 'prime'.
func Filter(in <-chan int, out chan<- int, prime int) {
	for {
		i := <-in // Receive value from 'in'.
		if i%prime != 0 {
			out <- i // Send 'i' to 'out'.
		}
	}
}

// The prime sieve: Daisy-chain Filter processes.
func main() {
	ch := make(chan int) // Create a new channel.
	go Generate(ch)      // Launch Generate goroutine.
	for i := 0; i < 10; i++ {
		prime := <-ch
		print(prime, "\n")
		ch1 := make(chan int)
		go Filter(ch, ch1, prime)
		ch = ch1
	}
}

There is a built-in function panic that in effect creates a runtime unrecoverable error that will stop the program.

The function takes a single argument of arbitrary type—​often a string—​to be printed as the program dies.

package builtin // import "builtin"

func panic(v interface{})
    The panic built-in function stops normal execution of the current goroutine.
    When a function F calls panic, normal execution of F stops immediately. Any
    functions whose execution was deferred by F are run in the usual way, and
    then F returns to its caller. To the caller G, the invocation of F then
    behaves like a call to panic, terminating G's execution and running any
    deferred functions. This continues until all functions in the executing
    goroutine have stopped, in reverse order. At that point, the program is
    terminated with a non-zero exit code. This termination sequence is called
    panicking and can be controlled by the built-in function recover.

When panic is called, including implicitly for runtime errors such as indexing a slice out of bounds or failing a type assertion,

However, it is possible to use the built-in function recover to regain control of the goroutine and resume normal execution.

A call to recover stops the unwinding and returns the argument passed to panic.

  func F() {
  	panic("F: panic.")
  }

  func G() {
  	defer func() {
  		e := recover()
  		if e != nil {
  			fmt.Println("G: recover:", e)
  		}
  	}()

  	F()
  }

  func main() {
  	G()
  	// Output:
  	// G: recover: F: panic.
  }

Width is specified by an optional decimal number immediately preceding the verb.

Precision is specified after the (optional) width by a period followed by a decimal number.

%f     default width, default precision
%9f    width 9, default precision
%.2f   default width, precision 2
%9.2f  width 9, precision 2
%9.f   width 9, precision 0