Rust traits have the opposite behavior. If it says it’s an iterable, it must quack like an iterable.

Something that quacks like an iterable cannot be used as an iterable, unless the trait is explicitly stated — unlike python, where it simply has to quack.

Crystal would be a better example of a statically compiled language with duck typing.

Typeclasses/traits are not duck typing. A type statically needs to implement an abstract data type (with its methods and invariants). This is more of a categorization/composition effort.

afaik Rust traits were directly inspired by the typeclass system in Haskell, which came about as a type-safe way to do the kind of ad-hoc polymorphism that you can do with interfaces in object-oriented languages like Java. Here's [1] a good talk by SPJ:

[1] https://channel9.msdn.com/posts/MDCC-TechTalk-Classes-Jim-bu...

On the contrary, the point of type classes/traits is to provide a type-based alternative to simple overloading.

What feature of rust traits make them "dynamic" as opposed to the traditional notion of typed interfaces? The latter had been part of static languages for quite a while.

I'm probably way in over my head with making a good case for how this resembles dynamic languages, but what I had in mind was trait objects. You can box a struct and refer to it as a trait object (aka type erasure). Thereafter, the receiver doesn't care _what_ concrete implementation it gets, just that it implements a certain trait.

What you describe are existential types, a feature that every statically-typed language with parametric polymorphism has, either through some explicit syntactic feature (Rust traits, Haskell type classes, ML modules), or even without, as from basic logic and the Curry–Howard correspondence you can always encode an existential using universals.

         ∃a.P(a)
    ----------------- Remove-Exist
    ∀b.(∀a. P(a)→b)→b

Some static languages had existentials even before they got parametric polymorphism (Go interfaces). This is why we could do so much in Go without generics!

Yeah that's traditional subtyping, not a dynamic language thing at all.

Rust traits are not subtyping, Rust's type system is principal (although with subtyping you could achieve the same thing as described by the OP, e.g. in C++, C#, etc, which only have subtyping but no existentials exposed as a syntactic feature).

The only reason trait objects aren't subtyping is that impl trait is not a first class type in Rust. They behave like subtyping in this context.

Not really traits per se, but std::any::Any is implemented by most Rust types and is pretty dynamic.

Ever heard of &dyn traits?

(that's a joke)

Rust's traits are a copy of Haskell's type classes. They are as far removed from dynamically-typed languages as you can get.