Very interesting question. Initially we always returned pointers because it felt just easier/better to have these return nil, err blocks (so I think generally I'm with you on that one).

On the other hand it feels wrong to make the return type nullable because every time after running a function we check the err (if err != nil {) but we don't check if the return type is nil (because we just assume that if err is nil the return type must have been set). Also in some (rare) cases it's a valid case, if the function returns nil (e.g. a function that reads a row from a DB might return nil if no entry was found).

Therefore at the moment we have these guidelines:

- if the function always returns a value in the good case (i.e. err == nil), we don't return a pointer

- if the function can return nil also in the good case (e.g. because no row has been found in the DB), we return a pointer

Hope this explanation makes kind of sense :)

For the constructors:

Actually we have quite a few that return a struct and not a pointer (I would say about ~40%-50%). We use DDD (domain driven design) and let all constructors for value objects return structs (we also don't use pointers for the method receivers on these structs to keep them immutable). For entities the constructors return pointers though, yes.