>Pre- and post-checks are of course possible, but I've rarely seen them used in practice.

I agree, I wish more people (especially Javascript developers) saw the value of pre (and post!) checking.

>The reason I call it one of the biggest advancements is that it is actually being used in production, has low overhead (both in cognitive load and performance-wise), and actually handles the complexities of duck-typing. It shows that it is practical. (By contrast, Erlang is sufficiently different to most other dynamic languages, both in use case and semantics, that it is difficult to generalize from Erlang to say Python).

This is fair, I just meant to point out that conceptually this isn't new, it's just a new implementation. Can you expand a bit on what you said about duck-typing?

So most type checking, especially in how people write pre- and post-checks, is of the form "is this an X", for example, "is this object an instance of the String class". In duck-typed languages, that's not good enough, because you're not passing an instance of a subclass of a string, you're passing "something that quacks like a string" (aka implements the necessary interfaces to act string-like).

So the type of an object in a duck-typed language is based on the functions and fields it has _now_, not its instance type. Since there is no name for that type, you cannot do "nominal" typing. Instead, you must use "structural" typing, which checks its structure. This is exactly what Typed Clojure does.

An example of how that works in practice, is you say that the 2nd parameter must be a map with one of the following configurations: a key named :foo and a key named :bar, both mapping to strings, or a key named :error, mapping to a string.