Don't Make These 5 Golang Mistakes

These are mistakes that I’ve made writing Go. Although these might not
cause any sort of error but they can potentially affect the software.

1. Inside Loop

There are several ways to make a mess inside a loop which you need to be aware of.

1.1 Using reference to loop iterator variable

Due to efficiency, the loop iterator variable is a single variable that
takes different values in each loop iteration. It might lead to unwitting behavior.

in := []int{1, 2, 3}

var out []*int
for  _, v := range in {
	out = append(out, &v)
}

fmt.Println("Values:", *out[0], *out[1], *out[2])
fmt.Println("Addresses:", out[0], out[1], out[2])

The result will be:

Values: 3 3 3
Addresses: 0xc000014188 0xc000014188 0xc000014188

As you can see all elements in

out

v

out

v

The simple fix is to copy the loop iterator variable into a new variable:

in := []int{1, 2, 3}

var out []*int
for  _, v := range in {
	v := v
	out = append(out, &v)
}

fmt.Println("Values:", *out[0], *out[1], *out[2])
fmt.Println("Addresses:", out[0], out[1], out[2])

The new output:

Values: 1 2 3
Addresses: 0xc0000b6010 0xc0000b6018 0xc0000b6020

The same issue can be found in the loop iteration variable being used in a Goroutine.

list := []int{1, 2, 3}

for _, v := range list {
	go func() {
		fmt.Printf("%d ", v)
	}()
}

Output will be:

3 3 3

It can be fixed using the very same solution mentioned above. Note that without running the function with Goroutine, the code runs as expected.

1.2 Calling WaitGroup.Wait in loop

This mistake can be made using a shared variable of type

WaitGroup

Wait()

Done()

len(tasks)

Add()

Wait()

Wait()

var wg sync.WaitGroup
wg.Add(len(tasks))
for _, t := range tasks {
	go func(t *task) { 
		defer group.Done()
	}(t)
	// group.Wait()
}

group.Wait()

1.3 Using defer in loop

defer

defer

var mutex sync.Mutex
type Person struct {
	Age int
}
persons := make([]Person, 10)
for _, p := range persons {
	mutex.Lock()
	// defer mutex.Unlock()
	p.Age = 13
	mutex.Unlock()
}

In the above example, if you use line 8 instead of line 10, next iteration can not hold mutex lock because the lock is already in use and the loop blocks forever.

If you really need to use defer inside loop you might wanna entrust another function to do the work.

var mutex sync.Mutex
type Person struct {
	Age int
}
persons := make([]Person, 10)
for _, p := range persons {
	func() {
		mutex.Lock()
		defer mutex.Unlock()
		p.Age = 13
	}()
}

But, sometimes using

defer

Go suffers no fools

2. Sending into an unguaranteed channel

You can send values into channels from one Goroutine and receive those values into another Goroutine. By default, sends and receives block until the other side is ready. This allows Goroutines to synchronize without explicit locks or condition variables.

func doReq(timeout time.Duration) obj {
	// ch :=make(chan obj)
	ch := make(chan obj, 1)
	go func() {
		obj := do()
		ch <- result
	} ()
	select {
	case result = <- ch :
		return result
	case<- time.After(timeout):
		return nil 
	}
}

Let’s check the above code. The

doReq

The child Goroutine executes

do

select

ch

If timeout happens earlier, the parent will return from

doReq

ch

ch

Another fix can be using a

select

ch

...
select { 
case ch <- result: 
default:
}
...

3. Not using interfaces

Interfaces can make code more flexible. It is a way to bring polymorphism in code. Interface allows you to ask for a set of behaviors instead of a particular type. Not using interfaces might not cause any error but it can lead to a less simple, less flexible, and less extensible code.

Among many interfaces,

io.Reader

io.Writer

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

These interfaces can be very powerful. Let’s assume you are going to write an object into a file, so you defined a

Save

func (o *obj) Save(file os.File) error

What if you need to write into a

http.ResponseWriter

io.Writer

func (o *obj) Save(w io.Writer) error

Also, an important note you should know is that always ask for behaviors you are going to use. In the above example, asking for an

io.ReadWriteCloser

Write

So most of the time you better stay with behaviors instead of concrete type.

4. Bad ordered struct

This mistake can not cause any error as well but it can cause more memory usage.

type BadOrderedPerson struct {
	Veteran bool   // 1 byte
	Name    string // 16 byte
	Age     int32  // 4 byte
}

type OrderedPerson struct {
	Name    string
	Age     int32
	Veteran bool
}

It seems like both types have the same size of 21 bytes, but the result
shows something totally different . Compiling code using

GOARCH=amd64

BadOrderedPerson

OrderedPerson

padding = (align - (offset mod align)) mod align
aligned = offset + padding
        = offset + ((align - (offset mod align)) mod align)

type BadOrderedPerson struct {
	Veteran bool     // 1 byte
	_       [7]byte  // 7 byte: padding for alignment
	Name    string   // 16 byte
	Age     int32    // 4 byte
	_       struct{} // to prevent unkeyed literals
	// zero sized values, like struct{} and [0]byte occurring at 
	// the end of a structure are assumed to have a size of one byte.
	// so padding also will be addedd here as well.
	
}

type OrderedPerson struct {
	Name    string
	Age     int32
	Veteran bool
	_       struct{} 
}

It can lead to a performance issue when you have a big frequently used type. But don’t worry, you don’t have to take care of all your structs manually. Using maligned you can easily check your code for this issue.

5. Not using race detector in test

Data races cause mysterious failures, often long after the code has been
deployed to production. Because of that those are among the most common and hardest to debug types of bugs in concurrent systems. To help distinguish those kind of bugs, Go 1.1 introduced a built-in data race detector. It can be used simply adding

-race

$ go test -race pkg    # to test the package
$ go run -race pkg.go  # to run the source file
$ go build -race       # to build the package
$ go install -race pkg # to install the package

When race detector enabled, compiler will record when and how the memory was accessed within the code, while the

runtime

When a data race has been found, race detector prints a report which contains stack traces for conflicting accesses. Here is an example:

WARNING: DATA RACE
Read by goroutine 185:
  net.(*pollServer).AddFD()
      src/net/fd_unix.go:89 +0x398
  net.(*pollServer).WaitWrite()
      src/net/fd_unix.go:247 +0x45
  net.(*netFD).Write()
      src/net/fd_unix.go:540 +0x4d4
  net.(*conn).Write()
      src/net/net.go:129 +0x101
  net.func·060()
      src/net/timeout_test.go:603 +0xaf

Previous write by goroutine 184:
  net.setWriteDeadline()
      src/net/sockopt_posix.go:135 +0xdf
  net.setDeadline()
      src/net/sockopt_posix.go:144 +0x9c
  net.(*conn).SetDeadline()
      src/net/net.go:161 +0xe3
  net.func·061()
      src/net/timeout_test.go:616 +0x3ed

Goroutine 185 (running) created at:
  net.func·061()
      src/net/timeout_test.go:609 +0x288

Goroutine 184 (running) created at:
  net.TestProlongTimeout()
      src/net/timeout_test.go:618 +0x298
  testing.tRunner()
      src/testing/testing.go:301 +0xe8

Last words

The only real mistake is one from which we learn nothing.

Also published behind a paywall on: https://medium.com/swlh/5-mistakes-ive-made-in-go-75fb64b943b8