Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TypeScript’s quirks: How inconsistencies make the language more complex

blog.asana.com

Post reply on HN
Print view View original

121–130 of 216 posts

Re: TypeScript’s quirks: How inconsistencies make the language more complex

#121

Post by the_gipsy »

nitram1 wrote: post #112
nawitus wrote: post #91

Earlier quoted context omitted.

"Full type safety would require a lot of runtime checks injected into the final JavaScript" Why would this be the case?

Array access is a good example. Many type-safe languages throw an exception if you attempt to access an element in an array that is out of bounds but javascript just returns undefined. Typescript ignores the fact that accessing an arbitrary element of an array could return undefined. If it did not ignore this fact then it would force you to deal with the potential undefined value retrieved from any array access (i.e…

Some languages do force you to check any time you access an element. If the rest of the language is in line with this, then it's actually amazing. Option/Maybe types help here, pattern matching lists also let's you make sure you handle all cases.

In some instances it makes sense to use a special NonEmptyList type that guarantees there is always at least one element, so you don't need to check.

Re: TypeScript’s quirks: How inconsistencies make the language more complex

#122

Post by the_gipsy »

sjy wrote: post #50
arusahni wrote: post #46

Earlier quoted context omitted.

In strongly typed languages, there are serialization/deserialization libraries that don't require you to type the entire JSON object - just the fields you care about.

I’m not a very skilled Haskell programmer, but every time I’ve tried to parse JSON in it I’ve felt a strong urge to switch back to Python or JavaScript. There are libraries that make it easier but I think it’s always going to be hardly to get started with JSON APIs in a language with a powerful and strict type system. Of course, that extra up-front effort might be worth it in the long run due to the benefits of type…

I've really come to love strict JSON parsing, because everytime an API call was not as expected, I get the error straight at it's source, not somewhere 20 layers deeps in my views or models, way too late, and only with this one specific combination of events.

Re: TypeScript’s quirks: How inconsistencies make the language more complex

#123

Post by gazarullz »

Findeton wrote: post #106
twotwotwo wrote: post #80

These can make sense if you think of TS as better-checked JavaScript, not as a from-scratch design for a statically typed language. Excess property checks catch a common JavaScript bug (typoed property names), structural static typing matches the dynamic duck typing JavaScript authors had already been working with (though I see how nominal would be useful), and it's awesome they found a workable hack for discriminate…

As someone that uses the language everyday, these are real quirks on the language, but they are not showstoppers. The benefits of using exactly the same language in front-end and back-end, with shared types and everything, largely offset the small quirks. However sometimes I kinda miss some functional stuff that you can for example find in Scala or Rust, like pattern matching. Specifically, we've had experience using…

You should try using computed propeties, it's the closest/cleanest way to pattern matching until tc39 will pass the pending proposal.

Re: TypeScript’s quirks: How inconsistencies make the language more complex

#124

Post by TomMarius »

blobs wrote: post #116
twotwotwo wrote: post #80

These can make sense if you think of TS as better-checked JavaScript, not as a from-scratch design for a statically typed language. Excess property checks catch a common JavaScript bug (typoed property names), structural static typing matches the dynamic duck typing JavaScript authors had already been working with (though I see how nominal would be useful), and it's awesome they found a workable hack for discriminate…

> TypeScript crew have managed to build something that can get traction where other efforts have not. You mean Microsoft managed to get traction? It seems most TS proponents don't realize TS is a success because they fell for smart marketing and serious money behind the project, not because it's a better language than 'other efforts' like for example Purescript or Dart. But every comment I make against TS seems futil…

They did it by solving a great pain of a very large amount of people. Not many of these people would have been able to use Dart or PureScript.

Re: TypeScript’s quirks: How inconsistencies make the language more complex

#125

Post by wwwigham »

nitram1 wrote: post #112
nawitus wrote: post #91

Earlier quoted context omitted.

"Full type safety would require a lot of runtime checks injected into the final JavaScript" Why would this be the case?

Array access is a good example. Many type-safe languages throw an exception if you attempt to access an element in an array that is out of bounds but javascript just returns undefined. Typescript ignores the fact that accessing an arbitrary element of an array could return undefined. If it did not ignore this fact then it would force you to deal with the potential undefined value retrieved from any array access (i.e…

Index unsafety w.r.t. bounds and `undefined` is something TS would like to fix; but it's not ergonomic to fix until there are, something like automatic refinement range types applied to array length fields. Without it, TS'd get in the way, demanding `undefined` checks it almost definitely didn't need. Those range types and their complexity are, ultimately, what currently block TS from making these indexed accesses safer.

Re: TypeScript’s quirks: How inconsistencies make the language more complex

#126

Post by cryptica »

twotwotwo wrote: post #80

These can make sense if you think of TS as better-checked JavaScript, not as a from-scratch design for a statically typed language. Excess property checks catch a common JavaScript bug (typoed property names), structural static typing matches the dynamic duck typing JavaScript authors had already been working with (though I see how nominal would be useful), and it's awesome they found a workable hack for discriminate…

I still don't see the value added by TypeScript. My JavaScript tests catch typoed property names every time. I can't remember the last time I merged code with a typo in a property name. IMO, if you typoed a property name and your tests didn't catch it, it means that either your tests are poorly written or your object didn't need that property to begin with.

Re: TypeScript’s quirks: How inconsistencies make the language more complex

#127

Post by nicoburns »

cryptica wrote: post #126
twotwotwo wrote: post #80

These can make sense if you think of TS as better-checked JavaScript, not as a from-scratch design for a statically typed language. Excess property checks catch a common JavaScript bug (typoed property names), structural static typing matches the dynamic duck typing JavaScript authors had already been working with (though I see how nominal would be useful), and it's awesome they found a workable hack for discriminate…

I still don't see the value added by TypeScript. My JavaScript tests catch typoed property names every time. I can't remember the last time I merged code with a typo in a property name. IMO, if you typoed a property name and your tests didn't catch it, it means that either your tests are poorly written or your object didn't need that property to begin with.

Type systems can be thought of as low-cost (in terms of dev time) declarative tests. Which should leave you with less to test in your actual tests. They also give much quicker feedback than tests.

Re: TypeScript’s quirks: How inconsistencies make the language more complex

#128

Post by redmorphium »

blobs wrote: post #120
dtech wrote: post #115

Earlier quoted context omitted.

> If you can pass a Cat to a Dog function, where is the better checking? If you have compatible method, fields and types, in a duck-typed ecosystem like Javascript it is a major boon that it is possible to interchange them, because it happens all the time in the ecosystem. The standard way to do enforce exactly the right interface in typescript if you need to is to add a `type: "cat" | "dog"` field to your Animal int…

Whatever words you use, it simply conflicts with basic JS and is a serious flaw. const cat = new Cat(); if (cat instanceof Dog) console.log('this should never be possible!'); What is this strange protective behavior towards TS, can we stick to logic please?

instanceof checks the prototype chain, which is a different concept from type. Prototype chains are dynamic and exist at runtime, while Typescript types are a static concept.

Re: TypeScript’s quirks: How inconsistencies make the language more complex

#129

Post by catblast »

crimsonalucard wrote: post #103
shhsshs wrote: post #77

Earlier quoted context omitted.

TypeScript’s goal isn’t to be sound. Its goal is to be a balance between type-safety and effort. Full type safety would require a lot of runtime checks injected into the final JavaScript, which TypeScript intentionally avoids. JavaScript will never be fully type-safe without fundamental changes, which will probably never happen.

This is absolutely false all type checking in basically every typed language happens precompile time. There is no trade-off here. You completely don't understand.

There's a thing called dynamic type checking. It's literally all type checking done at runtime. Even for mostly static typed languages you may want to lookup what a downcast is, it's not obscure.

Re: TypeScript’s quirks: How inconsistencies make the language more complex

#130

Post by k__ »

nojvek wrote: post #39

Typescript is great but it has its evils because it’s a superset of JavaScript. I really hope we get a modern language like c# where the types are guaranteed compile + runtime and you can’t any-ignore problems. The more I use typescript I realize I want a more sound and stricter language. Like no prototype overriding at runtime.

TypeScript already feels too much like C# for my taste.

But luckily with OCaml/Reason, there is a modern alternative to all these bloated C#/Java like type-systems.

Post reply on HN