22 ms·

Rather, I think Typescript's philosophy of not having a runtime is simply wrong. Other statically typed languages retain type information at runtime. I don't

Rather, I think Typescript's philosophy of not having a runtime is simply wrong. Other statically typed languages retain type information at runtime. I don't understand why that was so important to explicitly exclude from Typescript.

nosefurhairdo 3y ago
If we needed a special Typescript runtime to use Typescript it would become nearly useless. The vast majority of Typescript becomes JavaScript running in Node or V8. The web is stuck with JavaScript, and Typescript is a tool to help us write maintainable JavaScript.
- williamcotton 3y ago
  Could’t one write a TypeScript runtime in JavaScript or WASM?
  - kevingadd 3y ago
    It wouldn't be very useful, since a TS-in-JS runtime would have significant performance overhead, and a TS-in-WASM runtime would have very expensive JS interop plus cross-language-GC hurdles. Might be less bad with WASM GC.
    - DonHopkins 3y ago
      Does branding work in AssemblyScript?
  - moritzwarhier 3y ago
    With horrible overhead, and in the case of WASM, lots of serialization and API glueing (DOM is just somewhere near the tip of the iceberg) woes, maybe? Would be a fun thing to do for sure, but never as fast as the APIs built into the browser runtime.
  - DanielHB 3y ago
    Using any JIT language (most implementations of python, Java, ruby, JS, etc) in WASM means porting the runtime to WASM and then having the runtime (in WASM) parse and JIT-compile your code incurring a double-whammy of performance degradation (WASM runtime compiling your JIT language runtime and then your JIT language runtime compiling your actual code). To do this kind of thing viable there are two ways I can think of: 1) proper ahead-of-time compiler for your language targeting WASM directly. But that means pretty much rebuilding the whole stack for the language as that is a completely different approach. 2) Do something like Android Runtime (ART) does which translates Java bytecode to native machine instructions whenever you install an android app. But in this case translate the bytecode to WASM and do it before distribution. This requires a new compiler-backend which is still quite complex. Both of these mean you don't have a language runtime at all. There is a reason most WASM stuff you see is in written C/C++/Rust and it is not just the lack of GC.
recursive 3y ago
Static typing information isn't retained at runtime. e.g. ListInterface list = new ConcreteList(); let runtimeType = GetTypeOf(list); // will be `ConcreteList`, not `ListInterface` This is an imaginary java-like language, but I'm not aware of a statically typed language that gives you the static type resolutions at run-time, outside of cases like implicit generic resolutions and things like that.
vundercind 3y ago
So it’s Just JavaScript and the risk of adopting it is basically zero. It’s the thing that made it an easy sell after everyone got turned off by the long-term experience of Coffeescript and such. It’s the reason various “better” typed languages that run on top of JS have flopped except with enthusiasts.
mason55 3y ago
The decision between structural and nominal typing has nothing to do with whether you retain type information at runtime. TS could have just as easily chosen nominal typing + a simple way to do typedefs and had everything else work like it does now. But structural typing gives you a lot of other useful features.
klysm 3y ago
I disagree. If we had a runtime we'd have to inject that all over the place and compatibility with javascript wouldn't be a given.
Quekid5 3y ago
> Other statically typed languages retain type information at runtime. Funnily enough, Haskell[0] doesn't... unless you ask it to by explicitly asking for it via Typable[1]. [0] ... which is renowned/infamous for its extremely static+strong typing discipline. It is nice that one can opt in via Typeable, but it's very rare to actually need it. [1] https://hackage.haskell.org/package/base-4.19.1.0/docs/Data-Typeable.html https://hackage.haskell.org/package/base-4.19.1.0/docs/Data-...
hpeter 3y ago
Typescript is not a real standalone language. It's just javascript after all. Try Dart, maybe you like it. It's like TS but with it's own runtime.

nosefurhairdo 3y ago

If we needed a special Typescript runtime to use Typescript it would become nearly useless. The vast majority of Typescript becomes JavaScript running in Node or V8. The web is stuck with JavaScript, and Typescript is a tool to help us write maintainable JavaScript.

williamcotton 3y ago
Could’t one write a TypeScript runtime in JavaScript or WASM?
- kevingadd 3y ago
  It wouldn't be very useful, since a TS-in-JS runtime would have significant performance overhead, and a TS-in-WASM runtime would have very expensive JS interop plus cross-language-GC hurdles. Might be less bad with WASM GC.
  - DonHopkins 3y ago
    Does branding work in AssemblyScript?
- moritzwarhier 3y ago
  With horrible overhead, and in the case of WASM, lots of serialization and API glueing (DOM is just somewhere near the tip of the iceberg) woes, maybe? Would be a fun thing to do for sure, but never as fast as the APIs built into the browser runtime.
- DanielHB 3y ago
  Using any JIT language (most implementations of python, Java, ruby, JS, etc) in WASM means porting the runtime to WASM and then having the runtime (in WASM) parse and JIT-compile your code incurring a double-whammy of performance degradation (WASM runtime compiling your JIT language runtime and then your JIT language runtime compiling your actual code). To do this kind of thing viable there are two ways I can think of: 1) proper ahead-of-time compiler for your language targeting WASM directly. But that means pretty much rebuilding the whole stack for the language as that is a completely different approach. 2) Do something like Android Runtime (ART) does which translates Java bytecode to native machine instructions whenever you install an android app. But in this case translate the bytecode to WASM and do it before distribution. This requires a new compiler-backend which is still quite complex. Both of these mean you don't have a language runtime at all. There is a reason most WASM stuff you see is in written C/C++/Rust and it is not just the lack of GC.

recursive 3y ago

Static typing information isn't retained at runtime. e.g. ListInterface list = new ConcreteList(); let runtimeType = GetTypeOf(list); // will be `ConcreteList`, not `ListInterface` This is an imaginary java-like language, but I'm not aware of a statically typed language that gives you the static type resolutions at run-time, outside of cases like implicit generic resolutions and things like that.

vundercind 3y ago

So it’s Just JavaScript and the risk of adopting it is basically zero. It’s the thing that made it an easy sell after everyone got turned off by the long-term experience of Coffeescript and such. It’s the reason various “better” typed languages that run on top of JS have flopped except with enthusiasts.

mason55 3y ago

The decision between structural and nominal typing has nothing to do with whether you retain type information at runtime. TS could have just as easily chosen nominal typing + a simple way to do typedefs and had everything else work like it does now. But structural typing gives you a lot of other useful features.

klysm 3y ago

I disagree. If we had a runtime we'd have to inject that all over the place and compatibility with javascript wouldn't be a given.

Quekid5 3y ago

> Other statically typed languages retain type information at runtime. Funnily enough, Haskell[0] doesn't... unless you ask it to by explicitly asking for it via Typable[1]. [0] ... which is renowned/infamous for its extremely static+strong typing discipline. It is nice that one can opt in via Typeable, but it's very rare to actually need it. [1] https://hackage.haskell.org/package/base-4.19.1.0/docs/Data-Typeable.html https://hackage.haskell.org/package/base-4.19.1.0/docs/Data-...

hpeter 3y ago

Typescript is not a real standalone language. It's just javascript after all. Try Dart, maybe you like it. It's like TS but with it's own runtime.