If you want to write clever DSLs and/or name methods in ways that save keystrokes like in scala, NO, please.
2) There are libraries such as runtypes and io-ts that integrate well with the static type system
We've been using Mobx State Tree for this, which also gives us frontend models and automatically generates interfaces. Obviously only works for you if you're using Mobx, but we love it.
You can even define the type via io-ts and then make a TypeScript interface out of it!
Given this, and the other libraries that do something similar, I am not sure why Microsoft needs to add it to the language.
[1] https://www.typescriptlang.org/docs/handbook/advanced-types....
Please, please, please, no.
On the other hand, there's only one language that I'm aware of - TypeScript - prioritizing these things, which is a major selling point of it to me. I don't want yet another leaky abstraction, or yet another runtime heavy enough for those abstractions to not leak.
I just want enough types for my intellisense to work right, and for my sorry ass - spoiled by years of nothing but static typing systems - to be able to code without drowning in a veritable sea of uncaught type errors to debug, when I poke frontend stuff.
1) Operator overloading
2) Runtime type checking of JSON payloads (on dev env at least)
Can't believe in 2019 every library has to create its own way to add 2 elements of the same class together e.g dataframe1.addTo(dataframe2) vs dataframe1 + dataframe2
And the most common error that it should help catch during development is that you get a JSON and you cast it but it means nothing cause on runtime the JSON can be something completely different and nothing breaks until is somewhere else hard to debug, I get that Microsoft don't want to add runtime overhead but it should be possible at least on development mode.