> Surely that's not the first time you've heard of run-time type casts? Indeed – and for good reason, I'm sure. Pedantically, a cast is where the programmer sa

> Surely that's not the first time you've heard of run-time type casts? Indeed – and for good reason, I'm sure. Pedantically, a cast is where the programmer says in a language "just trust me on what type this is, don't bother to check my claim". A runtime type cast doesn't make any sense. I mean, I'm fine with words evolving and whatnot. I'm not here actually trying to play language police myself. But, as it seems you want to squabble over "duck type", which is then quite humorous when you accept any random definition someone can dream up for "cast": Why not call what Java is doing duck typing? > I hope you would agree they are essentially the same. I do agree, just as I said before, that Go's type conversions are essentially the same, except checked at compile time rather than run time. There is no conversion with type assertions, however. It is merely a runtime type check. The type you have is the type you keep. Now, what is important to remember is that Go's interface is a structural type. And what is a "structural type" checked at run time? That's right: A duck type! > So TFA could be written in any of those languages It's all just 1s and 0s at the end of the day. Of course you can write something that achieves the same result in just about any language. There is more nuance at play here, though. In the case of Go, it is not "here is another way to achieve the same thing". It literally employs duck typing, as duck typing is normally understood.