If I understand the Java 8 example correctly, the Http.handle accepts an interface as well (the Handler interface with a single method). Java compiler is smart enough to automatically convert functions into objects satisfying interfaces with exactly one method, while Go compiler isn't.
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.
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.
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.
