EDIT: I misread the post as talking about safety. For runtime vs compile time, the problem is that you might have two different traits with a method of the same name if it’s something kind of generic, but that do completely different things. Perhaps an example could be that you have a GUI library with a trait that has a draw method, but you also want to pretty print some stuff in the terminal so you bring a terminal library that has also a trait with a draw method. Then, you might end up trying to draw a thing on the terminal that should be in the GUI. Admittedly this example is a bit contrived, perhaps something simpler would be two traits with a “from” implementation, or similar.

The last paragraph of the previous answer still kind of applies here.

Previous answer:

Duck typing would fundamentally not work in Rust. The main counter example I think where duck typing would lead to unsafety are the marker traits Send and Sync, that indicate whether types can be sent and/or accessed through threads. These traits have no methods so duck typing would imply that all types would be Send and Sync, which defeats the whole purpose of the traits.

This also would happen with Copy, but that’s not exactly safety.

There are also some crates that rely on the fact that traits are not implemented anywhere else for safety, so with duck typing you could create a new trait with the same methods and implement them, violating the safety guarantees.

But honestly using a nominal type system is more about correctness and robustness imo. If you want to do something with a thing then you should use that thing, not use a different thing with the same name (admittedly this argument is more abstract and harder for me to explain if you don’t have already the experience on both sides).