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

`satisfies` is my favorite TypeScript keyword (2024)

sjer.red

Post reply on HN
Print view View original

141–150 of 217 posts

Re: `satisfies` is my favorite TypeScript keyword (2024)

#141

Post by jstanley »

LordN00b wrote: post #140
debugnik wrote: post #111

Earlier quoted context omitted.

Not really, I provided these examples a couple weeks ago on another HN thread. TypeScript is simply unsound. https://www.typescriptlang.org/play/?#code/MYewdgzgLgBAllApg... https://www.typescriptlang.org/play/?#code/DYUwLgBAHgXBB2BXA...

In the first example you deliberately create an ambiguous type, when you already know that it's not. You told the compiler you know more than it does. The second is a delegate, that will be triggered at any point during runtime. How can the compiler know what x will be?

If it only works when you write the types correctly with no mistakes, what's the point? I thought the point of all this strong typing stuff was to detect mistakes.

Re: `satisfies` is my favorite TypeScript keyword (2024)

#142

Post by bspammer »

LordN00b wrote: post #140
debugnik wrote: post #111

Earlier quoted context omitted.

Not really, I provided these examples a couple weeks ago on another HN thread. TypeScript is simply unsound. https://www.typescriptlang.org/play/?#code/MYewdgzgLgBAllApg... https://www.typescriptlang.org/play/?#code/DYUwLgBAHgXBB2BXA...

In the first example you deliberately create an ambiguous type, when you already know that it's not. You told the compiler you know more than it does. The second is a delegate, that will be triggered at any point during runtime. How can the compiler know what x will be?

For the first one, the compiler should not allow the mutable list to be assigned to a more broadly typed mutable list. This is a compile error in kotlin, for example

    val items: MutableList = mutableListOf(3)
    val brokenItems: MutableList = items

Re: `satisfies` is my favorite TypeScript keyword (2024)

#143

Post by debugnik »

LordN00b wrote: post #140
debugnik wrote: post #111

Earlier quoted context omitted.

Not really, I provided these examples a couple weeks ago on another HN thread. TypeScript is simply unsound. https://www.typescriptlang.org/play/?#code/MYewdgzgLgBAllApg... https://www.typescriptlang.org/play/?#code/DYUwLgBAHgXBB2BXA...

In the first example you deliberately create an ambiguous type, when you already know that it's not. You told the compiler you know more than it does. The second is a delegate, that will be triggered at any point during runtime. How can the compiler know what x will be?

First example: you're confusing the annotation for a cast, but it isn't; it won't work the other way around. What you're seeing there is array covariance, an unsound (i.e. broken) subtyping rule for mutable arrays. C# has it too but they've got the decency to check it at runtime.

Second example: that's the point. If the compiler can't prove that x will be initalised before the call it should reject the code until you make it x: number|undefined, to force the closure to handle the undefined case.

Re: `satisfies` is my favorite TypeScript keyword (2024)

#144

Post by mcintyre1994 »

Satisfies is very useful as a library author for testing your types. You can write `typetest` files that don't become part of the bundle but are compiled.

One example is that we have a TS library for a JSON-RPC server that is horribly complex on the server side, returning different shapes of output based on input params. I don't think it can be typed with OpenAPI etc, but it can be with Typescript method overloads.

But then instead of writing unit tests that either coerce or mock the server into returning each shape, we can write typetests like this to make sure our type juggling provides the exact right types to developers:

    const rpc = null as unknown as Rpc
    const result = await rpc.someApi(input).send()
    result satisfies {
        value: {
            nestedFieldForThisInput: number
        }
    }
