[dvt]

> Being able to write complex types in a syntax that more closely resembles JavaScript

Yikes. This is how you end up in preprocessor hell. Macros are generally not a good thing. (Fyi: TS types are already Turing-complete which is arguably a mistake.)

> Being able to debug types, not console output

Eh. It's not like Java has a "type debugger." Why is this needed? Why are your types so complex? Weird ask.

> More comprehensive documentation on writing advanced types

Really beating the same drum here.

> A typescript specification

What does this mean? We have a pretty clear typescript spec[1].

[1] https://github.com/microsoft/TypeScript/blob/main/doc/spec-A...

[gkiely]

> Yikes. This is how you end up in preprocessor hell. Macros are generally not a good thing.

Not suggesting macros, rather an alternative way to define types. A function that accepts and returns types. Seeing as typescript has a JavaScript interpreter I thought it might be feasible but I'm just spitballing it.

> Eh. It's not like Java has a "type debugger." Why is this needed? Why are your types so complex? Weird ask.

I don't buy this argument. Writing any type of complex types with recursion, arrays or ternaries sucks and it will take more than "this is how Java does it" to convince me otherwise. I like to debug with a debugger, not my head.

Take a look at the examples in the article to see some complex types and read some tweets from library authors complaining on twitter. I can find some examples if you're interested.

> We have a pretty clear typescript spec

I hadn't actually seen this and it looks interesting but seems pretty out of date, Typescript 1.8?

[jcparkyn]

> Why are your types so complex?

The article (and ensuing discussion) are about _library_ code, which necessarily has types that are orders of magnitude more complex than application code (source: see some of the links in the article).

The reason this isn't a problem in Java, C# etc is that the things these libraries do simply _aren't possible_ in the Java type system, so no one does them, and users end up with (usually) clunkier libraries.

[bhawks]

React has its roots in StandardML and it's showing them here. Java, C# (and ma y other languages) barely scrape the surface of what you can do with a type system.

Now there's definitely a question of when you start hitting diminishing returns but you can definitely do so much with and extract confidence from very strongly typed languages.

[GurnBlandston]

> React has its roots in StandardML

Really? This is fascinating, is there anywhere with more on this?

[dvt]

> The article (and ensuing discussion) are about _library_ code, which necessarily has types that are orders of magnitude more complex than application code (source: see some of the links in the article).

Are you somehow implying that C++ or Java don't have libraries? As a sidenote, React (and that entire ecosystem) is an architectural hellscape (see Vue for much more streamlined & cleaner code).

[jcparkyn]

No, I'm just saying the libraries in those languages tend to be designed differently, to accommodate the more limited type systems (but I don't use C++, so I'm sure templates can do a lot of things I'm not aware of).

I'm also not necessarily saying this is a good or bad thing overall, since it can so easily lead to extra complexity.

FWIW, I'd choose C#/Rust/Kotlin/etc over TS 100% of the time for projects that don't need to run in a browser.