We're not talking about monolithic, do-everything, hacky classes. You could do the same thing in C#.

Static languages (usually) force you to use interfaces and sub-typing just so common code can be reused. Duck typing is a much nicer way of working - without having to jump through seemingly unnecessary hoops. The situation is even worse when you code for testability. Things that really shouldn't have an interface now require one, so you can mock out the object appropriately. This is all avoided in a language with duck typing.

This is actually where Go has a great impact. You get your static type checking without being forced to use explicit interfaces. It essentially uses duck typing for interface implementation.

You're free to enjoy static typing over dynamic typing all you like - but you shouldn't make the mistake of thinking dynamic typing is inferior in any way. It is different - just like imperative vs functional is different. You make a series of tradeoffs, that is all.

C# supports duck typing though:

http://en.wikipedia.org/wiki/Duck_typing#In_C.23

Yes, but it's not idiomatic C#. The point I've been trying to make is that both kinds of languages (dynamic and static) have their different virtues. You can drop down to dynamic in C#, but unless you have a very good reason, your co-workers will lynch you.

Makes sense.