I was reading up on the Go programming language, specifically the language design FAQ (http://golang.org/doc/go_lang_faq.html) and it got me thinking again about duck-typing (signature based polymorphism). 

First, I have to strongly recommend that all programmers carefully read the Go language design FAQ. It is a glimpse into the kinds of issues that programming languages designed for the future are going to be doing in the face of rapidly increasing parallelism. The people designing this language, really know what they are doing in many respects, especially when it comes to concurrency.  

One thing about the FAQ that intrigued me was the level of excitement over signature based polymorphism (duck-typing). This is clearly one of the most exciting features from the point of view of the language designers (who are also using the language extensively). 

In the past I talked myself out of using duck-typing for Heron because I liked the explicit information carried in a class about what it is intended use is for. I was also scared of the possibility of accidentally using classes where the behavior did not match what was expected. Think of the case of a FIFO queue versus a LIFO queue. 

Now that I think about it though, I think that perhaps I was just being overly cautious. I realize that I frequently using C++ templates as a poor-man's duck-typing. 

Perhaps I should throw caution to the wind, and embrace duck-typing fully? Or maybe I should take a middle of the road approach and provide a form of explicit duck-typing via a duck-typing coercion operator. E.g. "MyFunction(Dog as IInternetUser)". 

So what are your thoughts, would you want duck-typing in a language intended for engineering large-scale complex software developed by big teams of developers? Would you like a "duck-typing" coercion operator, and if so what would you name it?