I'm not sure what you mean by 'not exact' since the article you posted explictly contrasts duck typing with structural type systems of which Go is given as an example.
> Structural typing is a static typing system that determines type compatibility and equivalence by a type's structure, whereas duck typing is dynamic and determines type compatibility by only that part of a type's structure that is accessed during run time.
That sounds like static vs. dynamic implementations of the same thing.
Consider a generic "proxy" object that can be arbitrarily disconnected and reconnected to objects of different types. These can exist in any duck-typed runtime system. What is such an object's "type", even in the sense of its "runtime type"? There isn't one. There might be a sense in which it has an instantaneous type—a type it has as of a given program world-state—but that information is inaccessible to the runtime, since any probing it might do to ascertain this might also cause the object's instantaneous typing to change in the middle of the probing procedure.
(See also: the Universal Server in Erlang [ https://joearms.github.io/published/2013-11-21-My-favorite-e... ]. What is this server's "type"?)
A type system is something that can make guarantees about the behavior of a program in advance. In that sense, duck-typing isn't really a type system. It's just asking objects questions and then blindly trusting the responses you get. There's nothing but convention guaranteeing that an object that e.g. in Ruby implements `respond_to?` a certain way, will _actually_ respond to those methods when they're called. The object can lie. Which means you don't have a guarantee, and so you don't have a type system.