"Faster but weaker" refers to the way these languages enforce types at the boundaries to untyped code:
Deep TR (#lang typed/racket) enforces types with contracts, which may add a huge run-time cost but always protect against miscommunications.
Shallow TR (#lang typed/racket/shallow) enforces types with shape checks, which run quickly but detect only big mistakes --- e.g., expected a list, got a string. Very useful for typed scripts that interact with untyped libraries.
Optional TR (#lang typed/racket/optional) enforces types with ... nothing! Types are checked statically and are not enforced at run-time.
Does this mean that libs heavily using typed/racket, such as math/array might become usable from plain racket by just changing the #lang line at the top of every lib file? @soegaard, could we finally be removing the 50x performance penalty warning soon?
Optional types cannot detect incorrect type assumptions and therefore do not enable type-driven optimizations
Would it be possible to apply optimizations by assuming the type signatures are correct?
One use is for timing: By converting one "hot spot" module and adding only annotations for anything else, you would get full TR optimizations and no contract slowdown. So you could measure the "best-case" scenario when deciding whether to convert a whole project to TR.
The downside: Optimized Optional TR could cause a segfault by e.g. an unsafe-vector-ref being applied to a list that somebody claims is a vector. At least it's now easy to change to shallow/deep for debugging. But that might not be enough in a security context(Racket websites exposed to the general internet, or a Discord bot that evaluates arbitrary code), so maybe hide it behind an option?