4 ms·

This is a mischaracterization of TypeScript. Unlike the relationship of C++ to C, TS is explicitly not a separate language from JS, and introduces no new capabi

by wrs 1y ago

This is a mischaracterization of TypeScript. Unlike the relationship of C++ to C, TS is explicitly not a separate language from JS, and introduces no new capabilities. There’s no engine that executes TypeScript. It doesn’t do anything (*) that JavaScript doesn’t do. It just layers a type system onto JavaScript so you can tell when your JS code doesn’t make sense. (*) with small exceptions like enums, which some think were a mistake for that reason

winrid 1y ago
Yeah but it could be, as the runtime could take advantage of the type defs.
- wrs 1y ago
  So much of the TS type system is just there to capture all the weird things you can do in JS. If you just wanted a new strongly typed dynamic language, I don't think TS is what you'd come up with. It is designed for a very large, but unique, niche domain, and that domain already has some incredibly optimized runtimes.
  - winrid 1y ago
    I wouldn't come up with a new language. I would use TS and use the types to optimize runtime decisions like using numbers to index arrays, without having to carry extra info about the number, and so on. I would change nothing except the runtime. Are you somehow arguing that's bad?
    - wrs 1y ago
      TS complains if it sees you trying to index a T[] with a non-integer. But there's nothing in the JS language that represents that T[] type annotation. So there's no way for the runtime to do that check. If you want to make that work, you'll have to invent a bunch of runtime type machinery and define it. The resulting combination of a subset of JS, TS, and whatever you had to invent to glue it together at runtime will be neither JS nor TS, it will be a new language (with, certainly, a family history). Also, every high-performance JS runtime already knows that you're only indexing that object with integers and already optimizes it without you telling it to.

by wrs 1y ago

winrid 1y ago

Yeah but it could be, as the runtime could take advantage of the type defs.

wrs 1y ago
So much of the TS type system is just there to capture all the weird things you can do in JS. If you just wanted a new strongly typed dynamic language, I don't think TS is what you'd come up with. It is designed for a very large, but unique, niche domain, and that domain already has some incredibly optimized runtimes.
- winrid 1y ago
  I wouldn't come up with a new language. I would use TS and use the types to optimize runtime decisions like using numbers to index arrays, without having to carry extra info about the number, and so on. I would change nothing except the runtime. Are you somehow arguing that's bad?
  - wrs 1y ago
    TS complains if it sees you trying to index a T[] with a non-integer. But there's nothing in the JS language that represents that T[] type annotation. So there's no way for the runtime to do that check. If you want to make that work, you'll have to invent a bunch of runtime type machinery and define it. The resulting combination of a subset of JS, TS, and whatever you had to invent to glue it together at runtime will be neither JS nor TS, it will be a new language (with, certainly, a family history). Also, every high-performance JS runtime already knows that you're only indexing that object with integers and already optimizes it without you telling it to.