Live data from Hacker News

`satisfies` is my favorite TypeScript keyword (2024)

sjer.red

111–120 of 217 posts

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

#111

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.

That scenario is usually either misuse of escape hatches (especially at API boundaries) or a misunderstanding of what Typescript actually guarantees.

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...

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

#112
post #41
post #24

Earlier quoted context omitted.

If I saw that in a PR I would push very hard to reject; something like that is a maintenance burden that probably isn’t worth the cost, and I’ve been the most hardcore about types and TypeScript of anyone of any team I’ve been on in the past decade or so. Now, that said, I probably would want to be friends with that dev. Unless they had an AI generate it, in which case the sin is doubled.

If it's correct, it's not a maintenance nightmare, and it will alert you to problems later when someone wants to use it incorrectly. If you're writing first-party software, it probably doesn't matter. But if you have consumers, it's important. The compiler will tell you what's wrong all downstream from there unless someone explicitly works around it. That's the one you want to reject.

> If it's correct, it's not a maintenance nightmare, and it will alert you to problems later when someone wants to use it incorrectly.

You're confusing things. It is a maintenance nightmare because it is your job to ensure it is correct and remains correct in spite of changes. You are the one owning that mess and held accountable for it.

> If you're writing first-party software, it probably doesn't matter. But if you have consumers, it's important.

Yes, it is important that you write correct and usable code. That code doesn't fall on your lap though and you need to be the one writing and maintaining it. Whoever feels compelled to write unintelligible character soup that makes even experienced seasoned devs pause and focus is failing their job as a software engineer.

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

#113

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 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 compiled perfectly fine, but the "numeric" input to my function contained a string!

I found that to be a gross violation of trust and have never recovered from it.

EDIT: See https://news.ycombinator.com/item?id=46021640 for examples.

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

#114

In my personal projects, I’m a fan of using satisfies to check Zod definitions against the interfaces they validate. I find the base interfaces easier to read at a glance than derived types, especially in an editor’s hover view. Though, nullable fields might get weird, iirc.

Yeah, I believe that doesn't quite work correctly for nullable fields or cases where the Zod type would be a subtype of the declared type. But it's a really useful technique, because it's a lot easier to work with types you've declared in TypeScript than the ones Zod generates. I'm sure there's scope for a validation library that is designed around the user providing a TypeScript type and then producing an error if the validation doesn't match that type.

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

#115
post #82

> TypeScript is a wonderfully advanced language though it has an unfortunately steep learning curve; in many ways it’s the complete opposite of Go. Replace "TypeScript" with "C++" and the same can be said. It is one of the worst languages ever designed and already built on top of a sloppy foundation (Javascript) compared to Go. The language encourages escape hatches and tons of flexibility on how it checks its types…

I disagree. The speed with which Typescript replaced JS as the default is testament to its strength. I remember back is the good old JS only days you had to assume that all the form values we passed and read were strings and not an integer account number for example. Typescript solves these challenges and that alone eliminates a large class of frankly nonsensical bugs.

The reason it is being rewritten in Go is so the compiler can be run at native speeds which is a good thing. Otherwise the only runtime we have available is NodeJS which has its fair share of problems. You can go far with TS with just interface definitions and some generics peppered in for common utilities. The places where all the type gymnastics is necessary are cases I frankly havent encountered in the usual course of development.

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

#116
post #82

> TypeScript is a wonderfully advanced language though it has an unfortunately steep learning curve; in many ways it’s the complete opposite of Go. Replace "TypeScript" with "C++" and the same can be said. It is one of the worst languages ever designed and already built on top of a sloppy foundation (Javascript) compared to Go. The language encourages escape hatches and tons of flexibility on how it checks its types…

Tell me when Go is browser ready

Misses the point. Both these languages have their place. Besides there's no benchmarks beyond developers personal opinions that tells us whether a language is browser ready or not.

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

#117
post #48

99% of my use of `satisfies` is to type-check exhaustivity in `switch` statements: type Foo = 'foo' | 'bar'; const myFoo: Foo = 'foo'; switch (myFoo) { case 'foo': // do stuff break; default: myFoo satisfies never; // Error here because 'bar' not handled }

I would highly recommend the ts-pattern [1] library if you find yourself wanting exhaustive switch statements! The syntax is a bit noiser than case statements in simple cases, but I find it less awkward for exhaustive pattern matching and much harder to shoot yourself in the foot with. Once you get familiar with it, it can trim down a /lot/ of more complicated logic too.

It also makes match expressions an expression rather than a statement, so it can replace awkward terenaries. And it has no transitive dependencies!

[1]: https://github.com/gvergnaud/ts-pattern

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

#118
post #5

the cool thing about Typescript is that you never have to know any of this to deliver highly performant enterprise scale software

I think this is spot on. TS goes very very far without the gymnastics. Its good to know these things, but not even close to necessary to be productive. Not to mention IDE support for TS is on a very different level conpared to the shitshow that is Javascript.

Also, Angular dev spotted :)

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

#119
post #49

> 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 is largely a result of solving a non-existent problem. Yeah JS is finicky & has foot-guns, however they're ways around those foot guns that don't involve typescript. Rich Hickey in 10 Years of Clojure & Maybe Not then the Value of Values - lays this out - though not meant at typescript but static types in general. the thing most people don't have proper Javascript fundamentals. Function signatures: JSDoc w…

> typescript is largely a result of solving a non-existent problem.

Claiming that lack of static type checking is a non-existent problem is quite a bold claim. Care to offer some details to substantiate your claim?

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

#120

80% of the value of TypeScript is that it will tell you when when you changed or added a parameter and forgot to update it everywhere, you doofus. The other 20% is that it keeps coding agents from going too far off the rails. Trying to use the type system as a metaprogramming language is only valuable as a fun exercise, but of negative value in real world projects.

This thread is weird, also spot on, not sure why its downvoted. I am happy when the IDE spots my dufusness.
Post reply on HN