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

81–90 of 216 posts

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

#81

Post by jolux »

potatoz2 wrote: post #41
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…

Java interfaces are not structurally typed, are they?

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

#82

Post by ascorbic »

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've used typescript-json-schema to generate a schema based on an interface. I had a script that could regenerate the schema, and a CI script that ran ajv on a set of fixture JSON files to ensure any schema changes were backward-compatible.

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

#83

Post by alangpierce »

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 solved this using the ts-interface-builder and ts-interface-checker libraries and have been happy with the result. You write a plain TS type (rather than a custom syntax like io-ts has) and then run a codegen step to make a runtime representation of the type. Then you can create a checker from that and do runtime type checking.

https://github.com/gristlabs/ts-interface-builder

https://github.com/gristlabs/ts-interface-checker

Example: https://github.com/alangpierce/sucrase/pull/468/files

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

#84

Post by june11 »

yawaramin wrote: post #73
sjy wrote: post #50

Earlier quoted context omitted.

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…

Out of curiousity, what exactly was the difficulty with decoding JSON in Haskell/

a quick search brings up a library, not sure why you would have trouble, other than maybe experience? https://github.com/bos/aeson

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

#85

Post by yawaramin »

june11 wrote: post #84
yawaramin wrote: post #73

Earlier quoted context omitted.

Out of curiousity, what exactly was the difficulty with decoding JSON in Haskell/

a quick search brings up a library, not sure why you would have trouble, other than maybe experience? https://github.com/bos/aeson

I was replying to someone who said they had trouble.

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

#86

Post by quickthrower2 »

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…

Typescript has the any type when you need it. You can write your code well typed but treat api returns as any if you wish. Although entering a type definition even for 100 types isn’t a big hassle, compared to day the code that has to do something with those objects. And will probably save the odd mistake so probably comes out ahead in terms of efficiency.

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

#87

Post by loxs »

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 released

The only thing that's missing is indeed better nominal typing so that we can more easily discriminate between logically separate instances of strings and numbers. For objects it's actually good enough to qualify for "perfect".

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

#88

Post by IggleSniggle »

chmod775 wrote: post #68
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.

This. My network code uses them everywhere on the client side. It's frankly amazing. Your server side code should have runtime validation though. You can't and shouldn't rely on TypeScript there for security reasons.

I don't quite follow. Discriminated unions allow you to derive the type from the runtime validation. If the runtime finds these properties then it must be one of these, but if it finds those then it's one of those. If it can't fit into one of those type buckets as defined by runtime validation, then its . The types flow from the validation algebraically.

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

#89

Post by loxs »

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…

The thing is... it doesn't seem to matter. After 30-40k lines of TS code (coming from OCaml) I am still to find a bug where OCaml would have done a better job, except for missing features like nominally typed primitives and no pattern matching. And these are hopefully coming to TS/JS

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

#90

Post by afiori »

yawaramin wrote: post #78
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.

I understand that, which is why I said 'Which TypeScript is [unsound], by choice'. Disagree that full type safety would require a lot of runtime checks. That's not the experience I've had in ReasonML.

ReasonML is exactly the kind of backwards incompatible change that would be necessary. You cannot mix reasonML and JavaScript freely together.
Post reply on HN