Hacker News Reader

Comment by automatwon | Hacker News Reader

It does not solve every problem JavaScript ever had. By definition of being a superset, it's still JavaScript. It just induces a prescription to mitigate symptoms of type unsafeness.

Null AND Undefined still coexist, though type safety helps. There's an idiomatic way to specify classes, as opposed to using a pattern of object returning closure function for instance. There's still both the == and === operators.

A problem beyond type-safety is the confusing semantics of 'this': https://github.com/Microsoft/TypeScript/wiki/'this'-in-TypeS...

View on HN

The semantics of 'this' in TS are the same as in JS and they're only a problem if you expect TS to be Java rather than JS.

I use the '=>' operator to get a 'this' reference that does what you'd expect (like in Java) by getting whatever object is running rather than the typical JS 'this' of the function. Trivial example is here:

https://github.com/Clay-Ferguson/meta64/blob/master/src/main...

If you want to trade contrarian jabs, I can play that game: TypeScript does far more than 'mitigate symptoms of type unsafeness' it is a fully type-safe language that will get proper compile-time errors if you use the wrong type. It doesn't "mitigate" unsafeness. It ELIMINATES unsafeness.

When comparing the types of function parameters, assignment succeeds if either the source parameter is assignable to the target parameter, or vice versa. This is UNSOUND because a caller might end up being given a function that takes a more specialized type, but invokes the function with a less specialized type.

A Google query for the definition of unsound: "not safe or robust"

https://www.typescriptlang.org/docs/handbook/type-compatibil...

You're portraying TypeScript as if it's perfect. Typescript is is permissive and structurally, rather than nominally typed. This is not TypeScript's fault. There will always be tradeoffs. Among other things in the FAQ, there is a section on how to prevent two types from being structurally incompatible. "A possible FIX if you really want two types to be incompatible is to add a 'brand' member"...

https://github.com/Microsoft/TypeScript/wiki/FAQ#type-system...

The 'assignability rules' of TS catches type-errors in a way that 'solves' all the problems JS ever had. You can critique the nature of that solution if you want (after all, there are an infinite number of solutions in the solution-set), but I think it's a perfect solution.

Give any good developer TS to code in, and he'll know how to use it to check every type in every variable, class, or method parameter, and the checking will be 100% perfectly reliable. That's what I mean by "problem solved".

Google's closure compiler already addressed that

Yeah, that's what I just said.

Reply on news.ycombinator.com