4 ms·

ClojureScript (and the other mentioned languages) really are in a different category than TypeScript. You can think of TypeScript as a linter for JavaScript tha

by Vinnl 5y ago

ClojureScript (and the other mentioned languages) really are in a different category than TypeScript. You can think of TypeScript as a linter for JavaScript that you help by adding some annotations to your JS, rather than an entirely different language. Deno merely strips those annotations for you before executing the remaining JavaScript.

fulafel 5y ago
The TS language semantics would seem to preclude a stripping based implementation, no? Eg generics seem to be a whole new area of semantics [1]. I agree that TS is closer to JS than ClojureScript is, but it seems to me to be its own compiled language with code generation targeting JS. [1] https://www.typescriptlang.org/docs/handbook/2/generics.html https://www.typescriptlang.org/docs/handbook/2/generics.html
- zarzavat 5y ago
  Generics in typescript do not affect codegen, they are only visible to the typechecker. The main typescript features that require specialist codegen for ESNext targets are enums (especially const enums) and namespaces. These were added in the past when typescript was less strict about adding features that affect codegen, if proposed today they would not be accepted as typescript now has a policy of waiting for JavaScript to implement features first.
  - fulafel 5y ago
    What about this article, which says the type level programming features constitute a turing complete system: https://mjj.io/2021/03/29/type-level-programming-in-typescript/ https://mjj.io/2021/03/29/type-level-programming-in-typescri... Edit: ok, it says it affects whether the program will typecheck, so it's consistent with not affecting code generation. (More Turing completeness discussion at https://github.com/Microsoft/TypeScript/issues/14833 https://github.com/Microsoft/TypeScript/issues/14833) Then there are other features that have no equivalent in JS. For example enums. And the handbook talks about what kind of JS they "compile to".
    - Vinnl 5y ago
      See the last paragraph of zarzavat's comment :) They wouldn't be added today, and they aren't widely used any more (they have non-codegen alternatives now). In other words, breaking changes in semantics shouldn't be a worry any more, since the TS team has consciously decided to attempt to avoid them a few years ago.

by Vinnl 5y ago

fulafel 5y ago

The TS language semantics would seem to preclude a stripping based implementation, no? Eg generics seem to be a whole new area of semantics [1]. I agree that TS is closer to JS than ClojureScript is, but it seems to me to be its own compiled language with code generation targeting JS. [1] https://www.typescriptlang.org/docs/handbook/2/generics.html https://www.typescriptlang.org/docs/handbook/2/generics.html

zarzavat 5y ago
Generics in typescript do not affect codegen, they are only visible to the typechecker. The main typescript features that require specialist codegen for ESNext targets are enums (especially const enums) and namespaces. These were added in the past when typescript was less strict about adding features that affect codegen, if proposed today they would not be accepted as typescript now has a policy of waiting for JavaScript to implement features first.
- fulafel 5y ago
  What about this article, which says the type level programming features constitute a turing complete system: https://mjj.io/2021/03/29/type-level-programming-in-typescript/ https://mjj.io/2021/03/29/type-level-programming-in-typescri... Edit: ok, it says it affects whether the program will typecheck, so it's consistent with not affecting code generation. (More Turing completeness discussion at https://github.com/Microsoft/TypeScript/issues/14833 https://github.com/Microsoft/TypeScript/issues/14833) Then there are other features that have no equivalent in JS. For example enums. And the handbook talks about what kind of JS they "compile to".
  - Vinnl 5y ago
    See the last paragraph of zarzavat's comment :) They wouldn't be added today, and they aren't widely used any more (they have non-codegen alternatives now). In other words, breaking changes in semantics shouldn't be a worry any more, since the TS team has consciously decided to attempt to avoid them a few years ago.