go: array in struct looses its content

The following go code (shared: link) should insert two positions in an order (both order and position are structs:

package main

import "fmt"

type orderPosition struct{
   art string
   qty string   
}

type order struct{
   posList []orderPosition
}

func main() {
  o := new(order)
  o.loadPos()
  fmt.Printf("# pos: %d\n",len(o.posList))

}

func (o order) loadPos() {
  o.posList = append(o.posList, orderPosition {art: "art 1", qty: "2 pc"})
  o.posList = append(o.posList, orderPosition {art: "art 2", qty: "7 pc"})
  fmt.Printf("# pos: %d\n",len(o.posList))
}

The output is:

# pos: 2
# pos: 0    

The method loadPos fills the positions in the order. But as soon as the method is left the list of positions is lost.

Why is the array loosing its content?

Any help would be greatly appreciated.

Your loadPos() method is using a value receiver (as opposed to a pointer), meaning that it's operating on a copy of the order object.
So when you call o.loadPos(), go is copying o, and calling loadPos() on that copy.

The solution is to simply change the receiver to a pointer:

func (o *order) loadPos() {

^{https://play.golang.org/p/PATpBCZLT7}

Extending the Patrick answer, there is more insight in Golang FAQ

Should I define methods on values or pointers?

func (s *MyStruct) pointerMethod() { } // method on pointer
func (s MyStruct)  valueMethod()   { } // method on value

> First, and most important, does the method need to modify the
> receiver? If it does, the receiver must be a pointer. (Slices and maps
> act as references, so their story is a little more subtle, but for
> instance to change the length of a slice in a method the receiver must
> still be a pointer.) In the examples above, if pointerMethod modifies
> the fields of s, the caller will see those changes, but valueMethod is
> called with a copy of the caller's argument (that's the definition of
> passing a value), so changes it makes will be invisible to the caller.
>
>
> Second is the consideration of efficiency. If the receiver is large, a
> big struct for instance, it will be much cheaper to use a pointer
> receiver.
>
> Next is consistency. If some of the methods of the type must have
> pointer receivers, the rest should too, so the method set is
> consistent regardless of how the type is used.

For types such as basic types, slices, and small structs, a value
receiver is very cheap so unless the semantics of the method requires
a pointer, a value receiver is efficient and clear.