> Golang furthers the notion of capabilities as shared method signatures, by loosely binding this into interfaces, and enforcing many errors by static type checks at compile time.
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.
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.