Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Learn how to unleash the full potential of the type system of TypeScript

type-level-typescript.com

Post reply on HN
Print view View original

61–70 of 256 posts

Re: Learn how to unleash the full potential of the type system of TypeScript

#61

Post by 323 »

agentultra wrote: post #54
323 wrote: post #50

Earlier quoted context omitted.

Non-soundness is sort of a feature, it lets you force your way through and just say "trust me, this is a Thing" when it's just hard (or impossible) to make TypeScript see that. In practice, you can write large code bases where you only need to do this every 1000 lines or so. Not ideal, but better than no typing.

Is it fair to say that the limitation is that the type checker can admit programs that are not type correct?

Yes. For example it has the "any" type which will bypass any sort of type check.

But I think it's more nuanced. Depends of what you mean by type correct. Even in Haskell you can override the compiler and say "trust me on this".

Re: Learn how to unleash the full potential of the type system of TypeScript

#62

Post by diroussel »

agentultra wrote: post #54
323 wrote: post #50

Earlier quoted context omitted.

Non-soundness is sort of a feature, it lets you force your way through and just say "trust me, this is a Thing" when it's just hard (or impossible) to make TypeScript see that. In practice, you can write large code bases where you only need to do this every 1000 lines or so. Not ideal, but better than no typing.

Is it fair to say that the limitation is that the type checker can admit programs that are not type correct?

Yea, because typescript is trying to model what can be done in JavaScript, which is a very permisssive runtime.

Re: Learn how to unleash the full potential of the type system of TypeScript

#63

Post by iainmerrick »

323 wrote: post #37

One think I struggled a lot with until I got it is that the TypeScript types and the JavaScript code live in totally separate universes, and you cannot cross from the type world to JavaScript values because the types are erased when transpilling - meaning they can't leave any trace. This means that it's impossible to write this function: function isStringType (): boolean { return ... } const IS_STRING: boolean = isSt…

I think that’s actually a positive feature of TypeScript -- a useful limitation. Reflection is generally a bad idea and it’s good to be forced to do without it.

It is a bit annoying sometimes that you can’t have overloaded functions with different types, but in that case you can usually just give the overloads different names, and usually that’s better for readability anyway. (Or if you really want to, write one function and use JS reflection to do the overloading manually) (but you really don’t!)

Here’s an interesting discussion of the overloading question in Swift: https://belkadan.com/blog/2021/08/Swift-Regret-Type-based-Ov...

Re: Learn how to unleash the full potential of the type system of TypeScript

#64

Post by tobyhinloopen »

cogman10 wrote: post #26

A great idea. Now, everyone that learns this stuff, show some restraint! The drawback of a powerful type system is you can very easily get yourself into a type complexity mudhole. Nothing worse than trying to call a method where a simple `Foo` object would do but instead you've defined 60 character definition of `Foo` capabilities in the type system in the method signature. Less is more.

True that.

Once types get so complex, I’ve no idea what’s going wrong.

Today I had code running fine but throwing errors all over the place because some deeply nested type mismatch between two libraries.

I just any’d it… i aint got no time for that shit

Re: Learn how to unleash the full potential of the type system of TypeScript

#65

Post by theteapot »

gvergnaud wrote: post #58
theteapot wrote: post #48

Didn't know `Expect` existed. Can't find it docs?

It's actually not in the standard library, but you can write it yourself: type Expect = T; `T extends true` puts a type constraint on the parameter, which then needs to be assignable to the literal type `true` to type-check.

OK cool, now what about `Equal` :).

Re: Learn how to unleash the full potential of the type system of TypeScript

#66

Post by diroussel »

tunesmith wrote: post #45

Might as well ask here. On our teams, we have the occasional developer that is insistent on using Typescript in an OO fashion. This has always struck me as square peg round hole. Even though I come from an OO background, Typescript strict settings really seem to push me in a direction of using interfaces and types for type signatures, and almost never classes, subclasses, instantiated objects. I don't have a very goo…

I get this question sometimes from a developer new to my team asking if it’s ok to add OOP code since most of the existing code is just functions.

My view on that is that it’s ok to use OOP and define classes if you are really defining an OOP style object. Back in the 90s is was taught that an object has identify, state and behaviour. So you you don’t have all three, it’s not really an object in the OOP style.

Looking at it through this lens helps make it clearer when you should add classes or just stick to function and closures.

Re: Learn how to unleash the full potential of the type system of TypeScript

#67

Post by likeclockwork »

323 wrote: post #37

One think I struggled a lot with until I got it is that the TypeScript types and the JavaScript code live in totally separate universes, and you cannot cross from the type world to JavaScript values because the types are erased when transpilling - meaning they can't leave any trace. This means that it's impossible to write this function: function isStringType (): boolean { return ... } const IS_STRING: boolean = isSt…

That boundary is why I have a hard time taking TypeScript seriously. A type system that doesn't participate in code generation is what.. just for linting and documentation basically? Is that what we are become? Is that all people think a type system is good for?

Worse there is one value that is both a user-definable TypeScript type and a JS value.

Re: Learn how to unleash the full potential of the type system of TypeScript

#68

Post by 323 »

davidatbu wrote: post #59
323 wrote: post #37

One think I struggled a lot with until I got it is that the TypeScript types and the JavaScript code live in totally separate universes, and you cannot cross from the type world to JavaScript values because the types are erased when transpilling - meaning they can't leave any trace. This means that it's impossible to write this function: function isStringType (): boolean { return ... } const IS_STRING: boolean = isSt…

You might be interested in DeepKit[0]. In short, it enables introspection/reflection of typescript types at runtime, and builds off of that to do super interesting things like an ORM, an API framework, ... etc. [0] https://deepkit.io/

Thanks, their @deepkit/type is exactly what I would need, but it seems they do that by a TypeScript plugin, and I'm in an esbuild setup which completely bypasses TypeScript.

But I will check if maybe I can use DeepKit to auto-generate files with the reflection info I need as a separate build step.

Re: Learn how to unleash the full potential of the type system of TypeScript

#69

Post by [deleted] »

323 wrote: post #37

One think I struggled a lot with until I got it is that the TypeScript types and the JavaScript code live in totally separate universes, and you cannot cross from the type world to JavaScript values because the types are erased when transpilling - meaning they can't leave any trace. This means that it's impossible to write this function: function isStringType (): boolean { return ... } const IS_STRING: boolean = isSt…

[deleted]

Re: Learn how to unleash the full potential of the type system of TypeScript

#70

Post by brundolf »

iainmerrick wrote: post #63
323 wrote: post #37

One think I struggled a lot with until I got it is that the TypeScript types and the JavaScript code live in totally separate universes, and you cannot cross from the type world to JavaScript values because the types are erased when transpilling - meaning they can't leave any trace. This means that it's impossible to write this function: function isStringType (): boolean { return ... } const IS_STRING: boolean = isSt…

I think that’s actually a positive feature of TypeScript -- a useful limitation. Reflection is generally a bad idea and it’s good to be forced to do without it. It is a bit annoying sometimes that you can’t have overloaded functions with different types, but in that case you can usually just give the overloads different names, and usually that’s better for readability anyway. (Or if you really want to, write one func…

Wanted to note that you can do function signature overloading in typescript- you just have to have a single function at the bottom that encapsulates all the different signatures and then branches its logic dynamically based on the values it's given: https://stackoverflow.com/questions/13212625/typescript-func...

I actually think this is a super cool and elegant way to do overloading

Post reply on HN