Forgive me if I didn't use the right terminology too. What I mean by type checking bugs are the kinds of bugs shown in the article: I have an argument that should be a number but someone accidentally uses it with a string instead.

That's the most basic bug that typed languages catch. But for me, those are extremely simplistic. I don't need a type checker to know that. If you follow the code path you already know the types you're dealing with.

What strongly typed languages can provide are types with constraints. E.g. an age is not only a number, but a valid number greater than zero (maybe with an upper bound?) that is attached to a person. That kind of strong guarantee will definitely catch runtime bugs if you pass in some other numeric value that is not a representation of an age.

Languages like TypeScript can't do that. Take the example below. It compiles as if there's nothing wrong:

  type Age = number

  type Person = {
    age: Age
  }

  const person = { age: 10 } as Person
  const someRandomNumber = 10

  function printAge(age: Age) {
    return console.log(age)
  }

  printAge(person.age)
  printAge(someRandomNumber)

This is the kind of bug that a good type system would be extremely helpful with. In my entire career it's definitely a lot more common than passing a string by mistake. This can be extended for having a type that differentiates an `Email` from a `ValidEmail`, an `ActiveUser` from an `User` and so on. Those are, in my view, where a type system can truly help us catch bugs. But even if you have a type system that supports that, nothing stops someone from simply using `number` instead of `Age`.

In any case, that's why I don't think it's as clear cut as people put it. Yes, in very rare occasions TS will tell me I accidentally allowed something that can be undefined pass (excluding the many times it gets it wrong). However that doesn't come for free and that is what makes absolutist claims for either side unhelpful.

TypeScript is intentionally _structurally_ typed (except for enums). The example you describe would only be caught by a _nominally_ typed language (think Java).

Structural typing is great when programming functionally (i.e. with immutability) when the most important thing is the shape of inputs and outputs of functions, instead of named objects (like Person) and properties. In a functional program, for example, "printAge" would likely be called something like "print" or "printNumber" since that is what it is doing to its input _value_.

I think a lot of the misunderstanding I've seen recently around TypeScript (like from the Rails creator) comes from the misuse of TypeScript - if you use TypeScript in an object-oriented way, its going to be significantly less helpful.

>if you use TypeScript in an object-oriented way

I don't follow this one. I've never seen anyone use TypeScript with an OO approach aside from, ironically, the .NET folks.

The code I wrote has nothing OO with it and we can already see the issues. The majority of TS I've ever worked with was written for React and it still would benefit greatly from nominal types as you call them (thanks I didn't know that terminology).

I don't see everyone misusing TS. For me, it's simply a very limited language as far as typed languages go. As a result, it's a shame that it's what is being touted as a good example of why you should use typed languages.

First, Angular uses classes, and React supports class-based components.

Then, if you have converted lots of Javascript into Typescript, you have probably found several type-related bugs.

On one hand, this makes you (me) trust Typescript more, and feel safer knowing that your types are correct.

Later, you discover that a few of the declared types are wrong! You also still get "this" wrong in callbacks.

You could say that Typescript lets you try to get your types right, but you have to do the heavy lifting yourself.

That hasn’t been my experience. ReScript and Elm are much better compared to the fragile types I’ve encountered with Typescript (where I needed to write code to do the type checking). Happy if you’ve found something that works for you though.

For such problems we use the Opaque type from the nifty type-fest package. We use it for all of our id types (which are usually numbers) so we can't accidentally mix them.

In your example it would be:

    type Age = Opaque<number, "Age">

And then you wouldn't be able to pass a random number to printAge