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.

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

https://typescript-eslint.io/rules/switch-exhaustiveness-che... if that is something you're not aware of!

Nice. I didn’t know I can now replace my “assertExhaustive” function.

Previously you could define a function that accepted never and throws. It tells the compiler that you expect the code path to be exhaustive and fixes any return value expected errors. If the type is changed so that it’s no longer exhaustive it will fail to compile and (still better than satisfies) if an invalid value is passed at runtime it will throw.

TIL.

> Hell, ask someone to write a signature for array flat, you'd be surprised how many would fail.

To be clear, an array flat type:

    type FlatArr<Arg extends unknown[]> = Arg extends [infer First, ...(infer Rest)] ?
      First extends unknown[] ?
        [...First, ...FlatArr<Rest>] :
        [First, ...FlatArr<Rest>] :
      [];

Not only have I never been expected to write something like this for actual work, I'm not sure it's been useful when I have, since most of my colleagues consider something like this nerd sniping and avoid touching/using such utilities, even with documentation.

> Too many really stop at the very basics.

I don’t think that means it has a steep learning curve. It just means the basics suffice for a ton of TypeScript deployments. Which I personally don’t see as the end of the world.

> Too many really stop at the very basics.

As someone who knows slightly more than the basics, and enough to know about the advanced stuff that I don't know about, this is the correct place to stop.

I would much rather restructure my javascript than do typescript gymnastics to fit it into the type system.

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.

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

Typescript types often devolve into

keyof typeof[number] ? uppercase (myNum)

On the other hand, there isn't much Omit, readonly, mutable in existing code bases, so devs have nowhere to learn but documentation.

Then the ground shifts again and –what should be basic stuff – enums are banned, because erasableSyntaxOnly makes life so much easier.

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 works

Most types - use Maps | Arrays

if a value doesn't exist in a map we can ignore it. There's also the safe navigation operator.

Instead of mutable objects - there's ways around this too. Negating types again.

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

I think you're both exaggerating your blanket accusations of incompetence and confusing learning curve with mastering extremely niche techniques akin to language gotchas.

>And even though I consider myself okay at TypeScript, the gap with the more skilled of my colleagues is still impressively huge.

Maybe they're smart, but the even smarter dev would avoid unnecessary complexity in the first place.

to our defense, we want to build stuff not become ts wizards. also I've worked with libraries with heavy heavy typing that it was a nightmare if you wanted to use their lib in any other way than what they have imagined.

This is the bell curve meme, and you are in the middle telling us "template metaprogramming in C++ is amazing".

