I would point out that there is a special syntax / api when you deference “any” in Go. And you are explicitly prompted by the language to consider the case where you receive an unexpected type.

I think this is an important detail, because it’s way safer than in C, where you can just re-interpret memory accidentally and the compiler won’t stop you. Go will panic the thread. Ok, but we already knew that.

The subtle bit is that it’s even a bit safer than most dynamic languages like Python. Because the programmer has to explicitly handle the “unexpected type” case. And because of how verbose Go’s error handling is, every caller up the stack has to consider the error, enforced by the type system. This is different than in Python, where every variable is type any at compiler time, so every line can throw a time error and the callers probably don’t handle it. Even when using “any”, Go’s type system enforces that both the caller and callee consider the “unexpected variable type case”. Overall, it’s still way more of a controlled failure compared to dynamic languages.

It’s great that Go has generics now, to do away with some any hacks. And in general you should avoid any in Go. But when you need it, I think Go actually has a really great reflection API (especially with how it composes with other features like error handling). It’s a bit looked over I think because the difference is subtle at first glance.