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.