go when to use & or not?

I am confused whether to use a & with go when declaring a variable and init with a struct

say we have a struct wrapper

type HttpResult struct {
  	Status int32       `json:"status"`
	Msg    string      `json:"msg"`
	Data   interface{} `json:"data,omitempty"` 
}

and a struct defining the user model

type OmUser struct {
	Id       primitive.ObjectID `json:"id" bson:"_id,omitempty"`
	Name     string             `json:"name"`
	Password string             `json:"password"`
	Email    string             `json:"email"`
}

And the following declaring seems give the same result:

myOmUser := OmUser{ //note no & sign here
   Name: "Tony",
   Password: "mypass",
   Email: "tony@foo.com"
}

httpResult := &HttpResult{
		Status: 0,
		Msg:    "ok",
		Data:   myOmUser,
}

js, _ := json.Marshal(httpResult)

fmt.Println(js)

Or

myOmUser := &OmUser{ //note the & sign
   Name: "Tony",
   Password: "mypass",
   Email: "tony@foo.com"
}

httpResult := &HttpResult{
		Status: 0,
		Msg:    "ok",
		Data:   myOmUser,
}

js, _ := json.Marshal(httpResult)

fmt.Println(js)

so, when to use & and why?

In your particular example it doesn't make a difference.
But when we look at an example of using json.Unmarshal() it makes a bit more sense:

jsonBlob := []byte(`{"id": "1", "name": "bob", "password": "pass", "email", "hi@me.com"}`)
var newOmUser OmUser
err := json.Unmarshal(jsonBlob, &newOmUser)
if err != nil {
	panic(err)
}

Here we declare the variable before hand, and then we use the & to pass a pointer to that variable into the Unmarshal function.
That means that the Unmarshal function can reach out and update that variable, even though it's declared outside of the function.
Without the &, the Unmarshal function would get a copy of the newOmUser variable, and it would leave the original newOmUser variable that we declared empty.

When it comes to pointers, my general rule of thumb is:

> Don't use them unless you have to.

If you need to use any unmarshalling functions, you'll need them. There are lots of other functions that make use of them.

Here's a quick exercise that helps me understand a little more about pointers:

func uppercase(s string) {
	s = strings.ToUpper(s)
	fmt.Println(s)
}

// Same as the uppercase() function, but works with a pointer.
func uppercasePointer(s *string) {
	*s = strings.ToUpper(*s)
	fmt.Println(*s)
}

name := "bob"
uppercase(name)   // prints 'BOB'
fmt.Println(name) // prints 'bob' - our variable was not changed

name2 := "bobpointer"
uppercasePointer(&name2) // prints 'BOBPOINTER'
fmt.Println(name2)       // prints 'BOBPOINTER' - our variable was changed

When we call the uppercase(name) function, go makes a copy of the name variable and sends it to the uppercase function.
Whatever the function does to that copy that it received stays in the function. The original variable that we declared outside the function is not changed.

When we call the uppercasePointer(&name2) function, we are sending a pointer to the name2 variable we declared.
The function can use that pointer to reach out and update the name2 variable that we declared earlier.

At first, you might not see the point of pointers, but as you continue to use go, you will see that they help us solve some complex problems.

Empty interface type in Go can hold values of any type. Tour here.

So in your HttpResult.Data is an empty interface type. So you can assigne any type to it.

The difference between defining a variable with & is getting a pointer of that type. Tour here.
Those are obviously two types with two different functionalities in Go. But you can assign both to empty interface type variable because its accepting values of any type.

package main

import (
	"fmt"
	"reflect"
)

type OmUser struct {
}

func main() {
	myOmUser := OmUser{}
	myOmUser2 := &OmUser{}
	fmt.Println(reflect.TypeOf(myOmUser)) //main.OmUser
	fmt.Println(reflect.TypeOf(myOmUser2)) //*main.OmUser
}

For more details about &, read Go doc address operators
> For an
> operand x of type T, the address operation &x generates a pointer of
> type *T to x. The operand must be addressable, that is, either a
> variable, pointer indirection, or slice indexing operation; or a field
> selector of an addressable struct operand; or an array indexing
> operation of an addressable array. As an exception to the
> addressability requirement, x may also be a (possibly parenthesized)
> composite literal. If the evaluation of x would cause a run-time
> panic, then the evaluation of &x does too.

fooA := &Foo{}

fooA has type *Foo.

fooB := Foo{}

fooB has type Foo.

https://tour.golang.org/moretypes/1

In practice, this means if you had a func that accepted type *Foo you could do either of the following...

func someFunc(f *Foo) {
    // ...
}

fooA := &Foo{}
someFunc(fooA)

fooB := Foo{}
someFunc(&fooB)

So realistically, create whichever you need to be honest.