[verttii]

Typescript certainly eliminates a class of errors from a JS codebase and can also make development more productive.

My issues with it are that it's just an extremely verbose language. Just like all Microsoft languages. All the while lacking advanced type system features like algebraic data types, pattern matching etc.

[eropple]

I feel almost the exact opposite: TypeScript is delightfully terse while still achieving its main goal of looking and feeling like JavaScript. I've used languages where things start looking like line noise (hi, Scala) and I very strongly do not get that feeling out of TypeScript.

You have discriminated unions and the compiler is clever about them, so you can implement ADTs if you want them with a little but not a nasty level of boilerplate. (They can also be implemented with an abstract class if that's more your bag.)

It lacks pattern matching because it intentionally doesn't include a runtime component, which I think is also wise. Options exist if you want to use them. I've seen people use Purify to good effect.

[verttii]

I guess it depends on what you compare with. If you're coming from Java or the like, surely TS does not feel particularly verbose.

However, coming from a truly terse language like Haskell you'll just feel TS is too verbose and not very elegant. TS is the most verbose and least elegant of the languages I'm personally using, on par with Dart.

ADTs not only feel dirty because they're not first class citizens (you build them with the TS primitives by adding a discriminating union key) but also somewhat useless since you don't have pattern matching.

Although pattern matching would not be a trivial problem to solve in TS. It could be solved with the compiler, however, you'd still have to hack the compiler API quite a bit too and TS doesn't even support integrating custom extensions with a config file like Babel does.

Btw thanks for pointing me to that ts-purify, it looks good!

[eropple]

I'm sure that, if you're carrying a torch for Haskell, TypeScript can feel very primitive--though I don't enjoy writing Haskell, in my experience it turns into an exercise in navel-gazing and write-only code compared to TypeScript or F#--but on the other hand normal people can write it and be productive and that's kind of important, yeah? I think the TS folks did a great job in making something that I can bring into engineering shops to make average to average-plus developers significantly better and significantly safer.

I'd really disagree with the notion that discriminated unions/ADTs are useless; the compiler is clever and will constrain the type in an `if` or a `switch` (particularly useful with an enum type, too). I use this regularly and it's really effective; my `nestjs-auth` library makes it more or less a requirement and its users seem to really dig it. And if you do it as an abstract class instead of a key, you can use polymorphism to take care of a lot of what would otherwise be pretty clunky--this is how you can make a solid maybe/option type in the vein of Scala.

[verttii]

Hehe yes the Haskell community certainly suffers from the dynamics you just described.

I guess my problem with TS ADTs is just that they're done with the TS primitives whereas they could be true first class citizens. But such a feature may be too hard to swallow for your typical JS developer whose first introduction to types is Typescript.

Btw can you elaborate on that Enum with ADTs? Or did you mean that you use Enums with switch-case? I use it too and find it one of the best bits of TS.

[eropple]

I do mean enums/switch, yeah. Makes it easy to have your code yell at you when all cases aren't dealt with.

The thing about making ADTs first-class citizens means that TypeScript stops being JavaScript, and one of the most valuable parts of TypeScript to me is that I can just look at it and know what the underlying JavaScript is. I kind of equate it to writing C on an old platform--it's going to be munged significantly but at a glance you can have a high degree of confidence that the code coming out the other end is going to be what you expect it to be.

[vedantroy]

I don't understand the desire for terse code, it makes things harder to read.

I also think Typescript makes the right tradeoffs, yes it may not have a Haskell-level type system, but in return, it has amazing integration with JS code and existing libraries, and no runtime.

As a side note, coming from someone whose previous exposure to type systems was Java and Kotlin, Typescript seems to have a pretty powerful type system. Yes, it may not have some/many Haskell-level features but I question whether those would have been necessary in the first place. At some point a more rigorous type system must stop generating value, otherwise we would all be using coq.

[lioeters]

Purify does look great, I can't wait to start playing/working with it.

For reference, here's the home page and documentation for purify-ts.

https://gigobyte.github.io/purify/

https://gigobyte.github.io/purify/getting-started

[no_wizard]

thanks for the mention of purify! This is going to be a game changer for me, I think. I can already see how this will benefit my TypeScript workflow!

[Epskampie]

Verbose? Do not agree at all. Adding types to function parameters for example is just a simple ": TYPE" I do not see how that could be much shorter.

Furthermore, where possible (variable assignment, function returns) types are inferred, and do not need to be specified at all, leaving you with mostly plain JS syntax.

[verttii]

No algebraic data types leads to having to add an additional discriminating union type key.

Besides that, no type signatures without parameters and other things just produce a lot more code than you'd have in a nicer type system.