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

41–50 of 216 posts

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

#41

Post by potatoz2 »

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…

It just means that structural types are the default and you need to opt in to nominal types, when necessary: https://www.typescriptlang.org/play/?ssl=13&ssc=1&pln=13&pc=... (there are other ways as well)

In something like Java, it's the opposite: you get nominal types by default and you need to opt in to structural types (via interfaces).

Because TS is built on a duck typed language, tons of existing libraries would break if they had to declare explicit nominal types as arguments. Or you'd need to add custom interfaces for each library you use. Structural typing is what you want 99% of the time.

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

#42

Post by potatoz2 »

earthly wrote: post #26
andrew_n wrote: post #9

Earlier quoted context omitted.

Programming TypeScript has a section on “Simulating Nominal Types” [1]. You define a type that’s impossible to create naturally, and provide a function that asserts something is of that type. type CompanyID = string & {readonly brand: unique symbol} type OrderID = string & {readonly brand: unique symbol} type UserID = string & {readonly brand: unique symbol} type ID = CompanyID | OrderID | UserID function CompanyID(i…

> TypeScript can be very confusing sometimes That's not good. A type system should be crystal clear, predictable and reliable. > and given the learning curve Types should not be a complex thing with a steep learning curve. If you know Assembler and C it's pretty clear what types are about. Added complexity to your codebase is what you should try to avoid at all times. We have a limited capacity of things we can think…

I don't follow how knowing C and Assembler makes types clear and I'd love it if you could clarify.

Nominal types are really a compile time only thing: if you have two structs (or classes) with the exact same fields, I'd expect them to be stored the same way in memory. And as a result I'd expect any function to work on them just fine, as long as they find semantically valid data at the right offsets.

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

#43

Post by seanmcdirmid »

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 actually like the unsoundness when I thought I would hate it. It rarely turns out to be a problem for me, and allows some designs I’d never be able to get away with in C#. What I really want from typescript are operators and extension methods (monkey patching is a bad hack), but those would break JavaScript supersetting (typescript isn’t allowed to desugar).

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

#44

Post by seanmcdirmid »

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).

Ya, I often have to write “this as any as T” because I’m using T as a self type.

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

#45

Post by jbob2000 »

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.

Noooo! Go away with those ideas! JavaScript is great because it’s not strict. That’s the flexibility that allows for speed.

I have like 30 different APIs I implement at work, but I only pull out a few attributes from each. I don’t want to go to the moon and back creating types for all this crap, I’ll have more than a 100 different types to model because of all the nested data and convoluted structures the APIs return.

I want the flexibility to incur tech debt where I want to, I don’t want the language to get in my way. That’s what makes JavaScript great!

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

#46

Post by arusahni »

jbob2000 wrote: post #45
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.

Noooo! Go away with those ideas! JavaScript is great because it’s not strict. That’s the flexibility that allows for speed. I have like 30 different APIs I implement at work, but I only pull out a few attributes from each. I don’t want to go to the moon and back creating types for all this crap, I’ll have more than a 100 different types to model because of all the nested data and convoluted structures the APIs return…

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.

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

#47

Post by jahewson »

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…

That’s control-flow sensitive type deduction though - not specific to union types. I agree that proper patten matching is much nicer - but unavailable in JS.

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

#48

Post by sramam »

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?

ts-json-schema-generator[1] generates a schema from an annotated interface definition.

[1] https://github.com/vega/ts-json-schema-generator

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

#49

Post by johnghanks »

felixfbecker wrote: post #4
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…

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 })())

I would absolutely reject a PR with the IIFE.

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

#50

Post by sjy »

arusahni wrote: post #46
jbob2000 wrote: post #45

Earlier quoted context omitted.

Noooo! Go away with those ideas! JavaScript is great because it’s not strict. That’s the flexibility that allows for speed. I have like 30 different APIs I implement at work, but I only pull out a few attributes from each. I don’t want to go to the moon and back creating types for all this crap, I’ll have more than a 100 different types to model because of all the nested data and convoluted structures the APIs return…

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 safety, but as the grandparent said, sometimes programmers need the freedom to incur technical debt.
Post reply on HN