[hajile]

Optimizing is possible even in those cases. A JIT usually runs a function hundreds of times to collect type data before attempting to optimize the function. Types can be used to pre-fill that type data. The JIT can then optimize immediately, but still bailout if the wrong types show up in the future. I wouldn't think such an approach would yield huge benefits overall (the most used code will be optimizing pretty quickly anyway), but on server apps, it could speed up edge-case behaviors a bit.

Another feature of even optional types is creating uniformity to allow JIT optimization. A great real-world example of this is Typescript or ReasonML. It's converted to JS, but still winds up faster on average. The JS JITs have multiple tiers of optimization. Changing data types and function signatures are the biggest performance killers. If you can ensure a list is always strings or numbers, then the optimizer can reach the top tier of optimization. When lots of people work together on untyped languages, there tend to be small changes in the signatures and structures that drop you out of that top optimization level. Even partial types are useful for preventing this.

Related to that is the potential for runtime type warnings. Even though the types aren't used by the JIT, it should be possible to give a warning message if the received types don't match up. That could be a huge assistance in finding where a bug is located.