6 ms·

> we all just wanted java with JIT, more feature rich type system Java has JIT. How is TypeSript type system feature-richer than the Java one?

by zx8080 2y ago

VMG 2y ago
1. *Type Inference*: TypeScript can automatically infer types from context, reducing the need for explicit type declarations. 2. *Union and Intersection Types*: Allows combining multiple types, offering more flexibility in defining data structures. 3. *Literal Types*: TypeScript supports exact values as types (e.g., specific strings or numbers), which can be useful for more precise type-checking. 4. *Type Aliases*: You can create custom, reusable types, enhancing code clarity and maintainability. 5. *Interfaces and Structural Typing*: Interfaces allow for flexible contracts, and TypeScript uses structural typing, where the type compatibility is based on the shape of the data rather than explicit type declarations. 6. *Mapped and Conditional Types*: These allow for dynamic type creation and manipulation, making the type system more powerful and expressive. 7. *Optional Properties and Strict Null Checks*: These provide better handling of undefined and null values.
- tpm 2y ago
  That's just an copy-paste of some features, not a comparison with Java which does most of that too.
  - afiori 2y ago
    Union types, structural typing, and conditional types are like a big chunck of what makes typescript typescript. It is how TS is able to "type" a completely untyped language. Just the support for union types is something that not even Haskell or Ocaml have.
    - nequo 2y ago
      I am not familiar with TypeScript. Is there something that you can achieve with union types that you can’t with sum types or type classes in Haskell?
      - afiori 2y ago
        TL;DR: Typescript is unsound so it can add a lot more type-level features that would make a sound type system undecidable Conceptually no, almost every useful union type can be easily converted to a sum type. In my opinion the difference is in the ergonomics and in the implicit structural subtyping. For example a common union type is number|string, and the beatiful part is that to use a value of such a type you do not need to do any matching or mapping you can just use the value as it does not have a runtime wrapper, for example (x:string|number)=>JSON.stringify(x) works perfectly fine. Also you can have a function that takes as input a Array<string>|number|null and returns a string|number without having to declare different contructors for the input number type and the output number type I believe that you can essentially implement this behaviour by generating enough typeclasses in Haskell, but regardless of the feasibility it, likely, would not be a good idea. An example of something in between union types an Hindley–Milner sum types are Ocaml's polymorphic variants types https://ocaml.org/manual/5.2/types.html#sss:typexpr-polyvar https://ocaml.org/manual/5.2/types.html#sss:typexpr-polyvar that are (I believe) more advanced than TS unions but also a lot less ergonomic to use. And TS has much more eg intersection types you could have a function with type (x:number)=>string & (x:string)=>number meaning that it is both a function that maps number to strings and strings to numbers (again you can do this with typeclasses but it is a worse experience) typescript also has very good support for value types for example there is the string type but also the "hello" type which is the type of only the string "hello" All in all if someone told me that they implemented typescript in haskell typeclasses I would not call bullshit on them, but I would not believe that anyone would actually use it for anything
        tpm 2y ago
        > For example a common union type is number|string So that's like my beloved Perl then.
  - wetpaws 2y ago
    [dead]
  - VMG 2y ago
    most of that? name one
    - tpm 2y ago
      Java has type inference. Also if a type alias is just a new name for a existing type, then you can always do something like class MyNewClass extends OldClass {}; (of course it's not just a new name, it's also a new class, but it's also still a OldClass, and you are out of luck if OldClass is final or sealed) Java also has interfaces, of course. And optional properties (using Optional) and strict null checks, when you want that, you can use it.
      - guipsp 2y ago
        Using optional still has the secret third thing problem
      - VMG 2y ago
        > type inference very limited, for instance you must declare the type of a public method > alias as you point out it's not > Java also has interfaces, of course but you have to implement them explicitly > strict null checks, when you want that, you can use it if we start accepting static analysis tools then C has null checks as well I guess
        tpm 2y ago
        > as you point out it's not so what's the difference except the name? > if we start accepting static analysis tools I'm not talking about static analysis. In today's Java you can write code that does not accept nulls, if you want to.
        svieira 2y ago
        You cannot write code that will fail to compile `theEntryMethod(null)` unless you only use primitive types. (You can, of course, make that method fail at runtime, but that's not what's being talked about here).
wiseowise 2y ago
https://www.typescriptlang.org/docs/handbook/2/types-from-types.html https://www.typescriptlang.org/docs/handbook/2/types-from-ty... https://www.typescriptlang.org/docs/handbook/2/template-literal-types.html https://www.typescriptlang.org/docs/handbook/2/template-lite... alone puts TS over anything that Java has.
- DarkNova6 2y ago
  > alone puts TS over anything that Java has. Virtual Threads alone challenge this assumption. Syntax bloat is not a feature.
  - deleted 2y ago
    [deleted]
  - Byamarro 2y ago
    It's not really a syntax bloat, the linked docs mention how to define strict string types and elaborate on type-level programming, something that is a very rare and powerful type-level capability. As far as I understand Virtual Threads aren't type oriented feature, which is basically the context for this thread.
  - 3836293648 2y ago
    Virtual Threads are not a type system feature?
- deleted 2y ago
  [deleted]
magnio 2y ago
I don't use them directly much, but template literal generic and contidiontal types is probably the closest a mainstream language has inched towards dependent types. Some examples of TypeScript power: - SQL database in TypeScript types: https://github.com/codemix/ts-sql https://github.com/codemix/ts-sql - Statically typed raw SQL queries: https://github.com/andywer/squid?tab=readme-ov-file#tag-function https://github.com/andywer/squid?tab=readme-ov-file#tag-func... - (Someone fill in your TS hackery for me)
- Vaguely2178 2y ago
  There are various programming language interpreters that run entirely in the type system: - BF: https://github.com/susisu/typefuck https://github.com/susisu/typefuck - Assembly: https://github.com/judehunter/ts-asm https://github.com/judehunter/ts-asm
yen223 2y ago
Java and Typescript have fundamentally different type systems, that lead to drastically different ways to approach types. Utility types, like Partial<T>, are basically impossible to represent in Java except with almost-duplicated classes.
- tpm 2y ago
  > drastically different ways to approach types Exactly. > Partial<T> Looking at that it's just what a default POJO (with nullable properties) already is, so I'd see no need to represent that in Java. Looks cool though and I like Typescript; my issue with it is that it needs transpiling to run. If it was a first-class citizen in an environment I would use it for my pet projects.
  - crabmusket 2y ago
    > it's just what a default POJO (with nullable properties) already is I think you missed the point. Partial<T> is an example of a "mapped type", see the handbook for more explanation: https://www.typescriptlang.org/docs/handbook/2/mapped-types.html https://www.typescriptlang.org/docs/handbook/2/mapped-types....
    - tpm 2y ago
      I understand that much, just thinking aloud what problem would that solve in Java.
      - scotty79 2y ago
        I think it's for when you need type that expresses partial data update for an object that has some fields required.
  - svieira 2y ago
    Yep - all non-primitive types in Java are `TheType | null` - TypeScript actually allows you to strip out the `| null`, which then means that sometimes you want to add it back in. So Java doesn't have a need for `Partial<T>`, it has a need for `NonNull<T>` and it can't express that at the type system level very easily right now (you can do it with type tagging and runtime checks inserted explicitly, but it's not very ergonomic right now) https://gist.github.com/svieira/9f8beeafb7bf4aa55d40c638532f4fd7 https://gist.github.com/svieira/9f8beeafb7bf4aa55d40c638532f...

> we all just wanted java with JIT, more feature rich type system Java has JIT. How is TypeSript type system feature-richer than the Java one?

by zx8080 2y ago

> we all just wanted java with JIT, more feature rich type system Java has JIT. How is TypeSript type system feature-richer than the Java one?

VMG 2y ago

1. *Type Inference*: TypeScript can automatically infer types from context, reducing the need for explicit type declarations. 2. *Union and Intersection Types*: Allows combining multiple types, offering more flexibility in defining data structures. 3. *Literal Types*: TypeScript supports exact values as types (e.g., specific strings or numbers), which can be useful for more precise type-checking. 4. *Type Aliases*: You can create custom, reusable types, enhancing code clarity and maintainability. 5. *Interfaces and Structural Typing*: Interfaces allow for flexible contracts, and TypeScript uses structural typing, where the type compatibility is based on the shape of the data rather than explicit type declarations. 6. *Mapped and Conditional Types*: These allow for dynamic type creation and manipulation, making the type system more powerful and expressive. 7. *Optional Properties and Strict Null Checks*: These provide better handling of undefined and null values.

tpm 2y ago
That's just an copy-paste of some features, not a comparison with Java which does most of that too.
- afiori 2y ago
  Union types, structural typing, and conditional types are like a big chunck of what makes typescript typescript. It is how TS is able to "type" a completely untyped language. Just the support for union types is something that not even Haskell or Ocaml have.
  - nequo 2y ago
    I am not familiar with TypeScript. Is there something that you can achieve with union types that you can’t with sum types or type classes in Haskell?
    - afiori 2y ago
      TL;DR: Typescript is unsound so it can add a lot more type-level features that would make a sound type system undecidable Conceptually no, almost every useful union type can be easily converted to a sum type. In my opinion the difference is in the ergonomics and in the implicit structural subtyping. For example a common union type is number|string, and the beatiful part is that to use a value of such a type you do not need to do any matching or mapping you can just use the value as it does not have a runtime wrapper, for example (x:string|number)=>JSON.stringify(x) works perfectly fine. Also you can have a function that takes as input a Array<string>|number|null and returns a string|number without having to declare different contructors for the input number type and the output number type I believe that you can essentially implement this behaviour by generating enough typeclasses in Haskell, but regardless of the feasibility it, likely, would not be a good idea. An example of something in between union types an Hindley–Milner sum types are Ocaml's polymorphic variants types https://ocaml.org/manual/5.2/types.html#sss:typexpr-polyvar https://ocaml.org/manual/5.2/types.html#sss:typexpr-polyvar that are (I believe) more advanced than TS unions but also a lot less ergonomic to use. And TS has much more eg intersection types you could have a function with type (x:number)=>string & (x:string)=>number meaning that it is both a function that maps number to strings and strings to numbers (again you can do this with typeclasses but it is a worse experience) typescript also has very good support for value types for example there is the string type but also the "hello" type which is the type of only the string "hello" All in all if someone told me that they implemented typescript in haskell typeclasses I would not call bullshit on them, but I would not believe that anyone would actually use it for anything
      - tpm 2y ago
        > For example a common union type is number|string So that's like my beloved Perl then.
- wetpaws 2y ago
  [dead]
- VMG 2y ago
  most of that? name one
  - tpm 2y ago
    Java has type inference. Also if a type alias is just a new name for a existing type, then you can always do something like class MyNewClass extends OldClass {}; (of course it's not just a new name, it's also a new class, but it's also still a OldClass, and you are out of luck if OldClass is final or sealed) Java also has interfaces, of course. And optional properties (using Optional) and strict null checks, when you want that, you can use it.
    - guipsp 2y ago
      Using optional still has the secret third thing problem
    - VMG 2y ago
      > type inference very limited, for instance you must declare the type of a public method > alias as you point out it's not > Java also has interfaces, of course but you have to implement them explicitly > strict null checks, when you want that, you can use it if we start accepting static analysis tools then C has null checks as well I guess
      - tpm 2y ago
        > as you point out it's not so what's the difference except the name? > if we start accepting static analysis tools I'm not talking about static analysis. In today's Java you can write code that does not accept nulls, if you want to.
        svieira 2y ago
        You cannot write code that will fail to compile `theEntryMethod(null)` unless you only use primitive types. (You can, of course, make that method fail at runtime, but that's not what's being talked about here).

wiseowise 2y ago

https://www.typescriptlang.org/docs/handbook/2/types-from-types.html https://www.typescriptlang.org/docs/handbook/2/types-from-ty... https://www.typescriptlang.org/docs/handbook/2/template-literal-types.html https://www.typescriptlang.org/docs/handbook/2/template-lite... alone puts TS over anything that Java has.

DarkNova6 2y ago
> alone puts TS over anything that Java has. Virtual Threads alone challenge this assumption. Syntax bloat is not a feature.
- deleted 2y ago
  [deleted]
- Byamarro 2y ago
  It's not really a syntax bloat, the linked docs mention how to define strict string types and elaborate on type-level programming, something that is a very rare and powerful type-level capability. As far as I understand Virtual Threads aren't type oriented feature, which is basically the context for this thread.
- 3836293648 2y ago
  Virtual Threads are not a type system feature?
deleted 2y ago
[deleted]

magnio 2y ago

I don't use them directly much, but template literal generic and contidiontal types is probably the closest a mainstream language has inched towards dependent types. Some examples of TypeScript power: - SQL database in TypeScript types: https://github.com/codemix/ts-sql https://github.com/codemix/ts-sql - Statically typed raw SQL queries: https://github.com/andywer/squid?tab=readme-ov-file#tag-function https://github.com/andywer/squid?tab=readme-ov-file#tag-func... - (Someone fill in your TS hackery for me)

Vaguely2178 2y ago
There are various programming language interpreters that run entirely in the type system: - BF: https://github.com/susisu/typefuck https://github.com/susisu/typefuck - Assembly: https://github.com/judehunter/ts-asm https://github.com/judehunter/ts-asm

yen223 2y ago

Java and Typescript have fundamentally different type systems, that lead to drastically different ways to approach types. Utility types, like Partial<T>, are basically impossible to represent in Java except with almost-duplicated classes.

tpm 2y ago
> drastically different ways to approach types Exactly. > Partial<T> Looking at that it's just what a default POJO (with nullable properties) already is, so I'd see no need to represent that in Java. Looks cool though and I like Typescript; my issue with it is that it needs transpiling to run. If it was a first-class citizen in an environment I would use it for my pet projects.
- crabmusket 2y ago
  > it's just what a default POJO (with nullable properties) already is I think you missed the point. Partial<T> is an example of a "mapped type", see the handbook for more explanation: https://www.typescriptlang.org/docs/handbook/2/mapped-types.html https://www.typescriptlang.org/docs/handbook/2/mapped-types....
  - tpm 2y ago
    I understand that much, just thinking aloud what problem would that solve in Java.
    - scotty79 2y ago
      I think it's for when you need type that expresses partial data update for an object that has some fields required.
- svieira 2y ago
  Yep - all non-primitive types in Java are `TheType | null` - TypeScript actually allows you to strip out the `| null`, which then means that sometimes you want to add it back in. So Java doesn't have a need for `Partial<T>`, it has a need for `NonNull<T>` and it can't express that at the type system level very easily right now (you can do it with type tagging and runtime checks inserted explicitly, but it's not very ergonomic right now) https://gist.github.com/svieira/9f8beeafb7bf4aa55d40c638532f4fd7 https://gist.github.com/svieira/9f8beeafb7bf4aa55d40c638532f...