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

151–160 of 216 posts

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

#151

Post by heisenbit »

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…

> TS can't know about your "classes" - they're a runtime thing. Treating them the same as interfaces can make this much nicer.

It helps sticking mostly to interfaces as it helps managing expectations. Class information gets discarded during compilation and that brings with it some quirks. Java Generics is another example where type erasure leads to quirky surprises.

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

#152

Post by garethrowlands »

jolux wrote: post #81
potatoz2 wrote: post #41

Earlier quoted context omitted.

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?

No but it's the closest available. Two classes C1 and C2 that both implement interfaces I1 and I2 can be said to have a common structure. That is, if they both implement I1 and I2 then they have that structure in common.

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

#153

Post by etripe »

namelosw wrote: post #71
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.

> a modern language like c# where the types are guaranteed compile + runtime and you can’t any-ignore problem. Come on, Typescript is more modern than C#. It's just started to being bloated a little bit since there are advanced type operators against structural typings. Or if you have to use a modern example, languages like Scala or Rust are more like it. Also guaranteed compile + runtime is not what C# is. Probably…

Typescript is certainly newer than C#. So are Scala and Rust. Modernity and novelty are two different things, though.

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

#154

Post by Sharlin »

bt4u wrote: post #108
ketzo wrote: post #94

Earlier quoted context omitted.

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

There's no such thing as an untyped programming language that's used in the real world. JavaScript and typescript definitely aren't. Maybe you mean dynamically typed

This is just a question of semantics. In mainstream programming language jargon it’s ”dynamically typed”, while in (applied) type theory it’s ”untyped” or, perhaps more accurately ”monotyped” or ”unityped”, because types are fundamentally invariants of a program that can be verified without executing it.

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

#155

Post by lazarljubenovic »

cryptica wrote: post #132

>> Real world JavaScript is inconsistent, messy, and complicated JavaScript is consistent. Expressive languages such as JS are consistent in their permissiveness. It doesn't stop developers from doing irrational things like comparing objects with numbers just like TypeScript doesn't stop developers from writing all other kinds of flawed logic. TypeScript basically only protects code from typos. The worst bugs I see i…

You obviously never wrote TypeScript with strict flag turned on. It does control flow analysis, not just typo checking.

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

#156

Post by The_rationalist »

paavohtl wrote: post #114
kazinator wrote: post #98

Earlier quoted context omitted.

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.

As a long time TypeScript user, I do think this is a design mistake with the language. For example, it breaks instanceof checks. However: - The language primarily uses structural typing. If two classes are compatible, it's not completely unreasonable to expect them to also behave in a structural way (though I would prefer them not to). - Adding a private field to a class makes it work as a nominal type ( https://mich…

taking full advantage of ADTs What? There is no clean way to switch on the types of an ADT on typescript, I believe.

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

#157

Post by hopia »

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…

Aeson parsing seems straightforward to me, not sure it could be easier in any language. Serialization from your endpoint is automatic, based on your data types.

The real benefit of using a well typed language here is that you only need to parse the data once at this point, after that the type system makes sure the data is of correct format everywhere else in your codebase.

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

#158

Post by lexicality »

kjtekn wrote: post #140

I like how nobody has realized that typescript is classic Microsoft embrace, extend, extinguish. Oh no, they have "turned a corner". This is a different Microsoft! Haha.. they are exactly the same. Every single company has wanted to try and control JavaScript as it takes over more and more of the roles other languages used to fill. Google failed with their new language, Microsoft is having some success. Google claime…

The only electron app I've ever used that wasn't slow/terrible is VSCode which happens to be written in typescript by Microsoft and it still occasionally decides to use 100% of my macbook's CPU making it entirely unusable until I restart, so I'm not sure that's a very good argument.

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

#159

Post by eatonphil »

kjtekn wrote: post #149
redmorphium wrote: post #143

Earlier quoted context omitted.

Some Typescript value added: - Living documentation: types are a clear description of how your code and its data are laid out, and this structure is kept always up-to-date with the code, regardless of future changes. If the "documentation" (the typing) is wrong, the compiler will complain. - Better tooling: autocomplete, more robust auto-refactoring - Elimination of an entire class of bugs. This class may include: 1.…

Lets be honest here, these reasons are really weak. Living documentation - TypeScript is less readable. There is more stuff you have to read. Stuff that isn't even relevant. I see a "cars" variable. Oh no, I don't know what type it is, I am going to have a panic attack. Don't worry that cars.map((c) => c.model); is the next line or whatever. What type is it, I must know! auto-refactoring.. yeah we all trust that. Unt…

> All the stuff coming in and out of your code is untyped.

Until you automate building TypeScript definitions from your external code. We do this to varying degrees and are always trying to improve.

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

#160

Post by [deleted] »

IggleSniggle wrote: post #88
chmod775 wrote: post #68

Earlier quoted context omitted.

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.

[deleted]
Post reply on HN