A lot of Golang is like this: very simple, almost trivial-seeming decisions that potently improve the language in practice. It's a fundamentally simple weapon, it's forged from Damascus steel.

    	if rt, ok := dst.(ReaderFrom); ok {
    		return rt.ReadFrom(src)
    	}

At least it is better than Java's instanceof + cast.

More importantly, it's a massively biased comparison to look at a language from 3 years ago and compare it to those from 20, 30 or 40 years ago. Of course the standard library will be cruftier in an older language. The Idris standard library is beautiful, really state of the art - as you'd expect from a language that's only been written in the last couple of years.

It will be interesting to see what the Go standard library looks like in 20 years' time; I'm betting it will fare less well than Java's, because the workarounds and cruft necessary to avoid breaking changes will be worse in a language without Java's type system. In the meantime, the fair and informative comparison to make is with languages of a similar vintage.

Really? Java's success is - rightly - attributed to its simple and usable libraries.

> To write clean Java you really need to avoid much of the standard library (read Effective Java by Josh Bloch)

Lol, the standard ArrayList.java is written by ... Josh Bloch!

The nice thing about this approach is that it signals to callers that reflection is going to happen, so callers can be ready for it—the types become a form of documentation. If reflection is unrestricted it's easy for callers to get surprised when methods are called that they didn't expect. (Go has had breakage during point release upgrades from this, for example.)

This stricter approach requires that you plan ahead for "upgrading" in advance since you can't change a non-upgradeable argument to an upgradeable one without changing the type signature and breaking your callers. On the other hand, your callers are secure in the knowledge that you won't do that: they know that if you didn't give them access to one of your type's methods they can't sneak around and get access to it through the "back door". Non-upgradeable interfaces can also be more efficient since there is no need to store the reflection metadata at runtime; with this approach you only pay for what you use. Altogether it's a classic static-versus-dynamic-typing tradeoff.

If you really need to cast, most functional languages will still let you - but as you say, it invalidates the proofs so is very much discouraged (e.g. the scalazzi safe subset requires you to not cast).

    GOPATH=`pwd` go test -bench=.

    BenchmarkInterfaceUpgrade        24.9 ns/op
    BenchmarkDoNothingInterfaceCall   5.32 ns/op
    BenchmarkInterfaceUpgradeAndCall 29.4 ns/op
    BenchmarkInterfaceUpgradeFail    23.9 ns/op

InterfaceUpgrade is testing the cost of having an interface-referenced value in hand and asking if it implements another interface. My belief based on the understanding of the runtime is that this is all a static check at runtime (i.e., taking the type of the value, looking that type's info up, and then reading from that type whether it implements a given interface, with all calculation done at compile time and only the lookup being done dynamically), and that while that number may go up a bit if there are more interfaces in play it shouldn't go up much.

DoNothingInterfaceCall is the time to call a function that does nothing and returns nothing through the interface. I tried adding a benchmark time for a do-nothing static call but Go inlines it away into nothing, making it a useless test of how fast the loop itself is running. 0.89 ns, FWIW.

InterfaceUpgradeAndCall combines the upgrade check and call into one pass. InterfaceUpgradeFail just checks to see if the fail case times very differently (no).

It's fairly easy to tweak these if you'd like to ask different questions. (Note some of the tests have a bit of spurious stuff at the end to make it so Go doesn't complain about unused values. Go really doesn't like to see unused values.)

Also, for those who may have spent some time benchmarking the more dynamic languages, I call your attention to the "ns" there. That's not milli- or microseconds, that's nanoseconds. (I once benchmarked something between Go and Erlang, and mistakingly though the Go was slower when it took 700 and Erlang was taking 70, but it turned out to be nanoseconds and microseconds respectively. FWIW, the code wasn't doing exactly the same thing, either, it was just some code I was benchmarking at the time, and it is expected that the Go code was doing less; point being, watch your units.)

http://play.golang.org/p/K1LedMxMPL

I understand it fine except this bit right at the end:

    var _ http.CloseNotifier = &fancyWriter{}
    var _ http.Flusher = &fancyWriter{}
    var _ http.Hijacker = &fancyWriter{}
    var _ io.ReaderFrom = &fancyWriter{}

In your example, GetVar() can be implemented in a number of ways. Returning Var field of Blah struct is only one such way (and if there was only one implementation, there would be no need for an interface).

In that light, adding variables as part of interface doesn't make sense. Variables are fixing the thing that interface is meant to make flexible.

In Go, you can achieve re-using of a bunch of variables (and their methods) by embedding - put the variables you want to re-use into a separate struct and embed that struct in other structs. See https://golang.org/doc/effective_go.html#embedding

Methods can be defined on any type declared in the package.

A type in go can be a lot more that just a struct; it can be any type in the language. So while it may make sense to have values on interfaces for structs, values don't make any sense for functions, pointers, interfaces, or extensions to built in types.