these are things most developers don't know how to do in most language's type systems. I think only rust with its focus on functional roots has seen similar focus on utilizing its type system to its fullest extent.

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` keyword is totally unknown. They don't know how to make a type, or what `Omit` is, or how to extend a type. Hell, they usually don't even know what a union is. Or generics.

I sometimes think that in trying to just be a superset of JavaScript, and it being constantly advertised as so, TypeScript does not/did not get taken seriously enough as a standalone language because it's far too simple to just slot sloppy JavaScript into TypeScript. TypeScript seems a lot better now of having a more sane tsconfig.json, but it still isn't strict enough by default.

This is a strong contrast with other languages that compile to JavaScript, like https://rescript-lang.org/ which has an example of pattern matching right there on the home page.

Which brings me onto another aspect I don't really like about TypeScript; it's constantly own-goaling itself because of it's "we don't add anything except syntax and types" philosophy. I don't think TypeScript will ever get pattern matching as a result, which is absurd, because it has unions.

You're right, but that begs the question: does a type system really require such complexity?

I'm aware that type theory is a field in and of itself, with a lot of history and breadth, but do developers really need deep levels of type flexibility for a language to be useful and for the compiler to be helpful?

I think TypeScript encourages "overtyping" to the detriment of legibility and comprehension, even though it is technically gradually typed. Because it is so advanced and Turing complete itself, a lot of brain cycles and discussion is spent on implementing and understanding type definitions. And you're definitely right that it being verbose also doesn't help.

So it's always a bittersweet experience using it. On one hand it's great that we have mostly moved on from dynamically typed JavaScript, but on the other, I wish we had settled on a saner preprocessor / compiler / type system.

Not steep so much as deep.

There’s a lot you can do in TypeScript. But you don’t have to do it. And TS existed successfully a long time without those features.

I have mixed feelings about Typescript, I hate reading code with heavy TS annotations because JS formatters are designed to keep line widths short, so you end up with a confusing mess of line breaks. Pure JS is also just more readable.

Also you can so easily go overboard with TS and design all sorts of crazy types and abstractions based on those types that become a net negative in your codebase.

However it does feel really damn nice to have it catch errors and give you great autocomplete and refactoring tooling.

> ask someone to write a signature for array flat

Out of curiosity - what do you think is a satisfactory answer here?

My answer would vary wildly based upon more details, but at the most basic all I can think you could guarantee is Array<unknown> => Array<unknown>?

Honestly I just use TypeScript to prevent `1 + [] == "1"` and check that functions are called with arguments. I don't care about type theory at all and the whole thing strikes me as programmers larping (poorly) as mathematicians.

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.

The author gets into that. `Thetype` might be complex. It also protects you from overgeneralizing, like casting to and from `unknown` to escape the type checker.

    type Current = {
      kind: "ac" | "dc";
      amps: number;
    }
    
    type Dc = {
      kind: "dc";
      amps: number;
    }
    
    const ac: Current = {
      kind: "ac",
      amps: 10000000,
    }
    
    const handleDc = (thing: Dc) => {}
    
    const badConvert = (c: Current) => ({...c, kind: "dc"});
    
    /**
    * Argument of type '{ kind: string; amps: number; }' is not assignable to parameter of type 'Dc'.
        Types of property 'kind' are incompatible.
            Type 'string' is not assignable to type '"dc"'.(2345)
    */
    handleDc(badConvert(ac));
    
    const goodConvert = (c: Current) => ({
      ...c, kind: "dc",
    } satisfies Dc);
    
    handleDc(goodConvert(ac));
    
    /**
    * Object literal may only specify known properties, and 'bar' does not exist in type 'Dc'.
    */
    const badConvert2 = (c: Current) => ({
      ...c, kind: "dc", bar: "qwerty"
    } satisfies Dc);

You can sorta think of `satisfies Foo` as "the type is exactly the literal value, but also make sure the value could be used in the place of a Foo"

The satisfies keyword is quite different than "as const." What it does is:

1. Enforce that a value adheres to a specific type

2. But, doesn't cause the value to be cast to that type.

For example, if you have a Rect type like:

    type Rect = { w: number, h: number }

    const a = { x: 0, y: 0, w: 5, h: 5 };

    const a: Rect = // ...

    as Rect

    type Location = { x: number, y: number };
    const a: Location & Rect = // ...

The satisfies keyword does what you want in this case: it enforces the object conforms to the type, without casting it to the type.

    const a = { x: 0, y: 0, w: 5, h: 5 } satisfies Rect;
    // a.x works

    const a = { x: 0, y: 0, width: 5, height: 5 } satisfies Rect;

I've really only found benefit on the return type of functions, when you can say that a type parameter satisfies a type (with the return type being a boolean). This let's you use `if (isPerson(foo))` and typescript will narrow the type appropriately in the conditional

With as const you can’t verify against another interface

It prevents you from mutating via the reference that you obtain from `satisfies` without casting its type, yes (or rather more precisely, you can mutate it, but only to the one allowed value).

However, the object can still be mutated via other references to it. TypeScript is full of holes like this in the type system - the problem is that they are trying to bolt types and immutability onto a hot mess that is JS data model while preserving backwards compatibility.

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.

Tell me when Go is browser ready

Then either make the properties optional or use Partial on the type you are satisfying

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 :)

You can do that with assembly and not know ANY high level language.

You might be interested in reading PG's treatise on "the blub paradox".

Can you even do that? I though you could only enterprise in secure languages, like Java

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