<div dir="auto"><div><div class="gmail_extra">I have many concerns about typing. </div></div><div class="gmail_extra" dir="auto"><br></div><div class="gmail_extra" dir="auto"><b>Types are opinionated</b></div><div class="gmail_extra" dir="auto"><b><br></b></div><div class="gmail_extra" dir="auto">Choice of type system significantly affects code that people write. As observed in many codebases, adoption of TypeScript favors object oriented style over functional style.</div><div class="gmail_extra" dir="auto"><br></div><div class="gmail_extra" dir="auto">Choosing type system descending from Java type system is message "creators of language endorse OOP as main JavaScript paradigm". It's fine for TypeScript to take opinionated approach, but it's unlikely with TC39. </div><div class="gmail_extra" dir="auto"><br></div><div class="gmail_extra" dir="auto">If you don't see limitations of eg. TypeScript type system, try to express in its terms: "function takes subclass of Foo as parameter Ctor and returns subclass of Ctor extended by some methods". Not to mention reflection here (think of Bluebird's promisification)... </div><div class="gmail_extra" dir="auto"><br></div><div class="gmail_extra" dir="auto">Functional languages usually provide better type systems, but complexity can be prohibitive. Moreover, I don't know any programming language that combines type system as strong as eg. Idris and object oriented programming. </div><div class="gmail_extra" dir="auto"><br></div><div class="gmail_extra" dir="auto"><b>Runtime type checking</b></div><div class="gmail_extra" dir="auto"><b><br></b></div><div class="gmail_extra" dir="auto">Runtime type checking would incur significant cost on browsers (and JavaScript parse time is already an issue for smartphone CPUs). It's especially important to remember about dynamic nature of JavaScript. TypeScript can rely on assumption that no one creates accessors on Object.prototype or Array prototype, but it's unacceptable for language feature.</div><div class="gmail_extra" dir="auto"><br></div><div class="gmail_extra" dir="auto">Therefore, chance of someone calling Object.defineProperty(Array.prototype, 7,...) requires type checking on every property assignment. There hundreds of ways to screw type system, including changes in inheritance in runtime. </div><div class="gmail_extra" dir="auto"><br></div><div class="gmail_extra" dir="auto"><span style="font-family:sans-serif">foo instanceof Foo; // true </span><br></div><div class="gmail_extra" dir="auto">foo instanceof Foo; // false</div><div class="gmail_extra" dir="auto"><span style="font-family:sans-serif">foo instanceof Foo; // true </span><br></div><div class="gmail_extra" dir="auto"><span style="font-family:sans-serif"><br></span></div><div class="gmail_extra" dir="auto"><span style="font-family:sans-serif">Ups, someone overwritten Function.prototype[Symbol.hasInstance] with () => Math.random() > 0.5.</span></div><div class="gmail_extra" dir="auto"><br></div><div class="gmail_extra" dir="auto"><b>Compilation time type checking</b></div><div class="gmail_extra" dir="auto"><br></div><div class="gmail_extra" dir="auto">Compilation time type checking requires tooling. If language relies on external  tool to strip type definitions, why whole typing can't be left to external tool? External tools can iterate faster than language and can compete. </div><div class="gmail_extra" dir="auto"><br></div><div class="gmail_extra" dir="auto"><b>People hates writing types</b></div><div class="gmail_extra" dir="auto"><b><br></b></div><div class="gmail_extra" dir="auto">That's why C++ have auto, Kotlin have val, and it's  significant reason why dynamically typed languages became popular. <i>Type inference</i> is awesome, but integrating it with existing JavaScript code in backwards compatible way seems to be hard.</div><div class="gmail_extra" dir="auto"><br></div><div class="gmail_extra" dir="auto"><br></div><div class="gmail_extra" dir="auto"><br></div><div class="gmail_extra" dir="auto"><br></div></div>