JavaScript had to implement these checks because you could pass a function literally anything and it was on the implementation to deal with it. Typescript has this same problem tbh.
It leads to less code, and more generalizable code. Maybe the caller does know what they're doing, who am I to say they can't.
What happens is you get an error. So you immediately know something is wrong.
Javascript goes the extra mile to avoid throwing errors.
So you've 3>"2" succeeding in Javascript but it's an exception in python. This behavior leads to hard to catch bugs in the former.
Standard operators and methods have runtime type checks in python and that's what examples in the article are replicating.
Javascript was a prototype that was supposed to be refined and cleaned. Then management said "we will ship it now" and it was shipped as it was.
At the time, they thought it will be used for small things, minor snippets on web page. Webapps as we have them were not a thing yet.
So? Language is irrelevant here. What matter is the contract, the agreement that operates through time and space between caller and callee on behavior and expectations. Contracts exist outside of the type system. All a type system can do is enforce a subset of the contractual requirements.
For example, log(0) is undefined. If you write a function to compute log(x), you can (and should) document the function as having unspecified behavior when x is zero.
That's the contract.
The contract holds whether the function is spelled like this
// x must be positive number
function log(x) { return ... }
// x must be positive
function log(x: number): number { ... }
Likewise, you could define a version of log that accepted, e.g. spelled numbers, like log("three"). You can express this weird contract with static or dynamic typing.
The nasty thing is that if early in the log library's history, before the author wrote down the contract or even had TypeScript, someone had written log("three") and gotten a type error, the log library's author might have "fixed" the "bug" by checking for spelled numbers as inputs. That would have been an expansion of the function's contract.
The log library author probably wasn't thinking about the long-term downsides of this expansion. He could have, even when our log() was a pure-JavaScript, just said "The contract is the input is a positive number. Your code is buggy."
But our hypothetical log library author didn't have the experience or good judgement to say no, so we ended up with the kind of "corner case bloat" the article's author describes.
Don’t most languages have the same problem? Even C or Rust have escape hatches that let you override compile-time type checking and pass whatever gibberish you want to a function. How is Typescript any worse?
I’ll pull off the cleanest, nicest generic constraints on some component that infers everything perfectly and doesn’t allow invalid inputs, just for a coworker to throw @ts-nocheck on the entire file. It hurts
In my experience nobody writes Typescript without checking the types. Unlike Python for example where it's not uncommon to have broken types. (And it's way more of a mess in general.)