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

Virtual Threads alone challenge this assumption.

Syntax bloat is not a feature.

Some examples of TypeScript power:

- SQL database in TypeScript types: https://github.com/codemix/ts-sql

- Statically typed raw SQL queries: https://github.com/andywer/squid?tab=readme-ov-file#tag-func...

- (Someone fill in your TS hackery for me)

- BF: https://github.com/susisu/typefuck

- Assembly: https://github.com/judehunter/ts-asm

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.

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 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

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

So that's like my beloved Perl then.

  class MyNewClass extends OldClass {};

Java also has interfaces, of course. And optional properties (using Optional) and strict null checks, when you want that, you can use it.

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

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.

Utility types, like Partial<T>, are basically impossible to represent in Java except with almost-duplicated classes.

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.

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....

https://gist.github.com/svieira/9f8beeafb7bf4aa55d40c638532f...