That's embedding. If it's a replacement for any traditional OO concept, it's "inheritance", not overloading. (It isn't a replacement, but if you found yourself needing inheritance, embedding is what you'd use to get the closest.) Overloading would allow multiple definition of the same function name that are dispatched in various ways based on the types being called.

I show this only for example because it's horrifying Go code, but the closest go equivalent would be:

    func OverloadedSomething(params ...interface{}) interface{} {
        // (int, int) int
        if len(params) == 2 {
            a, isAInt := params[0].(int)
            b, isBInt := params[1].(int)
            if isAInt && isBInt {
                return a + b
            }
        }

        // (string) string
        if len(params) == 1 {
            aStr, isAStr := params[0].(string)
            if isAStr {
                return aStr + " world"
            }
        }

        // etc etc

        panic("OverloadedSomething not given something it can resolve")
    }

Which could then be called like:

    sum := OverloadedSomething(1, 2).(int)
    helloWorld := OverloadedSomething("hello").(string)

I may have the ... on the wrong side of the interface{} in the params.

The Go thing to do is to declare separate functions for each implementation. Other languages have support for doing that sort of resolution at compile time, so you don't get the obvious run-time hit you'd take trying to do that in Go.

You confound the two orthogonal terms "overloading" and "overriding".

Overriding:

  class Foo {
    void f() {}
  }

  class Bar : Foo {
    void f() {}
  }

Overloading:

  class Foo {
    void f(int i) {}
    void f(string s) {}
  }

Go doesn't allow overloading: "method lookup is always by name only, not by signature (type) of the method. In other words, a single type can never have two methods with the same name. Given a method x.M, there's only ever one M associated with x. Again, this makes it easy to identify which method is referred to given only the name. It also makes the implementation of method invocation simple." http://talks.golang.org/2012/splash.article#TOC_11.