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

31–40 of 216 posts

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

#31

Post by horseman »

BigJono wrote: post #28
felixfbecker wrote: post #4

Earlier quoted context omitted.

Casting can hide errors. It's better to assign it to a variable first that has a type declaration. const dog: Dog = { breed: "Airedale", age: 3 } printDog(dog) An IIFE is safe too: printDog(((): Dog => ({ breed: "Airedale", age: 3 })())

Yeah and both of those are less readable, and used everywhere add up to a really crap code base relative to the same code in plain JS.

Yah, pojs is so much nicer because when you mistype breed as bred you get to debug the issue at runtime for a while changing things that are irrelevant when TS could have told you immediately

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

#32

Post by nojvek »

leetrout wrote: post #3

The first example doesn't bother me and I think it's a weak argument. TypeScript allows literals[1] as types[0] so it is trying to use the object as a type. The correct use of: printDog({ breed: "Airedale", age: 3 }) is to explicitly cast it: printDog({ breed: "Airedale", age: 3 } as Dog) [0] https://www.typescriptlang.org/play/index.html?ssl=1&ssc=1&p... [1] https://www.typescriptlang.org/docs/handbook/advanced-type…

Why would casting hide errors?

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

#33

Post by fyp »

habosa wrote: post #24

Ok since we have a lot of TS people here maybe someone can help me out. Let's say I have a simple interface with a few fields. I want to make sure incoming JSON conforms to that interface. I realize at runtime the interface isn't there, but is there some tool I can use to compile a utility to check JSON against an interface without having to write a duplicative JSONSchema or something else?

I am having the same problem and I think I am going to go with json schema.

The problem is that a lot of the things you want to validate aren't easily expressible as typescript types (e.g., valid email address, make sure two fields are always the same length, etc). If json schema are more expressive you want to use that as your source to generate the typescript interface instead of the other way around.

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

#34

Post by pansa2 »

earthly wrote: post #20

I still don't understand what pulls developers to Typescript. The examples given show major flaws in this (duck)type system. That it works when you don't use the 'any' type and when you know how to avoid all the edge cases and workarounds, I know. But when I see an example like this: const shasta = new Cat("Maine Coon") printDog(shasta) > Dog:Maine Coon I see a huge red flag. Coming from C/C++ it looks like a joke. W…

Because TypeScript is a superset of JavaScript and works directly with existing JavaScript code.

It’s the same reason that there is any interest at all in MyPy for Python, Sorbet for Ruby etc.

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

#35

Post by kccqzy »

alexcole wrote: post #18
stupidcar wrote: post #5

I don’t agree with the article’s claim that discriminated unions are just a JS compat feature. Many APIs type JSON serialised entities using a string property and this feature makes it very easy to write interfaces and code to work with them.

Author here! Yeah I think you are right that discriminated unions are useful more broadly than just legacy JS code. That being said, I still think TypeScript's solution to handling them of using "type guards" where the type of a variable changes in different scopes is definitely designed to match common JS patterns at the cost of added complexity. Most other languages I know of only have a single type for a variable…

> Most other languages I know of only have a single type for a variable

This may be pedantic, but with subtyping many OO languages can give many different distinct types for a variable. In Java you can assign any non-primitive typed expression to a variable of type Object. So almost any expression in Java can be typed as Object.

What you are describing as novel is rather the phenomenon of type refinement in a pattern match or conditional expression. When an expression undergoes pattern matching, its type becomes increasingly refined. This is a useful feature in intermediate-to-advanced Haskell (known as GADT) as well as dependently typed languages.

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

#36

Post by nojvek »

alexcole wrote: post #19
mekster wrote: post #17

Earlier quoted context omitted.

Casting is as bad as using "any". You can make the compiler think anything you throw at it as that type and you can get bitten at runtime.

Thats not 100% true in TypeScript. TypeScript actually only allows "up-casts" and "down-cast" (but if the type is neither a supertype nor a subtype the compiler will throw an error).

That’s my understanding too. You just can’t cast types wily Nily.

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

#37

Post by potatoz2 »

leetrout wrote: post #3

The first example doesn't bother me and I think it's a weak argument. TypeScript allows literals[1] as types[0] so it is trying to use the object as a type. The correct use of: printDog({ breed: "Airedale", age: 3 }) is to explicitly cast it: printDog({ breed: "Airedale", age: 3 } as Dog) [0] https://www.typescriptlang.org/play/index.html?ssl=1&ssc=1&p... [1] https://www.typescriptlang.org/docs/handbook/advanced-type…

The correct use is to remove the `age` property in this case: if you're not keeping a reference to the object or that property and the called function cannot use it, why have it in the first place?

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

#38

Post by recursive »

evmar wrote: post #15
aratakareigen wrote: post #7

How does TypeScript ensure encapsulation if it doesn't have nominal types? Edit: The article says "magical hidden properties".

At runtime, TypeScript is JavaScript, so depending on your perspective either encapsulation is impossible (because you don't have types to defend you) or easy (because you use the patterns that JS has to defend encapsulation at runtime, without types).

#private is coming soon, so that won't really be true any more. https://github.com/microsoft/TypeScript/pull/30829

You'll have class members with accessibility in their declaration, and real run-time encapsulation.

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

#39

Post by nojvek »

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.

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

#40

Post by hopia »

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.

I agree but it's a big leap to lose Javascript interoperability to gain type soundness.

There are many such compile-to-js languages but none nearly as popular as Typescript is.

Post reply on HN