The cost for this is that programs with type errors must still be specified to have a well-defined semantics. That in turn means that you can't hang useful lang

The cost for this is that programs with type errors must still be specified to have a well-defined semantics. That in turn means that you can't hang useful language features off static types. For example, TypeScript explicitly declares as a design goal that they don't use the type system to generate different code: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi... Meanwhile in Dart, you can write: double d = 1; In Dart, doubles and integers are different types with different representations. The above line of code works because if we see an integer literal in a context where a floating-point number is expected, we implicitly treat it as a double literal. Note that there's no runtime conversion here. We can do this because Dart does have a sound type system and is happy to use it for language features. That's also why Dart (and other statically typed languages) support extension methods while TypeScript does not: https://github.com/microsoft/TypeScript/issues/9#issuecomment-74302592 https://github.com/microsoft/TypeScript/issues/9#issuecommen... If the language gives users the ability to type their code, it's really nice to be able to give them as much value in return for their effort. That means building language features on top of them and using types to generate smaller, faster code. But languages with unsound type systems or that treat programs with type errors as well formed can't really do that.