I'm not sure if this is what you're talking about, but if you want to see an example of "runtime casting and duck typing" in Go, have a look at my torrent track

I'm not sure if this is what you're talking about, but if you want to see an example of "runtime casting and duck typing" in Go, have a look at my torrent tracker project: https://github.com/drbawb/babou/blob/master/app/filters/flash.go#L109 https://github.com/drbawb/babou/blob/master/app/filters/flas... What I've linked to is a filter that gets put in front of a controller. -- To keep some modicum of type-safety while making use of interfaces, I've added these TestContext() methods to my interface. Basically, when a controller is registered with one of these chains, the entire chain is checked to make sure that its dependencies are satisfied. (For example, this "flash" filter requires the "session" chain, because it uses session storage for the message being displayed to the user.) The controller has a similar test; and these runtime penalties are only incurred once when the route is registered. So the app will panic immediately if the types needed for the chain to work aren't present. It actually works out quite nicely: but you _need_ to write these tests or it falls flat on its face. -- I like to approach it as a form of test-driven development whenever I add a new filter or controller.