Optional typing like the one we see here is not uncommon in other dynamic languages: For instance, Clojure has core.typed and prismatic schema, which approach the problem in ways related to what the article shows.<p>However, while optional typing gives you some benefits over purely dynamic typing, the fact that it&#x27;s all bolted-on causes a variety of problems. First, there&#x27;s the fact that you&#x27;ll have code with types interact with code without them. This eventually causes more trouble than it solves.<p>IMO, the biggest issue though is that what we really see from most of these systems is to add optional type systems that are comparable to very simple type systems, like Java&#x27;s. But those strongly typed systems are not really that powerful! The real power of static typing doesn&#x27;t come from being able to make sure we don&#x27;t mix strings and integers, but in doing type checking for much more complex abstractions. Type systems like Scala&#x27;s, or Haskell&#x27;s. Creating an optional typing linter that looks at that high a level, and doesn&#x27;t cause much of pain, is not something I&#x27;ve ever seen. Type inference with generics, existential types, higher kinded types, algebraic types. That&#x27;s where the real value is, and where modern typed languages are.<p>Aiming optional typing at where typed languages were 20 years ago is not going to help bridge the gap. If anything, I think it makes it wider, because then fans of dynamic languages think they understand the position of proponents of type systems when, in fact, they are looking at a strawman from the past.