Nothing about duck typing requires a python-like type system. F# has duck typing via inlining (hacky sorta), C# has it too, but only for compiler use, not end user code (because why build generic features, when you can hack one-offs into the compiler).

It'd be great to have more static duck typing. I suppose that's the point of traits and mixins, to some extent. But it'd be nice to have on-the-fly constraints created and enforced.

I thought that F# used type-inferencing? If not, then its not nearly as similar to Haskell and OCaml as I've been led to believe.

Unless you're referring to type-inferencing when you use the term static duck-typing. The term duck-typing was never meant to refer to type-inferencing - duck-typing is type-opacity right into the runtime. The whole point of duck-typing is that objects can be referred to generically even in cases where their underlying type would be undecidable.

Type-inferencing gives you some of the source-level flexibility of not having to refer directly to an object's type much like duck-typing, but without many of the crazy runtime disasters that you can get with duck-typing.

Parent comment is referencing the "let inline" construction that in addition to inline code allows to constrain generic types structurally over member definition[1] instead of by name as usual. This gives us poor's man type classes which is useful nonetheless.

I guess the conclusion is that the definition of duck typing is fuzzy and misleading.

[1] https://msdn.microsoft.com/en-us/library/dd548046.aspx

C# Actually does have duck typing via the DLR (Dynamic Language Runtime) now. You can totally define a method as

    public dynamic DoDynamicStuff(dynamic wooDynamix)
    {
        Console.WriteLine(wooDynamix.DynamicProperty1);
    }

Right but it doesn't have the static kind the compiler uses for foreach loops or dictionary initializers.