I'm saying that at some point declaring the minimal interface a caller uses, for example Reader and Writer instead of a concrete FS type, starts to look like duck typing. In python a functions use of v.read() or v.write() defines what v should provide.

In Go it is compile time and Python it is runtime, but it is similar.

In Python (often) you don't care about the type of v just that it implements v.write() and in an interface based separation of API concerns you declare that v.write() is provided by the interface.

The aim is the same, duck typing or interfaces. And the outcome benefits are the same, at runtime or compile time.

Also yes Protocols can be used to type check quacks, bringing it more inline with the Go examples in the blog.

However my point is more from a SOLID perspective duck typing and minimal dependency interfaces sort of achieve similar ends... Minimal dependency and assumption by calling code.

> starts to look like duck typing.

Except you need a typed variable that implements the interface or you need to cast an any into an interface type. If the "any" type implemented all interfaces then it would be duck typing, but since the language enforces types at the call level, it is not.