```

The tradeoff is slightly longer compile times for the library since all this is checked at build time, but it provides a lot of flexibility for testing overloads and utility types in isolation.

Re: `satisfies` is my favorite TypeScript keyword (2024)

#145

Post by locknitpicker »

Exoristos wrote: post #100
epolanski wrote: post #3

> TypeScript is a wonderfully advanced language though it has an unfortunately steep learning curve An extremely steep one. The average multi-year TypeScript developer I meet can barely write a basic utility type, let alone has any general (non TypeScript related) notion of cardinality or sub typing. Hell, ask someone to write a signature for array flat, you'd be surprised how many would fail. Too many really stop at…

"There basics," well understood and judiciously applied, is where the bulk of TypeScript's value lies.

> "There basics," well understood and judiciously applied, is where the bulk of TypeScript's value lies.

Yes, precisely. OP is also completely oblivious to the fact that TypeScript is designed to help developers gradually onboard legacy JavaScript projects and components, which definitely don't require arcane and convoluted type definitions to add value.

Re: `satisfies` is my favorite TypeScript keyword (2024)

#146

Post by macguillicuddy »

jstanley wrote: post #113
locknitpicker wrote: post #107

Earlier quoted context omitted.

> The fact that there can be runtime type errors that were proven impossible at compile time is why I will never enjoy TypeScript. The "impossibility" is just a trait of the type definitions and assertions that developers specify. You don't need to use TypeScript to understand that impossibilities written in by developers can and often are very possible.

My first introduction to TypeScript was trying to use it to solve Advent of Code. I wrote some code that iterated over lines in a file or something and passed them to a function that took an argument with a numeric type. I thought this would be a great test to show the benefits of TypeScript over plain JavaScript: either it would fail to compile, or the strings would become numbers. What actually happened was it comp…

No tool is perfect. What matters is if a tool is useful. I've found TypeScript to be incredibly useful. Is it possible to construct code that leads to runtime type errors? Yes. Does it go a long way towards reducing runtime type errors? Also yes.

Re: `satisfies` is my favorite TypeScript keyword (2024)

#147

Post by macguillicuddy »

jstanley wrote: post #141
LordN00b wrote: post #140

Earlier quoted context omitted.

In the first example you deliberately create an ambiguous type, when you already know that it's not. You told the compiler you know more than it does. The second is a delegate, that will be triggered at any point during runtime. How can the compiler know what x will be?

If it only works when you write the types correctly with no mistakes, what's the point? I thought the point of all this strong typing stuff was to detect mistakes.

Because adding types adds constraints across the codebase that detect a broader set of mistakes. It's like saying what's the point of putting seatbelts into a car if they only work when you're wearing them - yes you can use them wrong (perhaps even unknowingly), but the overall benefit is much greater. On balance I find that TypeScript gives me huge benefit.

Re: `satisfies` is my favorite TypeScript keyword (2024)

#148

Post by Degorath »

ownagefool wrote: post #123
jstanley wrote: post #98

Earlier quoted context omitted.

The fact that there can be runtime type errors that were proven impossible at compile time is why I will never enjoy TypeScript.

Agree wholeheartedly. Writing TypeScript is better than JavaScript, but the lack of runtime protection is fairly problematic. However, there are libraries such as https://zod.dev , and you can adopt patterns for your interfaces and there's already a large community that does this.

Could you please elaborate on "patterns for your interfaces"?

Re: `satisfies` is my favorite TypeScript keyword (2024)

#149

Post by swiftcoder »

macguillicuddy wrote: post #146
jstanley wrote: post #113

Earlier quoted context omitted.

My first introduction to TypeScript was trying to use it to solve Advent of Code. I wrote some code that iterated over lines in a file or something and passed them to a function that took an argument with a numeric type. I thought this would be a great test to show the benefits of TypeScript over plain JavaScript: either it would fail to compile, or the strings would become numbers. What actually happened was it comp…

No tool is perfect. What matters is if a tool is useful. I've found TypeScript to be incredibly useful. Is it possible to construct code that leads to runtime type errors? Yes. Does it go a long way towards reducing runtime type errors? Also yes.

> No tool is perfect. What matters is if a tool is useful

Some tools are more perfect and more useful than others.

Typescript's type system is very powerful, but without strict compile-time enforcement you still spend a lot of effort on validating runtime weirdness (that the compiler ought to be able to enforce).

Re: `satisfies` is my favorite TypeScript keyword (2024)

#150

Post by locknitpicker »

lloydatkinson wrote: post #7
epolanski wrote: post #3

> TypeScript is a wonderfully advanced language though it has an unfortunately steep learning curve An extremely steep one. The average multi-year TypeScript developer I meet can barely write a basic utility type, let alone has any general (non TypeScript related) notion of cardinality or sub typing. Hell, ask someone to write a signature for array flat, you'd be surprised how many would fail. Too many really stop at…

TypeScript codebases I've seen generally seem to have the widest demonstration of skill gap versus other languages I use. For example, I don't ever see anyone using `dynamic` or `object` in C#, but I will often see less skilled developers using `any` and `// @ts-ignore` in TypeScript at every possible opportunity even if it's making their development experience categorically worse. For these developers, the `type` ke…

> For example, I don't ever see anyone using `dynamic` or `object` in C#, but I will often see less skilled developers using `any` and `// @ts-ignore` in TypeScript at every possible opportunity even if it's making their development experience categorically worse.

I think you're confusing things that aren't even comparable. The primary reason TypeScript developers use the likes of `any` is because a) TypeScript focuses on adding support for static type checking on a language that does not support it instead of actually defining the underlying types, b) TypeScript developers mostly focus on onboarding and integrating TypeScript onto projects and components that don't support it, b) TypeScript developers are paid to deliver working projects, not vague and arbitrary type correctness goals. Hence TypeScript developers tend to use `any` in third party components, add user-defined type guards to introduce typing in critical areas, and iterate over type definitions when time allows.

Post reply on HN