The trade-off is obvious: you gain confidence about your program but you need to Learn More Stuff. Nobody's talking about the downsides of type systems except to the extent that they're worth talking about: see the comments here every time someone compares the type systems of Python and Rust.
This is why engineering/software articles in general (this one included) needs to bring up tradeoffs more often. No, "learning more stuff" is not a downside or a tradeoff, it's just a fact of learning anything.
That you introduce more coupling is a tradeoff. That the program (sometimes) gets harder to change is a tradeoff. That is becomes easier to write large, messy programs because programmers feel more safe in the future to refactor, is a tradeoff. Trying to fix each one of those tradeoffs also come with their own tradeoffs, and so on.
These are "apparent" for me, when talking about languages using static types vs dynamic languages, but it is not apparent for everyone. So when bringing up these "obvious" upsides, also bring up the "obvious" downsides, as it seems quite a lot of people don't see it as "obvious" as we do.
You don't introduce more coupling, you document the coupling that already exists. If your program is hard to change with types, it would be hard to change without types - but easier to change incorrectly.
> That is becomes easier to write large, messy programs because programmers feel more safe in the future to refactor, is a tradeoff
Sure, I guess this is true in principle - but you could say the same about IDEs, or version control, or grep. The effect size is small.
This is true at the code level. But at the system-design level, this documentation is the extra coupling.
I feel like it's important to understand this. I agree with the original commenter; in engineering, nothing is truly free. In many cases, this extra coupling helps keep a system strong and stable, like extra nails holding planks of wood together. In other cases, you may find that part of a system's spec actually missed the mark and now needs to be ripped up and redone. That extra coupling might now work against you!
Again, that doesn't mean that it wasn't worth having it. It is just important to understand tradeoffs in engineering.
That’s not inherent in static types.
No, the coupling (i.e. assumptions about what type this thing can be) is implicitly there in a typeless language. If you pass in the wrong thing it'll blow up. But it'll happen in production.
The coupling is always there, it's just a matter whether you make it explicit (this allowing errors to be caught early) or you pretend it's not there and let things crash in production.
You still do need to know that stuff if you have no types in your language, but the compiler won't help you.