8 ms·

I have a strange take - I think Typescript types are better most other languages, including Java, C++ and Go. It's strange since TypeScript is adding types to a

I have a strange take - I think Typescript types are better most other languages, including Java, C++ and Go. It's strange since TypeScript is adding types to a weakly typed language. If we could push JavaScript performance to be another order of magnitude faster it wouldn't be necessary to use other languages, imho. Of course, pushing it that far without effectively creating a new one would be difficult, to say the least.

mrits 4y ago
That is a strange take. It sounds like you think the reason people don't use Typescript is because of performance and not what some would consider a irresponsible ecosystem of abandoned frameworks and a language that provides little actual safety while still being unpleasant to use.
- quonn 4y ago
  It‘s not strange at all. I think them same. The type system of TypeScript is in practice much more useful than the one of C# or Java. Nothing is abandoned and in any case typically only a small set of libraries is needed which should be carefully picked.
deleted 4y ago
[deleted]
TOGoS 4y ago
Good take if you ask me. When I want to flesh out an ontology, I find that TypeScript's type syntax more natural than anything else. Generally I find it to do an amazing job of bridging between a very expressive and flexible type system and a language that at runtime knows nothing about your types. Want structural/duck typing? No problem; that's the default. Define new interfaces that old classes happen to implement without having to wrap them. I always wanted that feature! Want nominal types? No problem; just declare a field indicating the type name! interface Square { classRef: "http://example.com/Shapes/Square"; width: number; } interface Circle { classRef: "http://example.com/Shapes/Circle"; diameter: number; } type Shape = Circle|Square; (I like to express things in a way that can be easily translated to RDF, hence my use of URIs for type and attribute names) Since TypeScript types don't runtime checks, you can even do it on atomic types! type USDollars = number & { [Symbol.for("http://ns.nuke24.net/Synx/unit")]: "USD" } type CanadianDollars = number & { [Symbol.for("http://ns.nuke24.net/Synx/unit")]: "CAD" } const someAmount : CanadianDollars = someExpressionReturningUsDollars; // Compile error! Try doing that in Java! I OFTEN WISH I COULD
- TOGoS 4y ago
  Addendum to my nominal types: For the 'fake' nominal types (you can't put a symbol on a number!) I like to make those fields optional, which makes the type less of a lie. "If this number did have a [unit symbol] property, the value would be 'USD'". That will still prevent accidental USD <-> CAD conversion, but allows converting to/from regular numbers without explicit casting. A pile of thoughts on the subject from back when I first came up with it: http://www.nuke24.net/plog/32.html http://www.nuke24.net/plog/32.html
  - triyambakam 4y ago
    Very cool
  - liminal 4y ago
    This is really great. I once spent a little time thinking about how to better represent RDF in Type/Javascript. These approaches seem like a good direction to go in. Would love to see these ideas developed further.
  - isleyaardvark 4y ago
    I’ve seen several TS users describe that approach as “branding” (or “flavoring” if it is optional).
smt88 4y ago
After using structural typing in TS, it's very hard to go back to nominal typing.
spion 4y ago
I used to think so too, until I tried Rust. By comparison, JavaScript (and by extension, TypeScript) is still lacking fundamental features and the library ecosystem situation is pretty bad. I wish there was a modern language that took all the good non-manual-memory-management things from Rust and added a GC and some immutable data structures. Error handling, enums, macros (with compile_error! / diagnostics API), traits / approach to OOP, embedded tests, doctests and the relentless determination to add examples in the docs in general... Everything in Rust feels like "oh, they got this right too", which hasn't been the case for any other typed lanuage I've used in the past 15 years (including typescript, my previous favorite; purescript; go; haskell)
- deleted 4y ago
  [deleted]
- jdthedisciple 4y ago
  Have you tried C#? Sounds like it would fit your needs perfectly, additionally benefitting from a huge ecosystem behind it.
  - rrishi 4y ago
    How does the verbosity in C# compare to Java's? And are big C# codebases littered with annotations and "dependency inversion" Java Spring boilerplate-y crap? I ask because I have never delved into C# only heard it's Microsoft's Java. And I am no fan of the original Java at all so C# gives me pause.
    - tester756 4y ago
      We don't do annotation-oriented-programming in C# DI is almost always in web, but via constructor instead of annotations.
    - theshrike79 4y ago
      C# is pretty much Java done right. Speaking as someone who started with Java 1.2 and saw all the crap that happened to it. C# is currently lightyears ahead of Java in every way, especially now that MS is not Micro$oft to people on the internet any more =)
throw_m239339 4y ago
> I have a strange take - I think Typescript types are better most other languages, including Java, C++ and Go. It's strange since TypeScript is adding types to a weakly typed language. Typescript types don't exist at run time, at all. So it's easy to be better when your language is merely about static analysis as it will not enforce any sort of type system during runtime. Java, Go or C++ have different constraints.
- dimitropoulos 4y ago
  that's a false equivocation in the sense that you just moved the goalposts by defining what "runtime" means. There are no types whatsoever as far as processors are concerned. No types in assembly Not for Go or Java, not for C, and not for Rust. All you gotta do is keep compiling.
  - throw_m239339 4y ago
    > that's a false equivocation in the sense that you just moved the goalposts by defining what "runtime" means. I disagree, Javascript does have types and runtime type errors, just not all the ones Typescript compiler has, it makes Typescript extremely leaky as a Javascript abstraction. Typescript compiler cannot represent every single Javascript type combination either, it will would have to be a Javascript interpreter at first place.
  - yencabulator 4y ago
    Runtimes exist above processors, you know. Here's types existing at runtime: https://go.dev/play/p/rc--yVzJ9bt https://go.dev/play/p/rc--yVzJ9bt
- kaba0 4y ago
  To be honest, that’s the “default” way of type systems - without runtime reflection capabilities type erasure is just a normal phase of an AOT compiler, why would you store types?
hackandthink 4y ago
>If we could push JavaScript performance to be another order of magnitude faster And it would speed up the TypeScript Compiler. My bet is: TypeScript typechecker in Rust: https://github.com/dudykr/stc https://github.com/dudykr/stc
- epolanski 4y ago
  TS is implementation-defined, it doesn't have a spec like C or Java. It's simply impossible to keep up with TS for competing compilers.
rr888 4y ago
I agree TS is great. Not really multi threaded kills it for me though.
- jdlshore 4y ago
  Threads are a function of the environment, and are available in TS and other compiles-to-JS languages: Node.js: https://nodejs.org/api/worker_threads.html https://nodejs.org/api/worker_threads.html Browser: https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers... However, threads are very rarely needed. The common use case in other languages is I/O, and JS environments handle that with async I/O—a superior choice, IMO.
  - illiarian 4y ago
    Neither of those are proper threads, and they have various limitations placed on them. And the language and the VM has been, and will be for any foreseeable future, single-threaded.
    - postdb 4y ago
      Deno supports vastly superior threading model (such as green threads). Again depending on what you are coding, threading may not be the best model. Look at Ngnix vs Apache (event driven vs threading).
      - illiarian 4y ago
        > Deno supports vastly superior threading model (such as green threads) Whatever it supports, Javascript-the-language has no concept of threads. And workers are basically external processes with a somewhat awkward event-based communication and certain limitations. Whatever Deno uses internally to implement them has no bearing.
      - 5e92cb50239222b 4y ago
        JFYI, apache httpd has had a similar event-driven request processing module for about 10 years, maybe more. https://httpd.apache.org/docs/2.4/mod/event.html https://httpd.apache.org/docs/2.4/mod/event.html
deleted 4y ago
[deleted]
deleted 4y ago
[deleted]
mekster 4y ago
If performance is the only concern to pick a language, world is far simpler.
treis 4y ago
The jankiness of JS combined with the correctness of TS really is a powerful combo. Especially stuff like string keys and const arrays as enums make safe and readable code without a lot ceremony. The big problem is the gap between TS and JS. User defined typeguards are a usable work around but it would be nice to be able to use a native isMyType function. Also would be nice to have constraints natively in types. Like string lengths or max ints.
- epolanski 4y ago
  You can do all you list with effect-ts/schema. Arguably the highest quality TS lib out there. https://github.com/Effect-TS/schema https://github.com/Effect-TS/schema
  - munbun 4y ago
    this looks like a better documented io-ts
    - epolanski 4y ago
      The author is the same of io-ts and t-comb, but capabilities go well beyond io-ts (including the experimental modules). Being able to generate types, encoders, decoders, apis, guards and even arbitrary data is extremely powerful.
  - iainmerrick 4y ago
    At first glance this looks similar to Zod (which is listed as an influence). What does @effect/schema do differently/better? I feel like the name could use a bit of work for a start! "schema" is way too generic.
    - chatmasta 4y ago
      In our project at work, we've been using superstruct since 2021, but if we started today we'd probably choose Zod. We also use fp-ts, and it looks like effect-ts is a recent project by the same author, which certainly gets my attention.
epolanski 4y ago
Better is hard to qualify but I'll add my 2 cents: - for functional programmers TS offers lots of flexibility and power many other languages including statically typed and pure don't - TS functions or methods that throw don't show up in the type system (they do in Java) I hope TS keeps getting stricter.
iainmerrick 4y ago
One thing I wonder is whether a “strict mode” subset of TS could be compiled to efficient code. Disallow “any” and most of the dynamic and meta programming features of JS so it’s fully typesafe. The type system is really nice, so even without being able to use the full range of JS hacks and escape hatches, I think it’d still be a nice language to work in.
- awestroke 4y ago
  TS by itself is not fully sound which could complicate such a compiler. Example: https://www.typescriptlang.org/play?#code/MYewdgzgLgBAtgTwLIEMAOAxArmYUCW4MAvDABT5QCmcAXDGFnAEZUBOANDCAG7sBmAGxAB3APz1obfGADmAShIA+GAG8AUDBj5+5SjRgqATDABkp7nzZDRMAISlGgwYo1atbKlCxswlgcIiANyaMAC+oZ7evtrUcAB0UCAAylDScmTyIWEhoJCwUAhoVMAo0KiYOHiEYPQUcfSMLOyKxCpSMrIk8Mjo2LgE4Lng0DCeEFiCsKQA2gCMHEYcAMwAuvFw6GSFxaXlfVWDYFkwAPSnMDtUEMDSaLAQKAgQlwAW+C8fMACCbGxPAB4OnIlFxmFhYJQYCJ8M4YKwYCh4PgAB7cXTA2QvFBgAAmDCYrDYEHUQA https://www.typescriptlang.org/play?#code/MYewdgzgLgBAtgTwLI... In the example above, the problem is that typescript allows casting function types to omit optional arguments, and also allows using a function with n arguments as a value where a function with >n arguments is expected
  - iainmerrick 4y ago
    Yes, those sorts of loopholes would need to be closed. I was imagining a subset of the language, but there might need to be some breaking changes to cover cases like that. Maybe it would end up being so different that it would be an entirely different language? I don't know! But it's hard for me to accept that non-soundness in TS is necessary for TS itself rather than just an unfortunate consequence of the JS language and library that it has to build on top of.

mrits 4y ago

That is a strange take. It sounds like you think the reason people don't use Typescript is because of performance and not what some would consider a irresponsible ecosystem of abandoned frameworks and a language that provides little actual safety while still being unpleasant to use.

quonn 4y ago
It‘s not strange at all. I think them same. The type system of TypeScript is in practice much more useful than the one of C# or Java. Nothing is abandoned and in any case typically only a small set of libraries is needed which should be carefully picked.

deleted 4y ago

[deleted]

TOGoS 4y ago

Good take if you ask me. When I want to flesh out an ontology, I find that TypeScript's type syntax more natural than anything else. Generally I find it to do an amazing job of bridging between a very expressive and flexible type system and a language that at runtime knows nothing about your types. Want structural/duck typing? No problem; that's the default. Define new interfaces that old classes happen to implement without having to wrap them. I always wanted that feature! Want nominal types? No problem; just declare a field indicating the type name! interface Square { classRef: "http://example.com/Shapes/Square"; width: number; } interface Circle { classRef: "http://example.com/Shapes/Circle"; diameter: number; } type Shape = Circle|Square; (I like to express things in a way that can be easily translated to RDF, hence my use of URIs for type and attribute names) Since TypeScript types don't runtime checks, you can even do it on atomic types! type USDollars = number & { [Symbol.for("http://ns.nuke24.net/Synx/unit")]: "USD" } type CanadianDollars = number & { [Symbol.for("http://ns.nuke24.net/Synx/unit")]: "CAD" } const someAmount : CanadianDollars = someExpressionReturningUsDollars; // Compile error! Try doing that in Java! I OFTEN WISH I COULD

TOGoS 4y ago
Addendum to my nominal types: For the 'fake' nominal types (you can't put a symbol on a number!) I like to make those fields optional, which makes the type less of a lie. "If this number did have a [unit symbol] property, the value would be 'USD'". That will still prevent accidental USD <-> CAD conversion, but allows converting to/from regular numbers without explicit casting. A pile of thoughts on the subject from back when I first came up with it: http://www.nuke24.net/plog/32.html http://www.nuke24.net/plog/32.html
- triyambakam 4y ago
  Very cool
- liminal 4y ago
  This is really great. I once spent a little time thinking about how to better represent RDF in Type/Javascript. These approaches seem like a good direction to go in. Would love to see these ideas developed further.
- isleyaardvark 4y ago
  I’ve seen several TS users describe that approach as “branding” (or “flavoring” if it is optional).

smt88 4y ago

After using structural typing in TS, it's very hard to go back to nominal typing.

spion 4y ago

I used to think so too, until I tried Rust. By comparison, JavaScript (and by extension, TypeScript) is still lacking fundamental features and the library ecosystem situation is pretty bad. I wish there was a modern language that took all the good non-manual-memory-management things from Rust and added a GC and some immutable data structures. Error handling, enums, macros (with compile_error! / diagnostics API), traits / approach to OOP, embedded tests, doctests and the relentless determination to add examples in the docs in general... Everything in Rust feels like "oh, they got this right too", which hasn't been the case for any other typed lanuage I've used in the past 15 years (including typescript, my previous favorite; purescript; go; haskell)

deleted 4y ago
[deleted]
jdthedisciple 4y ago
Have you tried C#? Sounds like it would fit your needs perfectly, additionally benefitting from a huge ecosystem behind it.
- rrishi 4y ago
  How does the verbosity in C# compare to Java's? And are big C# codebases littered with annotations and "dependency inversion" Java Spring boilerplate-y crap? I ask because I have never delved into C# only heard it's Microsoft's Java. And I am no fan of the original Java at all so C# gives me pause.
  - tester756 4y ago
    We don't do annotation-oriented-programming in C# DI is almost always in web, but via constructor instead of annotations.
  - theshrike79 4y ago
    C# is pretty much Java done right. Speaking as someone who started with Java 1.2 and saw all the crap that happened to it. C# is currently lightyears ahead of Java in every way, especially now that MS is not Micro$oft to people on the internet any more =)

throw_m239339 4y ago

> I have a strange take - I think Typescript types are better most other languages, including Java, C++ and Go. It's strange since TypeScript is adding types to a weakly typed language. Typescript types don't exist at run time, at all. So it's easy to be better when your language is merely about static analysis as it will not enforce any sort of type system during runtime. Java, Go or C++ have different constraints.

dimitropoulos 4y ago
that's a false equivocation in the sense that you just moved the goalposts by defining what "runtime" means. There are no types whatsoever as far as processors are concerned. No types in assembly Not for Go or Java, not for C, and not for Rust. All you gotta do is keep compiling.
- throw_m239339 4y ago
  > that's a false equivocation in the sense that you just moved the goalposts by defining what "runtime" means. I disagree, Javascript does have types and runtime type errors, just not all the ones Typescript compiler has, it makes Typescript extremely leaky as a Javascript abstraction. Typescript compiler cannot represent every single Javascript type combination either, it will would have to be a Javascript interpreter at first place.
- yencabulator 4y ago
  Runtimes exist above processors, you know. Here's types existing at runtime: https://go.dev/play/p/rc--yVzJ9bt https://go.dev/play/p/rc--yVzJ9bt
kaba0 4y ago
To be honest, that’s the “default” way of type systems - without runtime reflection capabilities type erasure is just a normal phase of an AOT compiler, why would you store types?

hackandthink 4y ago

>If we could push JavaScript performance to be another order of magnitude faster And it would speed up the TypeScript Compiler. My bet is: TypeScript typechecker in Rust: https://github.com/dudykr/stc https://github.com/dudykr/stc

epolanski 4y ago
TS is implementation-defined, it doesn't have a spec like C or Java. It's simply impossible to keep up with TS for competing compilers.

rr888 4y ago

I agree TS is great. Not really multi threaded kills it for me though.

jdlshore 4y ago
Threads are a function of the environment, and are available in TS and other compiles-to-JS languages: Node.js: https://nodejs.org/api/worker_threads.html https://nodejs.org/api/worker_threads.html Browser: https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers... However, threads are very rarely needed. The common use case in other languages is I/O, and JS environments handle that with async I/O—a superior choice, IMO.
- illiarian 4y ago
  Neither of those are proper threads, and they have various limitations placed on them. And the language and the VM has been, and will be for any foreseeable future, single-threaded.
  - postdb 4y ago
    Deno supports vastly superior threading model (such as green threads). Again depending on what you are coding, threading may not be the best model. Look at Ngnix vs Apache (event driven vs threading).
    - illiarian 4y ago
      > Deno supports vastly superior threading model (such as green threads) Whatever it supports, Javascript-the-language has no concept of threads. And workers are basically external processes with a somewhat awkward event-based communication and certain limitations. Whatever Deno uses internally to implement them has no bearing.
    - 5e92cb50239222b 4y ago
      JFYI, apache httpd has had a similar event-driven request processing module for about 10 years, maybe more. https://httpd.apache.org/docs/2.4/mod/event.html https://httpd.apache.org/docs/2.4/mod/event.html

deleted 4y ago

[deleted]

deleted 4y ago

[deleted]

mekster 4y ago

If performance is the only concern to pick a language, world is far simpler.

treis 4y ago

The jankiness of JS combined with the correctness of TS really is a powerful combo. Especially stuff like string keys and const arrays as enums make safe and readable code without a lot ceremony. The big problem is the gap between TS and JS. User defined typeguards are a usable work around but it would be nice to be able to use a native isMyType function. Also would be nice to have constraints natively in types. Like string lengths or max ints.

epolanski 4y ago
You can do all you list with effect-ts/schema. Arguably the highest quality TS lib out there. https://github.com/Effect-TS/schema https://github.com/Effect-TS/schema
- munbun 4y ago
  this looks like a better documented io-ts
  - epolanski 4y ago
    The author is the same of io-ts and t-comb, but capabilities go well beyond io-ts (including the experimental modules). Being able to generate types, encoders, decoders, apis, guards and even arbitrary data is extremely powerful.
- iainmerrick 4y ago
  At first glance this looks similar to Zod (which is listed as an influence). What does @effect/schema do differently/better? I feel like the name could use a bit of work for a start! "schema" is way too generic.
  - chatmasta 4y ago
    In our project at work, we've been using superstruct since 2021, but if we started today we'd probably choose Zod. We also use fp-ts, and it looks like effect-ts is a recent project by the same author, which certainly gets my attention.

epolanski 4y ago

Better is hard to qualify but I'll add my 2 cents: - for functional programmers TS offers lots of flexibility and power many other languages including statically typed and pure don't - TS functions or methods that throw don't show up in the type system (they do in Java) I hope TS keeps getting stricter.

iainmerrick 4y ago

One thing I wonder is whether a “strict mode” subset of TS could be compiled to efficient code. Disallow “any” and most of the dynamic and meta programming features of JS so it’s fully typesafe. The type system is really nice, so even without being able to use the full range of JS hacks and escape hatches, I think it’d still be a nice language to work in.

awestroke 4y ago
TS by itself is not fully sound which could complicate such a compiler. Example: https://www.typescriptlang.org/play?#code/MYewdgzgLgBAtgTwLIEMAOAxArmYUCW4MAvDABT5QCmcAXDGFnAEZUBOANDCAG7sBmAGxAB3APz1obfGADmAShIA+GAG8AUDBj5+5SjRgqATDABkp7nzZDRMAISlGgwYo1atbKlCxswlgcIiANyaMAC+oZ7evtrUcAB0UCAAylDScmTyIWEhoJCwUAhoVMAo0KiYOHiEYPQUcfSMLOyKxCpSMrIk8Mjo2LgE4Lng0DCeEFiCsKQA2gCMHEYcAMwAuvFw6GSFxaXlfVWDYFkwAPSnMDtUEMDSaLAQKAgQlwAW+C8fMACCbGxPAB4OnIlFxmFhYJQYCJ8M4YKwYCh4PgAB7cXTA2QvFBgAAmDCYrDYEHUQA https://www.typescriptlang.org/play?#code/MYewdgzgLgBAtgTwLI... In the example above, the problem is that typescript allows casting function types to omit optional arguments, and also allows using a function with n arguments as a value where a function with >n arguments is expected
- iainmerrick 4y ago
  Yes, those sorts of loopholes would need to be closed. I was imagining a subset of the language, but there might need to be some breaking changes to cover cases like that. Maybe it would end up being so different that it would be an entirely different language? I don't know! But it's hard for me to accept that non-soundness in TS is necessary for TS itself rather than just an unfortunate consequence of the JS language and library that it has to build on top of.