`satisfies` is my favorite TypeScript keyword (2024) • Hacker News Board

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

#181

Post by CharlieDigital » Sun, Nov 23, 2025, 1:59 PM UTC

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.

Zod is quite unpleasant to use, IME, an has some edge cases where you lose code comments.

From experience, we end up with a mix of both Zod and types and sometimes types that need to be converted to Zod. It's all quite verbose and janky.

I quite like the approach of Typia (uses build-time inline of JavaScript), but it's not compatible with all build chains and questions abound on its viability post Go refactor.

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

#182

Post by dcre » Sun, Nov 23, 2025, 1:59 PM UTC

cess11 wrote: post #173

thomasikzelf wrote: post #130

Earlier quoted context omitted.

If Typescript is javascript with types bolted on, Rescript is javascript with types the way it should have been. Sound types with low complexity. https://rescript-lang.org/

Does this have a relation to Reason/Reason ML?

“ReScript is a rebranding of BuckleScript and Reason”

https://v11.rescript-lang.org/docs/manual/latest/migrate-to-...

https://rescript-lang.org/blog/bucklescript-is-rebranding/

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

#183

Post by sandblast » Sun, Nov 23, 2025, 2:05 PM UTC

debugnik wrote: post #175

sandblast wrote: post #167

Earlier quoted context omitted.

Aren't these bugs that could be "simply" reported and fixed? Or maybe those would get a label "not a bug" attached by the TS creators for some reason?

Both are by design. Array covariance is a common design mistake in OOP languages, which the designer of TypeScript had already done for C# but there they at least check it at runtime. And the latter was declared not-a-bug already IIRC. TypeScript designers insist they're ok with it being unsound even on the strictest settings. Which I'd be ok with if the remaining type errors were detected at runtime, but they also i…

"By design", for me, doesn't say that it can't be changed — maybe the design was wrong, after all. Would it be a major hurdle or create some problems if fixed today?

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

#184

Post by lelandfe » Sun, Nov 23, 2025, 2:40 PM UTC

mook wrote: post #72

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…

It's also terribly documented. As an example, I don't think `satisfies` is in the docs outside of release notes. There's lots more stuff like that, which makes using it kind of frustrating.

Preach. It’s astonishing how much necessary documentation lives as unchanging footnotes on TS releases.

https://www.google.com/search?q=site%3Ahttps%3A%2F%2Fwww.typ...

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

#185

Post by hermanradtke » Sun, Nov 23, 2025, 2:51 PM UTC

CharlieDigital wrote: post #181

ownagefool wrote: post #123

Earlier quoted context omitted.

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.

Zod is quite unpleasant to use, IME, an has some edge cases where you lose code comments. From experience, we end up with a mix of both Zod and types and sometimes types that need to be converted to Zod. It's all quite verbose and janky. I quite like the approach of Typia (uses build-time inline of JavaScript), but it's not compatible with all build chains and questions abound on its viability post Go refactor.

> we end up with a mix of both Zod and types and sometimes types that need to be converted to Zod

In my code, everything is a Zod schema and we infer interfaces or types from the schemas. Is there a place where this breaks down?

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

#186

Post by tshaddox » Sun, Nov 23, 2025, 2:53 PM UTC

jstanley wrote: post #128

Defletter wrote: post #102

Earlier quoted context omitted.

Isn't that not necessarily out of the ordinary though? What if there's a cosmic ray that change's the value to something not expected by the exhaustive switch? Or more likely, what if an update to a dynamic library adds another value to that enum (or whatever)? What some languages do is add an implicit default case. It's what Java does, at least: https://openjdk.org/jeps/361

> What if there's a cosmic ray that change's the value to something not expected by the exhaustive switch? I could forgive that. The TypeScript case is more like "what if instead of checking the types we just actually don't check the types?".

This is how all static type checking works. What programming language do you have in mind that does static type checking and then also does the same type checking at runtime? And what would you expect this programming language to do at runtime if it finds an unexpected type?

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

#187

Post by thomasikzelf » Sun, Nov 23, 2025, 3:24 PM UTC

intellix wrote: post #166

thomasikzelf wrote: post #130

Earlier quoted context omitted.

If Typescript is javascript with types bolted on, Rescript is javascript with types the way it should have been. Sound types with low complexity. https://rescript-lang.org/

That syntax is so alien to me as a JS/TS developer. I mean coffeescript was as well until JS slowly introduced it all. It would be cruel for me to force ReScript onto the team because they'd all need to reskill. I could only use it for a private project and then hire exclusively for it afterwards

Really, that is surprising to hear. There are a couple of differences but most of the syntax looks the same to me, what part do you find alien?

The reskill problem is of similiar difficulty with learning a new framework I think. Especially because the language is rather simple compared to typescript (which is also its strength).

I do understand it is an uphill battle. The whole nobody get's fired for choosing IBM thing. The language is still unproven in the general perception. I do think that when it comes to libraries and frameworks I see a lot of developers choose new unproven stuff, more then they do languages.

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

#188

Post by mrlowlevel » Sun, Nov 23, 2025, 3:51 PM UTC

rezonant wrote: post #83

mckirk wrote: post #71

Earlier quoted context omitted.

I generally do this via a `throw UnsupportedValueError(value)`, where the exception constructor only accepts a `never`. That way I have both a compile time check as well as an error at runtime, if anything weird happens and there's an unexpected value.

That's very clever!

We have this nifty util in our codebase:

```ts

/*

* A function that asserts that a value is never.

* Useful for exhaustiveness checks in switch statements.

*/

export function assertNever(x: never): never {

  // eslint-disable-next-line @typescript-eslint/restrict-template-expressions

  throw new Error(`Unexpected object: ${x}`)

}

```

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

#189

Post by halapro » Sun, Nov 23, 2025, 4:06 PM UTC

nrhrjrjrjtntbt wrote: post #23

Why? why make your code so complex you even hit this problem. Just use the type: const x: Thetype = .... I am not keen on as const either. Just program to interfaces. It is a better way to think IMO.

Because what you wrote broadens the type. `satisfies` validates the type without broadening it.

const c: string = 'c';

This will be of type string instead of type 'c'. This is a barebones example and it already breaks support for template literal types. Imagine how much better `satisfies` is for complex union types.

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

#190

Post by plaguuuuuu » Sun, Nov 23, 2025, 4:13 PM UTC

eitland wrote: post #135

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.

TypeScript isn't primarily meant to be enjoyed. It is meant to be a much better alternative to Javascript while dealing with the fact that the underlying engines use and existing programmers were used to Javascript. That said I absolutely enjoy TypeScript, but that might be because I suffered from having to deal with Javascript from 2006 until TypeScript became available.

As a C# dev, backend typescript is fantastic and the type system is light years ahead of C# in expressivity.

But the learning curve... no shit.