BTW I don't think the compiler is "smart enough" - but the Http API has 2 (probably more) overloaded methods for each type you may want to pass to it. Go doesn't have method overloading by design. If that's something that is a must have for anyone, Go is simply not for them.

Usually you don't want the compiler to be "smart" in this way, because it creates other headaches. For example, is a temporary object created each time you do this? What impact will that have on GC? If I compare an object of this interface with a "fake interface object" generated by the compiler, will it always be the same for the same callback? What is the call stack going to look like when I use jps? Seeing another <<anonymous>> line in there wouldn't give me the warm fuzzies when debugging.

I was not a fan of auto-unboxing for ints, for the same reasons.

There are a lot of good features in Java 8, but I'm not a fan of this particular one. Even if it saves a line of typing.

Yeah, well, knowing the Go philosophy, it makes sense not to have the compiler solve ambiguities like that, especially since a function can have its own methods.