Yes, everything can be a type error (security, memory management, concurrency (deadlocks), ...). You define properties about the code and you can check them eit

Yes, everything can be a type error (security, memory management, concurrency (deadlocks), ...). You define properties about the code and you can check them either at runtime, or statically. If I choose to write in OCaml, the memory management is done with a GC, which relies on dynamically typed memory; but I write in Rust, there is no GC but a kind of static analysis for managing ownership; both approaches work. Your fallacy is saying: there is a whole class of errors that can avoided if only we use a different type system, so there is no point in using that type system which defers (some or all) checks at runtime. I can write code that manipulates values which represent types in the language, at runtime. If the types happen to be known or declared during compilation, fine enough, they can be optimized away. Otherwise, they will be checked later (which transparently invokes dynamic dispatch if needed), and I can even use them once they are known to compile the code myself, on a closure; there, along with other values which are then known, they can be taken into account to perform more aggressive optimizations. Why don't all language provide this? As for bugs or errors, if you cannot lower risks (with static guarantees) then you have to improve on fault tolerance. You take other approaches to ensure the system behaves well, even if some parts can fail (e.g. Erlang).