You're right, but that's because Go doesn't really follow the OOP paradigm that you describe -- at least it's not idiomatic. It sounds like what you really want to do is define an interface, and provide types that satisfy that interface. That way, you could do something like this (example from sort package):

// A type, typically a collection, that satisfies sort.Interface can be                                                                                
// sorted by the routines in this package.  The methods require that the                                                                               
// elements of the collection be enumerated by an integer index.                                                                                       
type Interface interface {
        // Len is the number of elements in the collection.                                                                                            
        Len() int
        // Less returns whether the element with index i should sort                                                                                   
        // before the element with index j.                                                                                                            
        Less(i, j int) bool
        // Swap swaps the elements with indexes i and j.                                                                                               
        Swap(i, j int)
}

type Grams int

func (g Grams) String() string { return fmt.Sprintf("%dg", int(g)) }

type Organ struct {
        Name   string
        Weight Grams
}

type Organs []*Organ

func (s Organs) Len() int      { return len(s) }
func (s Organs) Swap(i, j int) { s[i], s[j] = s[j], s[i] }

// ByName implements sort.Interface by providing Less and using the Len and                                                                            
// Swap methods of the embedded Organs value.                                                                                                          
type ByName struct{ Organs }

func (s ByName) Less(i, j int) bool { return s.Organs[i].Name < s.Organs[j].Name }

// ByWeight implements sort.Interface by providing Less and using the Len and                                                                          
// Swap methods of the embedded Organs value.                                                                                                          
type ByWeight struct{ Organs }

func (s ByWeight) Less(i, j int) bool { return s.Organs[i].Weight < s.Organs[j].Weight }

From the Go FAQ:

Is Go an object-oriented language?

Yes and no. Although Go has types and methods and allows an object-oriented style of programming, there is no type hierarchy. The concept of “interface” in Go provides a different approach that we believe is easy to use and in some ways more general. There are also ways to embed types in other types to provide something analogous—but not identical—to subclassing. Moreover, methods in Go are more general than in C++ or Java: they can be defined for any sort of data, even built-in types such as plain, “unboxed” integers. They are not restricted to structs (classes).

Also, the lack of type hierarchy makes “objects” in Go feel much more lightweight than in languages such as C++ or Java.

Could you provide an example of what you are doing? Perhaps I could suggest a more "Go-like" approach?

Edit: Added sort.Interface for clarification.