While Go interfaces are usually checked at compile time, this doesn't have to be the case - you don't even have to use reflection. Consider the following program.
package main
import "fmt"
type Dog struct{}
func (d Dog) NumberOfLegs() int {
return 4
}
func (d Dog) Genus() string {
return "Canin"
}
func main() {
var dog interface{} = Dog{}
fmt.Println(dog.(interface{ NumberOfLegs() int }).NumberOfLegs())
fmt.Println(dog.(interface{ Genus() string }).Genus())
fmt.Println(dog.(interface{ Happy() bool }).Happy())
}
Why do good people downvote what they don't understand?
https://play.golang.org/p/d0TkGTCZa2S
Runtime results in panic:
4
Canin
panic: interface conversion: main.Dog is not interface {
Happy() bool }: missing method Happy
goroutine 1 [running]: main.main() /tmp/sandbox251002434/prog.go:18 +0x200
So golang is somewhat dynamic as well, although using interface{} is kludgy and one would want to avoid that and reflection whenever possible.
This, I think, is the main point of the parent comment.
I think the distinction (and overlap) come into focus when you think computationally: how is a type computed? Type semantics are determined by the type checker, and Go's interface types are checked at compile time. Duck type checking happens at runtime. There's no language support in Go for this, but the closest thing would be passing a bunch of empty interfaces around and using the stdlib's reflect package everywhere so that you never panic, but sometimes return a user-generated TypeError.
Sure, Go's interfaces allow clients to accept multiple concrete types, but that's checked at compile time, not runtime, and so it will never be duck typed.