I don't get TypeScript's type system.

It is obviously very powerful and can model very complex type constraints.

But then you have stuff like this where it is not checking types as I would expect:

  interface Foo { bar: string; }
  const f = {bar: "foobar"} as Readonly<Foo>;
  function someFunc(): Foo {
    return f; // No error or warning, even with all strict flags enabled
  }

    class Animal {}

    class Dog extends Animal {
        woof() {}
    }

    class Cat extends Animal {
        meow() {}
    }

    let append_animals = (animals: Animal[], animal: Animal) => animals.push(animal)

    let dogs = [new Dog()]
    append_animals(dogs, new Cat())

    dogs.map(dog => dog.woof())

    Uncaught TypeError: dog.woof is not a function

    class Animal:
        pass

    class Dog(Animal):
        pass


    def append_animals(animals: List[Animal], animal: Animal) -> None:
        animals.append(animal)


    dogs = [Dog()]
    append_animals(dogs, Dog())

    $ mypy types.py 
    types.py:16: error: Argument 1 to "append_animals" has incompatible type "List[Dog]"; expected "List[Animal]"
    types.py:16: note: "List" is invariant -- see https://mypy.readthedocs.io/en/stable/common_issues.html#variance
    types.py:16: note: Consider using "Sequence" instead, which is covariant

    let append_animals = <T extends Animal>(animals: T[], animal: T) => animals.push(animal)

While no actual Turing machine’s tape is infinitely long, I found issues in TypeScript with how finite generics are.

You have to define every possible count of generic arguments if you want to preserve their types. And if you go above that count your type system degrades. I think there’s also a maximum of 7 or so before it doesn’t work. Beyond that and the generic type widens.

For example, Lodash enumerating types for 2 to 7 generic items per function: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/0452...

Admittedly I don’t understand the problem space well. I’ve just seen it happen to me and in others’ code. It might not actually be an issue, or is already fixed.

As wonderfully absurd as this is, I learned more about TypeScript’s type system from this post than I have from its documentation.

Entirely possible that PEBKAC, but I’ve found TypeScript’s documentation to be on the worse end of the programming language documentation quality spectrum.

  interface add extends F { out: this['args'] extends   [infer a, infer b]     ?
  a extends Zero         ? b :
  a extends Suc<infer n> ? Suc<apply<add, [n, b]>> : 

  never : never
}

Can you? Certainly. Should you? Ehhhhh…

The post is experimenting with the type system—which is neat—but before you think you should push this in production (having been in positions to work with heavy-FP’d code), consider an actual FP language if that’s the style you want. The ergonomics are so bad compared to any FP lang→JS option. Currying/partial application, first-class composition/bind/apply, pattern matching not using a ._tag property with a String key, and more are just missing (see: migrating from PureScript/Haskell[0] for fp-ts to see how verbose basic concepts becomes). The other issue is that with TypeScript being multiparadigm and idiomatic TS leaning to imperative/OO due to ergonomics and Java’s legacy on culture/education, there’s a good chance your coworkers/contributors will be expecting a non-FP style which will cause even more friction as you try to justify ‘purity’ to folks that just see a verbose codebase that likely is leaning hard into a lib, quality as it is, like fp-ts which cosplays as Haskell, PureScript, OCaml, Idris, et. al.

[0]: https://gcanti.github.io/fp-ts/guides/purescript.html

Is it just me or do other people read things like "covariance on a mutable generic type" and just want to get stuff done? Maybe it's because nowadays I do solo or small team projects but this is why I fled to Elixir, it's mostly dynamically typed and you can gradually get into types when you want it, Elixir is cool with that.

I’m really interested in this for fun, but it’s still way over my head. And this is someone who has been using typescript daily for years. Would love to read something more long form that builds up to this.

Related: "TypeScripting the technical interview" https://news.ycombinator.com/item?id=35120084

I've done my share of weird stuff with TS types before, but I'd never seen the trick of using interfaces to make higher-order functions. Neat.

Fun exploration and exceptionally impractical. Love it.

What a monstrosity.

At this point I'm wondering if the TypeScript type system can be used for dependant types that would allow formal verification of the programs

Gross. I love it.

Try to type a flatMap and then we talk.

    type ValueOrArray<T> = T | Array<ValueOrArray<T>>;
    type FlatMap<In, Out> = (array: Array<In>, fn: (el: In) => ValueOrArray<Out>) => Array<Out>;