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

91–100 of 216 posts

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

#91

Post by nawitus »

shhsshs wrote: post #77
yawaramin wrote: post #70

Earlier quoted context omitted.

> TS can't know about your "classes" - they're a runtime thing. Treating them the same as interfaces can make this much nicer. No–this is a very surprising and unsound choice and not at all what you would expect if you previously saw that TypeScript lifts classes into types. > This way you can have type safety without losing JS features. IMHO, you can't get type safety out of an unsound type system. (Which TypeScript…

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.

"Full type safety would require a lot of runtime checks injected into the final JavaScript"

Why would this be the case?

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

#92

Post by IggleSniggle »

loxs wrote: post #87

To me, TypeScript is "perfect". Unlike other strictly typed languages (looking at you OCaml, ReasonML, Haskell), TS has never prevented me from achieving all three of: 1) Be type safe enough to guarantee practically bug-free code (at least with regard to types, you can always have logic bugs) 2) Actually achieve what I want to do in less than a day 3) Upgrade easily when a new version of the language/tooling is relea…

TS has led me to a desire for more functionally pure typed code. I'm super interested in learning OCaml and ReasonML right now so I would be interested in understanding where you felt ReasonML falls flat vs TS.

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

#93

Post by seanmcdirmid »

yawaramin wrote: post #70
chmod775 wrote: post #67

The following is purely anecdotally, my opinions is solely based on my personal experience with the language. As someone who learned TypeScript just by using it and without any serious "study", I'll have to disagree the basic premise of the article. I already knew about almost everything the article mentioned and nothing really seemed weird to me at the time. The only point that I did not know about is type narrowing…

> TS can't know about your "classes" - they're a runtime thing. Treating them the same as interfaces can make this much nicer. No–this is a very surprising and unsound choice and not at all what you would expect if you previously saw that TypeScript lifts classes into types. > This way you can have type safety without losing JS features. IMHO, you can't get type safety out of an unsound type system. (Which TypeScript…

TypeScript’s goal isn’t absolute type safety, the goal is feedback (eg code completion) and earlier detection of many errors.

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

#94

Post by ketzo »

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…

Yup. Rather than bringing 100,000 devs from one typed language to another, Typescript brings 1,000,000 devs from untyped to typed.

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

#95

Post by IggleSniggle »

nojvek wrote: post #32
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?

In the simple case, if it could be Dog|Cat and you cast as Dog but you get a Cat, and TS could have told you about the error if it hadn't been forced to treat it as Dog. This can be fixed by having your types be derived by runtime validation.

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

#96

Post by cuddlecake »

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…

TypeScript does not offer perfect typing, but on the other hand, your example is wild in such a way, that I don't think I would ever encounter it with a professional team of developers.

I.e. it would be quickly caught in a review, and the offending developer would have to bring cake the next day.

Yes, TypeScript is not perfect, but we take what we can get

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

#97

Post by rtpg »

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…

Structural typing and actual first class union types in typescript are better than basically all the ML-based languages.

Dumb example: imagine you had

Animal = Dog | Cat

Person = Plumber | Driver

If you want a list of “stuff” in your system , in typescript you just say you have Person | Animal.

In ML languages you would need to introduce an Either type so you’re working with Either Person Animal.

So now in your code you’ll need to introduce a bunch of Lefts and Rights. And if you end up needing to compose you’re introducing even another layer of Lefts and Rights. And you don’t get much of any or the inference capabilities of TS to just do this for you.

ML languages don’t have first class unions, they have ADTs, which introduce difficulties and lead to classic type safety weirdness like “why can’t I write a function that only accepts one ADT variant??”

Typescript resolves a lot of these, do you end up with a much better local maximum for typechecking IMO.

Typescripts type unsoundness means you unfortunately can’t really implement return type polymorphism though...

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

#98

Post by kazinator »

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…

If you can pass a Cat to a Dog function, where is the better checking?

That would be one of the hello-world test cases for a type checker bolted on to a dynamic language.

That type checker itself has introduced the syntax for declaring Cat and Dog classes; yet is neglecting to do the obvious with it.

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

#99

Post by loxs »

IggleSniggle wrote: post #92
loxs wrote: post #87

To me, TypeScript is "perfect". Unlike other strictly typed languages (looking at you OCaml, ReasonML, Haskell), TS has never prevented me from achieving all three of: 1) Be type safe enough to guarantee practically bug-free code (at least with regard to types, you can always have logic bugs) 2) Actually achieve what I want to do in less than a day 3) Upgrade easily when a new version of the language/tooling is relea…

TS has led me to a desire for more functionally pure typed code. I'm super interested in learning OCaml and ReasonML right now so I would be interested in understanding where you felt ReasonML falls flat vs TS.

I definitely recommend trying them, as it will be a great learning experience. It will probably even make your TS better.

What you won't be able to do is to actually ship a product easily, as the ecosystem is virtually non-existent. Documentation - virtually non-existent especially for actually creating working products.

Of course, there are exceptions to this (like the Facebook Messenger being written in ReasonML), but people tend to underestimate what kind of engineering effort went into that. If you actually want to do stuff by yourself, use TS.

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

#100

Post by austincheney »

There are problems in their approach:

In the first case the behavior is quirky because they are passing an untyped object into a function. If the object is typed the behavior is consistent.

The second example is about classes. Classes are created as easy extension objects via inheritance and poly-instantiation. Those ideas are friendly concepts for many developers but they increase complexity so I intentionally avoid classes and use a custom ESLint rule to enforce such.

In the third case they can solve for complexity with a simple refactor. The two interfaces are structurally identical so they should be a single interface with either a union on property values (static literals) or by defining a property again a union of other interfaces called by reference.

Post reply on HN